Lower AI coding costs by 70% without lowering the quality bar
A capable model guides and reviews the work while a cheaper model implements it. How I use delegation in CTM, and why keeping the lead involved makes the savings possible.
When I ask a coding agent to build a feature, I am asking it to understand what I want, work out how to change the codebase, write the code and tests, and check the result. These are different kinds of work. I want strong reasoning for the design and review, but I do not need to pay the same premium for every implementation step.
The approach I use is to give a capable model the lead role and let it delegate implementation to a cheaper model. The lead works through the problem, gives the worker clear requirements, and reviews what comes back. The worker writes the code and tests, then makes any corrections the lead asks for. That is what I mean by delegation. I use CTM to run these models together and keep track of their work.
What delegation means for a coding task
For example, I can keep Fable as the lead and use Sonnet for implementation. Fable reads the relevant code, works out the approach and writes the requirements and the checks. Sonnet changes the code and writes the tests. Fable then inspects the diff and runs the checks, and if something is wrong the correction goes back to Sonnet. You do not have to move to another provider to try this — two models from the family you already use are enough, and the lead can be the model you already trust to review.
This is based on my own experience using CTM. I looked at 46 tasks where DeepSeek handled most of the delegated implementation. Including the lead’s work, the worker’s work and the corrections, the estimated cost was about 70% lower than having the lead do that work itself. I kept the same review and acceptance requirements.
A tech lead and an engineer
Think about how a tech lead works with an engineer. The lead helps clarify the problem and work through the design. The engineer owns the implementation, including the decisions that come up while writing the code. When the change is ready, the lead reviews it against the requirements and helps resolve anything that is missing. The lead does not have to write every line to stay responsible for the outcome.
I want the same arrangement with coding agents. The worker needs enough context to make good decisions, and the lead needs to stay involved through the review. A detailed plan helps, but it does not remove the need to look at the finished code.
Why paying two models can cost less
The code a worker generates becomes input for the lead to read. Those tokens are billed differently: on Fable 5.1, output costs five times as much per token as fresh input. That price difference is why it can make sense to pay a cheaper model to write a patch and a more capable model to review it.
Published list rates, in dollars per million tokens, as of 21 October 2026:
| Model | Input | Output | Cache read |
|---|---|---|---|
| Fable 5.1 | $10.00 | $50.00 | $0.25 |
| Sonnet 5.5 | $2.00 | $10.00 | $0.10 |
| DeepSeek V4.1 Flash (peak) | $0.30 | $1.20 | $0.006 |
A coding conversation keeps returning to the same background: the requirements, the code already read, and the decisions made earlier. With prompt caching (Anthropic, DeepSeek), the provider can reuse an unchanged beginning of that conversation and charge a lower rate for those repeated input tokens. That is what the cache-read column means.
The lead still pays the fresh-input rate when it first reads new code from the worker. In later rounds, earlier context can qualify for the cached rate when it is reused. DeepSeek’s row uses peak prices; off-peak prices are lower.
What one task's tokens cost
To see how the pricing works, consider a task whose implementation is about 10,000 generated tokens. The lead reads those as new input before writing about 1,000 tokens of feedback. Generating the code costs $0.50 on Fable 5.1, $0.10 on Sonnet 5.5 and $0.012 on DeepSeek V4.1 Flash. Reviewing that patch on Fable 5.1 costs $0.10 for the 10,000 input tokens at $10 per million plus $0.05 for the 1,000 feedback tokens at $50 per million, so $0.15 altogether.
I have included DeepSeek in the chart because it takes the same idea further: the implementation costs less again. I’ll come back to what happened on whole tasks in the DeepSeek comparison below.
In this example, Sonnet’s code generation plus Fable’s review comes to $0.25, compared with $0.50 for Fable to generate the code. That leaves room to pay for a review and still spend less on this part of the task. To understand the overall saving, I also need to count planning, context, testing and corrections. That is what the whole-task comparison below does.
The tech lead stays involved
A design review happens before the code exists. Once implementation starts, the engineer still has to handle edge cases, work with the existing code, and decide what to test. A tech lead who helped with the design comes back to review those decisions. I expect the lead model to do the same.
When a worker reports that it is done, the lead should inspect the changes and check the evidence. Did the implementation meet the requirements? Do the tests cover the failure cases? If something is missing, the lead sends the work back with a specific correction and reviews the updated result. Accepting the worker’s summary without checking the work skips this responsibility.
The analysis of my sessions showed why this matters. About one in four of the Sonnet implementations reviewed by Claude leads contained a major issue that review caught. That is a large enough share to treat review as part of the work rather than a formality at the end of it.
It also rules out one tempting shortcut. Claude Code's Opus Plan Mode — the opusplan setting — uses Opus for planning and switches to Sonnet for execution (model configuration). If I use Opus to make a plan, hand implementation to Sonnet and accept whatever comes back, I have dropped the review step. That does not meet the standard I want for code I ship. Choosing which model plans and which model executes is only part of organizing the work; the review still has to happen after the implementation.
Why corrections can still be inexpensive
Finding a problem does not mean the expensive model has to take over the implementation. I keep the same division of responsibility: the lead explains what is wrong and what needs to change, then sends the work back to the same worker. The worker writes the fix, and the lead checks it again.
Both sessions already have useful context by this point: the requirements, earlier code and previous discussion. When that history is reused and the provider finds a matching cached prefix, those repeated input tokens get the lower rate. For example, reading 10,000 cached tokens on Fable 5.1 costs $0.0025, compared with $0.10 for 10,000 fresh input tokens. The lead and worker each reuse their own history.
The new writing still matters, but the expensive model can keep it focused. A 200-token correction from Fable costs $0.01 in output. If DeepSeek then generates a 2,000-token fix, that output costs $0.0024; generating those same 2,000 tokens on Fable would cost $0.10. This is why I want the lead to give specific feedback and let the worker do the rewriting.
The lead also pays to read the revised code and verify the fix. That returned code is fresh input, whether it is a small diff or a complete file. Worker inputs and any further rounds count too. The figures above show individual parts of the cost; the whole-task comparison below counts the lead, workers and corrections together.
That is the useful result from my own experience: the savings did not require every first attempt to be perfect. The lead could find problems, send them back and check the fixes while the cheaper model continued to do the implementation.
The whole task, with DeepSeek
DeepSeek V4.1 Flash is much cheaper per token than either Claude model in the table above, and the same division of work applies: the lead plans and reviews, the worker implements. The question I wanted answered was whether the extra review and correction a cheaper worker may need would erase the saving. The estimate below counts the whole task — planning, the worker's run, review and corrections, with the same work done on the lead alone normalized to 100. Corrections cost both the lead's feedback and the worker's follow-up work.
| Delegation group | Tasks | Cost when estimated lead-only = 100 |
|---|---|---|
| Mostly Sonnet subagents | 28 | 41 — about 59% lower, estimated |
| Mostly DeepSeek workers | 46 | 30 — about 70% lower, estimated |
The Sonnet and DeepSeek rows cover different groups of tasks. Each group is compared with the estimated cost of doing its work on the lead model.
What I do now
The lead writes the requirements and the checks: what the change has to do, and how we will know it works. The worker gets only the context that task needs rather than the whole conversation, since a long history is read again on every call. The lead then reviews the result and owns accepting it — I count a task as finished when the lead has read the change and run the checks, not when a worker reports success.
To understand whether delegation is helping, I count the lead, the worker and the corrections together. I also look at the effort required to get an acceptable result. For a small edit, writing a brief and reviewing another model’s version may be more work than doing it directly. I would start with a task large enough to benefit from delegation and clear enough to check.
How I estimated the savings
- Costs are list-price estimates over one developer's sessions, not invoices, and not a controlled experiment: the tasks are nonrandom and were not selected for comparison.
- The token example isolates code generation and review using selected token counts. The task estimates include the recorded lead, worker and correction costs.
- Cache reuse requires a matching prefix that the provider still retains. Creating a cache may carry a separate charge; misses and newly generated tokens use their applicable rates. A long pause or a changed prefix can reduce the benefit. The correction figures illustrate individual cost components rather than a measured task total.
- The whole-task table assumes the lead alone would have needed the same number of steps as the worker; the sensitivity range assumes half to twice as many — 29–52 for the mostly-Sonnet group and 18–45 for the mostly-DeepSeek group. That range moves with the assumption rather than describing sampling error.
- Review labels came from one LLM judge with eight human spot checks, over a mix of tasks.
- Human time and other non-API costs are excluded, and edit volume includes churn, so it is not a measure of quality.
Try it in CTM
In CTM, I can choose the lead model and delegate model separately. That lets me keep a lead I trust for design and review while trying different models for implementation. CTM keeps the workers under the lead session, so I can follow their progress, read their reports and inspect the changes as the work comes together.
The way to judge it for yourself is to take a few representative tasks, cost the whole thing — lead, worker and corrections — and weigh that against the quality you need from the result. The walkthrough below takes one task from requirements to accepted change.
Want to try it on one task?
Walk through your first delegated task in CTM →