What one finished feature costs in tokens

Why the monthly bill misleads

Usage arrives per session, per day or per month. A feature doesn't fit any of those. It spans a planning session, a build, a failed check and a second build, a review that sent it back, a fix and a second review. Each of those sessions looks reasonable on its own. Added up, the feature may have cost several times what its final build did.

A session view also hides the work that never shipped. A run cancelled halfway, a branch that was abandoned and an attempt that stopped on an error all spent their tokens, and none of them produced anything. In a monthly total they are invisible. Per feature, they are often the largest line.

Where the tokens go

Context comes first. Before an agent changes anything, it reads: instructions, docs, the code around the change, earlier output. That reading happens again in every session, and in many runs it is the largest single part of the cost. It is also where cost hides best: a long instructions file loaded at the start of every session feels free because nobody watches it being read, yet it is paid for on every task, including the ones it has nothing to do with.

Exploration follows: reading files to find the right place, running commands to see how things behave, trying an approach and backing out of it. Some of that is necessary. Much of it repeats what an earlier session already learned and didn't write down.

Then comes rework. A failed check, a send-back or a redo each repeat the context and the exploration before they repeat the change. One send-back can cost as much as the build it corrects.

Two details change the picture. Reading the same context again from a cache costs much less than reading it fresh, so the way sessions are arranged affects the bill. And the model chosen for each step matters: prices differ widely between models, and not every step needs the strongest one.

Measure per item, not per session

To see what a feature costs, record usage where it happens and tie it to the work it served. For each agent session, keep the input and output tokens, the cache reads, the model and the wall-clock time. Tie the session to the step of the workflow it ran, the run to the item it served, and the item to its milestone. Then add up.

That gives you cost per item, per milestone, per workflow and per model. Call it estimated, because prices change and caching varies. An estimate you can attribute is worth more than an exact total you can't.

Attribute the usage when the work happens. Reconstructing it later from a monthly export means guessing which session belonged to which feature, and the guess tends to be wrong in exactly the cases that matter: the retries and the abandoned attempts.

Look closely at the spend on work that never shipped. It shows where runs start without what they need, where checks fail late, and where items were picked up before they were ready.

What lowers the cost of a feature

Smaller context per task. Hand each step the rules and docs that apply to it, not everything you have. That cuts the largest cost directly, and it tends to improve the result as well, because the agent's attention isn't spread over material it doesn't need.

Deciding before building. A wrong approach caught in a plan costs one short session. Caught in review, it costs the build, the review and the rebuild. Approving a plan before the build is the cheapest review you can buy.

Failing fast, and choosing the model per step. Checks that run inside the build loop stop a failing attempt while it is small, instead of after a person has looked at it. A cheaper model can gather information, and a stronger one can take the steps where judgement matters.

Fewer abandoned runs. Pick up only work that is ready: nothing blocked, nothing waiting on an item it depends on. A run that starts on a half-defined item is the one most likely to be thrown away.

Read cost next to outcome

Cost on its own pushes toward cheap and wrong. Read it next to what the money bought: the first-pass rate, how often work is sent back, how long runs wait on a person and how each workflow tends to end. A workflow that costs more per run but rarely needs a redo can be the cheaper way to finish an item.

The same view shows where waiting, not tokens, is what slows a feature down. A run waiting for an approval spends no tokens, but the feature isn't finished until someone answers.

Compare like with like. A bug fix and a new feature cost different amounts for good reasons, so compare workflows on the same kind of work and items of a similar size. Trends over weeks say more than any single number: whether cost per item falls as rules get sharper, and whether rework falls once plans are approved first.

Where ctxflows fits

In ctxflows, you see what every agent session spent, in tokens, cache use, model and time, and every run belongs to the item it served. Analytics adds it up: estimated cost per item, milestone and workflow, by model, including the spend on work that never shipped. Beside it you see the first-pass rate and rework per workflow, the time runs wait on you and how each workflow's runs end.

You can make the review of cost a workflow of its own. A scheduled workflow reads past runs and their cost, notes in a dataset what slowed or stopped them, and proposes changes to the workflow that you accept or dismiss. And the context step before each node keeps the reading small, handing each task only the rules and records that apply to it.