The Terminal Bill Before Lunch: Agentic Cost Mistakes
Cache writes are the line item that surprises you first
The first surprise in a full day of agentic coding usually arrives as one line in the usage report: cache writes. It is easy to assume that a long context becomes nearly free once it has been cached, and that assumption quietly doubles the number on the invoice. Cache reads are discounted, but the act of writing the cache still costs real tokens, and an agent that keeps rewriting its working context pays that fee every time it does.
Most of these mistakes are arithmetic rather than architecture. People estimate by multiplying output tokens by a headline rate and then stop, which ignores the fact that a coding agent reads far more than it writes. If a session pushes sixty thousand tokens of context into cache on the first turn and then reads that cache back on every later turn, the read side dominates the run, while the write side is the toll you pay for starting a new session at all.
Fluxo bills per real token, including cache reads and cache writes, with no monthly fee, so the figure you compute is the figure you pay. One key and one base URL, https://api.fluxorelay.com, sit in front of Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok and more.
- Track cache write tokens separately from cache read tokens in every estimate you build.
- Assume each fresh session pays a full context write before it pays for anything else.
- Price the first turn of a session differently from the twentieth turn of the same session.
Letting the agent re-read the whole repository every turn
The second mistake is letting the agent re-read the entire repository on every turn. A new feature branch, a wide file search, and a fresh build log can inflate a single turn from three thousand tokens to ninety thousand, and the session never recovers because the model keeps the whole pile in its context window.
Long logs are the usual culprit. A full test suite output is rarely more useful than the failing assertion, yet agents get pasted the entire stream again and again. The fix is discipline in what you hand over: point at specific files, paste the smallest relevant error, and ask for a summary instead of a transcript.
Sessions themselves need hygiene too. After a large refactor, the old assumptions still sit in the context and cost tokens on every subsequent read. Restarting with a compact state, a short plan, and the current diff is usually cheaper than carrying an entire day of history forward.
- Give the agent a short list of relevant files instead of a whole repository dump.
- Replace long build logs with the failing block and a single summary sentence.
- Restart the session after a large refactor so stale context does not follow you around.
Paying frontier prices for mechanical edits and renames
The third mistake is paying frontier prices for mechanical work. Renaming a symbol across twenty files, updating an import map, formatting a changelog, or writing boilerplate tests does not need the same reasoning power that just designed your retry strategy.
Concrete routing helps here. Keep Claude Opus 5.5 for the hard architectural call and the tricky concurrency bug, and send the routine pass to Claude Haiku 4.5, which handles the mechanical edits at a fraction of the per-token cost while the heavier model stays idle.
The switching cost is lower than it looks, because the same key and base URL work in Claude Code, Codex, Gemini CLI, and any OpenAI SDK. You change a model name in one config file, not your workflow, and your editor and terminal stay exactly where you live.
Cheaper models also make the previous mistake less expensive to explore, since you can afford to let an agent read a little more before you tighten the prompt. That is the practical reason to keep two or three models on call instead of a single default that answers everything.
- Route mechanical renames and formatting work to a cheaper model before you route anything else.
- Reserve your heaviest model for design decisions and bugs that need real reasoning.
- Change the model name in one config file instead of rebuilding your toolchain.
Estimating a full day from benchmarks instead of measurements
The fourth mistake is estimating a full day of agentic coding from benchmark numbers or from one impressive run. Benchmarks do not include your repository, your build times, your test suite, or the way you prompt when you are tired at six in the evening.
Measure one real day instead. Start a session in the morning, keep your normal tools, and record input tokens, output tokens, cache reads, and cache writes at every stop. By the end of the day you know the cost of your actual habits rather than an average that nobody on your team lives.
Then extrapolate honestly. Multiply the measured day by the number of days you expect to run agents, add a margin for the weeks when a migration touches everything, and split the total by task type so you can see which work is expensive and which work is cheap.
- Record input tokens, output tokens, cache reads, and cache writes for every session you run.
- Multiply one measured day by the number of agent days you actually expect.
- Add a margin for migrations, refactors, and the weeks when everything is on fire.
Counting only successful runs while retries keep billing
The fifth mistake is counting only the successful runs. A flaky tool call, an agent that loops on the same failing test, a retry after a truncated response, and a compaction pass that rewrites the context all bill real tokens, and none of them appear in a happy-path estimate.
Assume a failure rate and price it in. If one run in five needs a second attempt at roughly the same context size, your true daily cost is not the single-run figure but a fifth more, plus the tokens spent discovering that the run had failed at all.
Background sessions deserve the same scrutiny, because a long-running agent that checks the build every ten minutes reads cache continuously and writes it again whenever its state changes. Those quiet minutes are still billable minutes, and they add up faster than the dramatic runs do.
Invited teammates pay the same per-token way, and you earn a referral share when people you invite pay, which turns a shared estimate into a small and steady offset. If you would like to measure a real day against real prices, create a Fluxo account and run one session the way you normally work.
If any of the numbers look odd once you compare them with your own day, you can leave a note on the contact page after signing in.
- Assume one run in five fails and needs a second attempt at the same context size.
- Count the tokens spent discovering a failed run, not just the tokens spent retrying it.
- Watch background sessions that rebuild or test every few minutes and bill continuously.