A few months ago I became convinced my AI assistant was bleeding money through incompetence. It felt true. Sessions ran long, things failed, and th...
For further actions, you may consider blocking this person and/or reporting abuse
The 1.5% number for recovery turns is the result I wish more people got to before deciding what to optimize. I spent a month convinced my agents were burning money on retries and bad tool calls before I actually measured it. Same thing. The failures were real but they weren't the bill.
The re-read tax hit me differently because I run long-lived agent sessions that accumulate context across dozens of tool calls. I had one session that stayed open for three days and by the end every routine turn was dragging 6MB of conversation it didn't need. Archiving that session and handing off a one-line summary dropped my weekly spend by something like 15%. No prompt changes, no model swaps, just closing a tab.
Your 40/60 split between agent mistakes and environment failures is the part I'd push people to replicate. When I broke mine down the environment side was almost entirely timeouts from web pages that never reach idle and file locks from other processes. You can't prompt your way past a site that deliberately never finishes loading. Separating those two buckets made the agent-side fixes a lot simpler because I stopped trying to solve problems that weren't the model's fault.
Fifteen percent from closing a tab is the same shape as my three sessions holding 20% of a week's burn — the expensive sessions are the ones that feel too valuable to close. Your one-line-summary handoff is the practice I landed on as well: archive the transcript, hand the next session a summary, and let the file hold the memory instead of the context window. The matching environment bucket is almost reassuring — never-idle pages and file locks are the same two offenders here, and you cannot prompt your way past either.
Your 80% number — the "re-read tax" from long sessions — is the same failure mode I hit building a retrieval pipeline: long context silently accumulates, every turn re-reads it, and nothing alerts because nothing errors. I catalogued this in my own system as the "absent answer" problem — a cost that never shows up on any dashboard until you build the tool that measures it.
brainbootdev's question about the ratio drifting is the right one, and I'd push it further: the ratio itself is a third state. If the 40/60 split drifts toward environment-heavy, that means the infrastructure is degrading — more external tools failing, more pages not rendering. If it drifts toward agent-heavy, the agent is degrading — more stale file references, more hallucinated paths. The ratio is a health metric for both the agent AND the environment, not just a cost breakdown.
One thing I'd add: your scanner runs locally and costs zero tokens, which means it can measure every week forever without itself becoming a cost item. That's the discipline: measurement infrastructure should never be a line item in its own report. The moment your auditor costs more than the audit, you stop auditing.
"Measurement infrastructure should never be a line item in its own report" is the sentence I would paste over the dashboard. The zero-token parse was an accident of locality — local transcripts, local script — but you are right that it is the property that makes a weekly cadence sustainable, and the auditor quietly becoming a cost item is how most observability stacks die. The drift-direction read is the part I am taking: environment-heavy drift means the tooling is degrading, agent-heavy drift means the context is going stale, and those have opposite fixes.
The 1.5 percent number is the useful part of this post, and it is the kind of result that only shows up when measuring is free. When an audit costs a day of work you run it once, get a scary anecdote, and optimize the thing you happened to look at. When it costs zero you run it weekly and discover the scary anecdote was rounding error. That reframes where to spend effort: 729 failures over 45 days is a quality problem worth fixing on its own terms, but it is not a cost problem, and treating it as one would have bought you a 1.5 percent ceiling. Curious whether the remaining 98.5 percent broke down mostly into context re-reading, or into genuinely long reasoning turns - those two have completely different fixes.
Mostly re-reading. The same audit put the re-read tax at roughly 80% of total spend — the worst single session had burned 240M cache-read tokens across 665 messages, and three sessions like it held 20% of one week's entire burn. I did not price long reasoning turns separately, because in a transcript "thinking" and "re-reads the history while thinking" are hard to isolate. But the fixes are different exactly as you say, and the evidence pointed almost entirely at the one you fix by closing tabs.
The 40/60 split is the part I would want other people to copy. Most cost postmortems stop at "the model made mistakes" because that is the only bucket the vendor dashboard can show you. Separating genuine agent error from environment latency changes what you do next: the first is a scaffolding problem, the second is a timeout policy problem, and they have almost nothing to do with each other.
The thing I trust most here is that you went looking for a big number and published the small one. 1.5% is an unrewarding headline, and that is exactly why the rest of the piece reads as credible.
Question, since you say measuring is now cheap enough to do weekly: has the 40/60 split held steady across the 45 days, or does the environment share move around week to week? If it drifts, that ratio is arguably a better health metric for the setup than the absolute spend is.
Honest answer: 40/60 is the aggregate across the whole 45-day window — I have not cut it by week yet. That cut is the obvious next run now that the parse is free, and your scaffolding-problem vs timeout-policy split is exactly why it matters: a drifting ratio tells you which of the two is degrading, and the absolute spend never will. I would rather run the cut than guess at it, so that is this week's audit.
An AI agent bleeding money through incompetence is usually a retry-loop or an unbounded context-window problem, not a model-choice problem
The fix is almost always capping retries and trimming what gets sent on every call, not switching to a cheaper model
Half of this matches my measurements and the other half inverts them. Capping retries was the fix I expected to find too, but pricing every failed tool call across 45 days put retry-loop waste at 1.5% of spend — real, and not the bill. The unbounded-context half is exactly where the money was: roughly 80% went to long sessions re-reading their own history, so trimming what gets sent every call is the intervention that moved the numbers. Cheaper models were only for the scheduled routines, where the cheapest model that can do the job is free money — that was a scheduling fix, never the diagnosis.