What Claude Code taught me about agentic coding costs

By early 2026, I was using Claude Code regularly. Delegation was no longer an occasional experiment. It had become part of normal development, which exposed a question the experiments had hidden: I could tell whether I accepted the result, but not what the whole attempt had cost.

Headline prices did not answer that question. A short, bounded session and a long session full of corrections could produce similar-looking changes while consuming very different amounts of usage and attention.

I noticed that pattern during repeated use rather than in a preserved bill or token export. I did not measure equivalent sessions or record a cost per change. What I had was a practical warning: as a session accumulated context and correction rounds, the visible price of one prompt became a poor guide to the cost of the work.

The prompt bloat problem

My working explanation was prompt bloat. System instructions, file excerpts, tool results, and conversation history accumulated during a session. Longer sessions appeared to carry more of that material into later turns, particularly after the agent had taken a wrong direction and needed more explanation.

I could not see exactly how Claude Code cached, compacted, or discarded that context. Seeing an earlier file influence a later answer did not prove that the tool had performed another file read. It showed that the session had become harder to reason about: more context was involved, more corrections had been made, and I had less visibility into the cost of reaching an acceptable result.

Correction rounds were especially noticeable. An answer that looked fine after several attempts could hide more usage and supervision than an equivalent answer produced in a short session. That made accumulated context a cost risk worth controlling, not a billing mechanism I could claim to have measured.

Context trimming as a manual response

My first response was context trimming. I kept tasks narrow, exposed only the files I expected to matter, and started a fresh session when the correction chain became longer than the task justified.

This did not prove that I had reduced the bill. It gave me a way to bound the experiment. Too little context could still cause mistakes and retries; too much made the session harder to inspect. The useful question became whether each piece of context improved the chance of an accepted change.

That was the practical rule I could apply at the time: define a bounded task, begin with the smallest plausible context, and restart rather than preserve a confused conversation by default.

What the visible price left out

The visible price was only one part of the cost. The rest appeared in the work around it:

• another attempt after a failed delegation;
• reconstructing or carrying context across correction rounds;
• human attention spent checking whether the agent was drifting; and
• deciding when to trim context, restart, or intervene.

A tool with a lower token price could still cost more per accepted task if it needed more attempts or supervision. That was a hypothesis from repeated use, not a benchmark. I had no preserved comparison of sessions with and without context trimming, and readers cannot independently verify the private development work behind the observation.

Token efficiency is a workflow design problem

The engineering mistake was familiar: measuring the cheapest visible unit while ignoring the behaviour of the whole system. Token prices mattered, but so did task boundaries, context selection, correction rounds, verification, and human intervention.

Prompt optimisation could reduce the size of one request. It could not tell me whether the request led to accepted work, whether a smaller context caused another retry, or whether a cheaper model needed more correction. The workflow determined how those costs combined.

Cost per accepted work

I needed to evaluate cost per accepted task rather than cost per token or subscription price alone. That meant starting with a definition of completion, then accounting for the attempts, corrections, verification, and human attention required to reach it.

I did not yet have a controlled comparison across tools. Until I did, the useful response was to keep tasks bounded, limit initial context, and restart sessions that had become dominated by correction. Those choices did not reveal an exact cost, but they stopped the headline token price from standing in for one.

The comparison I needed would have to use real development work, shared acceptance criteria, and the full route to an accepted change. Product pricing pages could not supply that answer.