A conversation about an agent's cost almost always veers toward tokens: how to count them, where to trim, which cheaper model to take. The instinct is understandable but misleading - it optimizes the unit of spending instead of its cause. Tokens are not spent on their own; they are spent by iterations, and the number of iterations is set by how much unresolved uncertainty is left in the task.
The naive move is to save on the input. Take a weaker model, trim the context, run the check less often - on paper each of these actions lowers the bill for a single turn. In practice it more often raises their number: understood worse, did worse, asked again, redid. Saving on a turn turns into extra turns, and the total spend grows exactly where you tried to cut it.
The naive economy breaks on the fact that the main driver of cost is not the price of a turn but the count of turns, and that is driven by uncertainty. Spending grows from wide context, from repeated investigation of the same thing, from a strong model where a simple one would do, from subagents and parallel variants launched without need. All these line items share one thing: they multiply work that was not narrowed in advance. It is expensive not to think but to guess many times over. The practical takeaway is one: the bill grows not so much where an expensive model is chosen as where the task is posed so that it must be walked through twice and three times.
Hence the reversal of strategy: what should be cut is not verification but uncertainty. A small task instead of a vague one, a precise reproduction instead of "it fails sometimes", a saved plan instead of a spoken one, narrow commands instead of walking the whole repository - each of these techniques cuts not the cost of a single step but the very number of steps. Verification stays in place: to cut it is to save on the one thing that tells the done from the claimed.
Before an expensive turn it helps to ask it one question: which unknown does it remove. If there is no answer, the turn investigates at random, and its cost almost certainly returns as a second pass. If there is an answer, you are paying for a specific removal of uncertainty, and the result of that turn is worth saving. The question "what will I learn" turns spending from a bet into a deliberate purchase of knowledge. And the reverse: a turn with no clear answer to that question is most often a signal to step back and narrow the task, not to launch an investigation in the hope that it stumbles onto the needed thing on its own.
The second technique is to save an artifact after each stage. The cause found, the plan agreed, the diff ready, the test-run result - everything that took work is fixed so that the next session does not buy the same investigation anew. It is precisely the re-purchase of already-obtained knowledge that is the most invisible line item: an agent without saved context honestly investigates from scratch what you already worked out yesterday.
A dated caveat about the claimed efficiency belongs here. Devin Local is described as "up to 30% more token-efficient" on most tasks compared with Cascade, with an emphasis on prompt caching. This is a vendor claim without an independent benchmark: a useful reference point, not a guarantee for your specific task and model. The real cost is shown not by that figure but by the usage page - and billing is arranged so that unsuccessful messages consume no spend.
This does not mean you cannot save on the model and the context at all. On a simple, well-outlined task a light model and narrow context are exactly the right choice, and taking a heavy model there is the same mistake in reverse. The point is not to be always expensive or always cheap but to match the power of a turn to the uncertainty it removes: excess is as wasteful as a shortfall that breeds redoing.
You must check cost management by fact, not by the feeling of saving. Look at usage before and after, not at the presumed price of the model; count how many turns went into the task and how many of them were repeated investigation of the already known. A good sign is that the number of iterations falls from task to task, because the stock of saved artifacts grows. A bad one is that each new session starts from scratch and the total bill is unrelated to the real complexity of the work.
The typical failures lie on both sides. On one - false economy: a cut check and a weakened model produce the redoing that costs more than what was saved. On the other - wastefulness: wide context, a heavy model and parallel branches on a task where one narrow one would have sufficed. The sign of both is the same: cost was managed at the level of tokens rather than at the level of uncertainty and iterations. Remove the unknown with cheap moves, save what you obtained, and the bill adds up on its own.