Save on Completing the Task, Not on Calls

A cheap call that leaves the task undone is pure waste. Downgrading sub-agents is the biggest lever.

Beginners try to save cost by watching "how many times AI was called." But the real unit of cost is "how much it took to complete a task." A cheap call you send back and forth many times costs far more than a pricier one that lands the first time.

After reading, you should be able to answer:

Why is "cutting the number of calls" the wrong direction for saving?
How does "saving on completion" land concretely?
What's the single biggest cost lever?

Why cutting calls is wrong

Cheap call but bad result is the priciest: one call is cheap, but redoing it over and over costs more than one good call
Squeeze the prompt until quality drops, and the tokens you saved get paid back in rework copilot-cost
Optimize with "complete the task" as the denominator: if the task isn't done, every cent spent on it is waste

Saving on completion

Write right the first time: enough context, clear acceptance criteria, less rework—far more effective than "fewer calls"
Batch in one round: what can be concurrent or packed into one round, don't split into ten round-trips
Let verification catch the error fast: the sooner an error is found, the less rework, the more you save

The biggest lever: downgrade sub-agents

For clearly-scoped subtasks, use a cheaper/smaller model; use a strong model to back the main task—this is the single most impactful saving google-patterns
Don't send every simple task to the strongest model; don't use a cleaver to cut a bean
Allow manual override: on critical moments, use the strongest

The second lever: cache hits are an architectural property

The essence of prompt caching is "only the unchanged prefix gets re-billed." So whether it saves money does not depend on which flag you turned on, but on whether the request's shape is stable: system prompt, tool definitions, and static documents sit at the front and never move, and only conversation content is appended. If volatile content (timestamps, a system prompt rewritten every round, a randomly ordered tool list) sits inside the prefix, there is nothing to hit — this is a property of your request-assembly code's structure, not a tuning parameter anthropic-cost-performance.

Treat it as an architecture decision, not a savings switch: the composition, order, and stability of the prefix are decided when you write the first version of request assembly, not after the bill arrives. This is the same idea as "saving on completion" in another form — reloading the entire prefix every time and paying for rework are the same waste under two names.

Spend where it counts: pick the model by upside

The dual of saving is knowing when to pay for the most expensive model. A frontier model can cost 100x more and buy one more notch of intelligence — whether that pays depends on the task's upside a16z-cascading-loops:

Tasks with unbounded upside (research, a judgment that could change direction): an extra notch of intelligence can be worth disproportionately much — the frontier model is the rational pick
Tasks with bounded outcomes (reconciling accounts, format compliance): "right" is just "right"; it never gets "100x right" — a cheap model with enough capability is enough
The test is the upside, not verifiability; and the conclusion has a shelf life — the frontier moves with every release every few weeks, so re-run the assessment on real tasks regularly

Once "save what should be saved, spend what should be spent" is thought through, vibe coding's ledger stops bleeding.

With cost held, finally enter the closing chapter of "getting better": the knowledge flywheel and sustainable collaboration.