Why your AI usage runs out in minutes, and what is quietly eating it

I hit ninety percent of my weekly usage on a Tuesday I had barely worked. No error, no incident, nothing to open a ticket about. I had run a couple of small jobs, skimmed the output, and closed the laptop for lunch. When I came back the meter said I was nearly out, and I could not point at the thing I did to cause it.

If your AI usage runs out faster than your work explains, the cause is almost always structural, not behavioral. You are not paying for what you typed. You are paying a fixed floor of tokens that your setup loads before your first word, on every single request, and one wrong setting can quietly switch off the discount that hides how big that floor is. Shorter prompts will not fix it. What fixes it is inventorying what loads before your first token, deleting what you are not using, and watching the settings that change your cost without telling you.

why does my AI usage run out so fast?

Because your prompt is the small part of what leaves your machine. Every time an agent talks to a model, it re-sends the whole context: the harness system prompt, the tool schema for every connected server, whatever instruction file governs the repo, and the running transcript so far. Your actual request rides on top of that pile. When you are vibe coding past the toy stage, with a standing set of agents instead of one chat window, that floor rides every single turn and multiplies with fan-out, because each subagent pays its own bootstrap before it does any work.

The numbers are worse than they feel. A harness can carry tens of thousands of tokens of system prompt and tool definitions before your prompt is even appended. Each connected tool server tends to add somewhere around 1,000 to 1,400 tokens of schema per request, whether or not you call it. A fat instruction file can quietly add around 20,000 tokens to every request in that project. None of it appears as a line item anywhere. It is just the cost of saying hello, paid again on every message, and it is the number that empties your week while you are looking at your prompt wording.

the setting that turned off my cache without telling me

Prompt caching is supposed to make that floor cheap. The first time the big static block goes up you pay a cache write, and after that you pay a small read for the same block, as long as it stays byte-identical and the cache has not lapsed. That is the mechanism that is supposed to save a vibe coder running a standing fleet from paying full price on the same 40,000-token preamble a thousand times a day.

Then I turned on the model's extended thinking mode for a class of harder jobs, and my usage climbed. No error. No warning. The jobs succeeded, the output was better, and the meter kept moving faster than the work did. It took me an embarrassing while to trace it. Turning on thinking changed the shape of the request just enough to silently invalidate the cache, so every request paid the full write again instead of the cheap read. The setting that helped the reasoning had quietly deleted the discount, and nothing in the interface said a word about it.

That is the shape I now go looking for first. Not the happy path, the failure surface. A setting that changes your cost with no error, no log line, no red text, is exactly the kind of thing that eats a week of usage while you sit there editing your prompt, sure the problem is something you said. Build the failure mode into your mental model before you trust the happy path, because the happy path is the part that was always going to work.

what actually survives prompt caching?

Three costs survive, and they are the ones people forget when they assume caching has them covered.

First, the cache write. You re-pay it every time the cached block changes or the cache lapses, and these entries expire on a short timer. Change one line of your instruction file, or let the agent sit idle past the window, and the next request pays full freight again. Anything that mutates the preamble, including a capability toggle like the one that got me, resets you to zero.

Second, the read, multiplied by request count. A cheap per-request read is still real money when your agent talks hundreds of times in a session and each subagent pays its own. Small times enormous is not small.

Third, and this is the one that matters most, the context window itself. Caching discounts the input you send repeatedly. It does nothing about how much you send. A 40,000-token floor is a 40,000-token floor whether it is cached or not. You still carry it through every turn, it still counts against your window, and past a point it crowds out the room the model has to actually think. So when someone asks whether prompt caching lowers the bill, the honest answer is: partly, and only on the axis you were probably already fine on. It never touches the window, which is the axis that quietly runs you out.

how do I lean the window instead of the invoice?

The instinct when usage spikes is to treat it as an invoice problem. Find the cheaper plan, wait for the credit, argue with the reseller. That is the wrong surface. The invoice is downstream of the window, and the window is something you control directly, today, without anyone's pricing page. Lean the window.

Start by reading one real request at the boundary, the way it actually leaves your machine, once. Add up the harness floor, every tool server's schema, the instruction file, and the standing transcript. That single measurement usually finds the whole problem, because the cost model of AI orchestration is dominated by what you send before your first token, and almost nobody has ever looked at it.

Then delete. Disconnect the servers you are not calling this session. Split the 20,000-token instruction file so only the slice a job needs rides that job. Trim the harness config down to the surface you actually use. And watch the settings that move cost silently, like the thinking toggle that killed my cache: when you flip a capability, measure the next request instead of assuming it was free. Only after all of that does the plan you are on become the right thing to look at.

This matters more this month than last. A lot of the promotional credits that have been masking the metered price of AI coding run out at the end of August, which makes September the first true-cost month for anyone who built their fleet math on the discounted baseline. When the credit disappears, the cost that stays is the window, because no credit, cache discount, or reseller markdown touches how many tokens you carry into every turn. The vibe coders who leaned the window in August will barely feel it. The ones who leaned on the credit will feel all of it at once.

The failure mode I see most, and lived myself, is optimizing the prompt while the setup eats forty percent or more of the window every turn, silently, with no error to catch. You can shave your wording all day and never touch the multiplier. The config you added is the bill you pay.

If you are moving from chat-built scripts to a standing automation that has to hold in production, and you want a second set of eyes on where the tokens actually go before the credit runs out, /work-with-us.

questions that keep coming up

Why is the same model costing me twice as much as last month? Usually it is not the model. Either the cache stopped applying, because a setting changed or the cached block is no longer byte-identical, or your context floor grew, because you added a tool server or the instruction file got fatter. Measure one request today and compare it to what you think it should be. The gap is almost always in the preamble, not the prompt.

Which harness uses fewer tokens? The one that sends less before your prompt. That is measurable at the boundary in about ten minutes, so measure the two you are choosing between on the same real job rather than trusting a comparison chart. The floor is the differentiator, and it is the number nobody publishes.

Does a shorter prompt help? Rarely, once you are past the toy stage. Your prompt is the small part of what leaves your machine on each turn. The floor is the big part, and you cut the floor with configuration, not wording.

The meter did not lie to me that Tuesday. My config did, quietly, and I had never once asked it what it cost.