Felan Makes Coding Agents Spend Less

Felan, from felan-ai, is an open-source coding agent built to reduce model spend while still completing software tasks. It deals with a boring but very real question in AI software development: how much of the bill is useful work, and how much is waste? The useful takeaway for ai coding for teams is not “use cheaper models everywhere.” It is: measure task success first, then optimize the context, routing, and tool output around that success.

Look at the rule, not just the benchmark

Felan’s README starts with a constraint that matters: an optimization only counts when the task still succeeds. That is the right center of gravity for a coding agent. A cost-efficient coding agent is an agent that reduces model usage without lowering the quality gate for the task.

As of September 2026, the repository is small: 13 GitHub stars, MIT licensed, mostly TypeScript, and last pushed on September 9. That makes it more like an interesting lab bench than a mature default. But the project is concrete enough to study.

The headline number is a 36.6% lower aggregate AI model cost across six controlled, extension-specific comparisons. The caveat is important. Felan’s reported candidates used $13.7132 versus $21.6297 for their baselines when summing median-reduced case costs, but each extension was measured separately against its disabled baseline, not as one all-enabled configuration.

That caveat is not a weakness. It is the honest shape of the claim. The trap to avoid is reading one savings number as “this agent is 36.6% cheaper for my repo.” The better read is: Felan is testing which parts of a coding-agent loop create waste.

Notice where the waste comes from

Felan’s interesting pieces are model routing, progressive context, compact tool output, explicit task state, and estimated API-equivalent savings. Those are not flashy features. They are the places where coding agents quietly burn money.

A common failure mode is dumping the whole repo, every test log, and every tool result into the model because it feels safer. It often is not safer. It can make the model slower, more expensive, and less focused.

Progressive context is the opposite habit. Give the model enough to move, then add more only when the task proves it needs more. In a real repo, that might mean starting with package.json, the failing test, and the target file, instead of attaching the whole service directory.

Compact tool output matters for the same reason. A failing test run does not need 1,200 lines of dependency noise. It needs the command, the failing assertion, the stack frame, and any changed files that explain the failure.

Treat Felan as a signal for your agent loop

The useful story here is not that every developer should switch agents tomorrow. It is that Felan makes a good engineering bet visible: agentic coding needs cost controls that are tied to correctness, not vibes.

That matters if your Claude Code, Anthropic’s coding agent, sessions are starting to look like long-running background processes. You may not need a new agent. You may need a smaller loop.

For a Claude Code user, the closest practical translation is a tight slash-command workflow. Keep one command for bounded edits, one for tests, and one for summarizing only the evidence a reviewer needs.

A small example:

# /small-fix
Goal: make the smallest safe change for the named failing test.
Inputs: failing command, target file, expected behavior.
Rules:
- inspect only files needed for this failure first
- run the narrowest relevant test before broad tests
- summarize changed files, test command, and remaining uncertainty
Stop when the narrow test passes or the next missing fact is clear.

That is not Felan’s implementation. It is the same lesson in a Claude Code-shaped wrapper: constrain the task state before you pay for more context.

Try it when spend hides in routine edits

Felan is most interesting when the task is ordinary and repeated: fixing tests, changing API handlers, updating generated types, writing migration helpers, or cleaning up lint failures. These are the places where ai coding for teams can lose money without anyone noticing, because each individual session looks harmless.

It is less compelling for one-off architecture work where the expensive part is human judgment. In that case, a cheaper model route or compact context may save a few dollars while increasing the chance that the agent misses the shape of the system.

The trap is optimizing before you know the task class. Pick one repeatable workflow. Measure success, elapsed time, and approximate model cost. Then decide whether a cost-aware agent like Felan, or a stricter Claude Code command, is worth the added moving parts.

For a neighboring example of making agent behavior easier to scan, see i-have-adhd Makes Agents Answer First. It is a different project, but it shares the same instinct: remove waste from the interaction before asking developers to trust more automation.

Copy this small experiment plan

Use this when you want to learn from Felan without betting your repo on a new agent.

A tiny permission note is enough for this experiment: run local coding agents only in a repo and shell you are comfortable giving your user permissions to. Felan’s README is explicit that the local agent is a host application, not a sandbox.

If you are already building a shared AI coding practice, this experiment fits naturally beside the broader AI coding governance topic. Keep the experiment small. The point is to learn where your own agent loop wastes tokens.

Common questions

• Is Felan ready for ai coding for teams?

  Felan is worth testing, but it looks early as of September 2026. The repository has 13 stars, an MIT license, and a clear efficiency thesis, so treat it as an experiment rather than a default tool. Use it on isolated, repeatable tasks with a defined quality gate.

• Does Felan prove AI coding can be 36.6% cheaper?

  No, not as a universal claim. Felan reports 36.6% lower aggregate model cost across six controlled, extension-specific comparisons, with every candidate meeting its configured quality gate. The important caveat is that each extension was compared separately against its disabled baseline, not as one all-enabled system.

• What makes model routing different from just picking a cheaper model?

  Model routing chooses a model based on the task, instead of forcing every step through the same model. The useful version preserves quality gates: cheap model for narrow inspection, stronger model for ambiguous edits, and no model call when a tool result is enough. The bad version is just cost cutting with nicer wording.

• How does this relate to ai pair programming?

  Felan pushes AI pair programming toward a more engineering-like loop: define the task, expose only needed context, run tools, and check the result. That is less magical than open-ended chat, but usually more useful. The pair is still helpful; it just gets fewer chances to wander.

Best ways to use this research

• Best for: developers who already use coding agents and want a concrete way to ask, “Where are we wasting model calls?”
• Best first artifact: a five-task experiment with a quality gate, baseline run, and lean-agent run. Do not start with a policy document.
• Best comparison angle: compare Felan against your current Claude Code or editor-agent loop on one repeated task class, not across your whole backlog.
• Best caution: remember that local agents inherit host permissions unless isolated. Cost savings are not worth running untrusted commands on your main machine.

Further reading

• Felan — source
• Claude Code — overview
• Claude — Agent
• OpenAI Developers — Codex quickstart

Next step

Pick one boring task your agent does every week and measure it twice: once with your normal flow, once with a leaner context loop. If correctness stays flat and cost drops, you have found the part of the agent workflow worth keeping.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.