I Spent Weeks Rationing My AI Usage Instead of Using It. Then Fable Burned a 5-Hour Session in 5 Minutes.

The real waste wasn't running out of runway — it was the hours I quietly spent trying not to waste it, a sunk-cost habit dressed up as discipline. The moment I stopped rationing and pointed Anthropic's priciest model at real work, an entire 5-hour session vanished in about five minutes. That's a preview of something every AI subscriber is going to hit, once the current era of dirt-cheap frontier intelligence stops being subsidized.

For weeks before any of this, I'd fallen into a habit I didn't clock as a problem until I was writing it up: quietly rationing my Claude Code usage. Holding off on ambitious asks because I wasn't sure they were worth "spending" a session on. Breaking tasks into smaller pieces than they needed to be. Watching the meter more than I was watching the actual goal. That's a sunk-cost trap wearing a budgeting costume — I was spending real attention managing a number instead of just doing the work the number was supposed to enable.

Then Anthropic shipped Fable, its priciest, most capable model, and I decided to stop rationing and actually use what I was paying for. I pointed it at something I'd been meaning to do for weeks: build out a real research library — drug and supplement timing, interactions, raw-vs-cooked nutrient science, all citation-verified against primary sources — to feed a health project I'm building. Legitimate, useful, exactly the kind of deep-but-tedious work AI is supposed to be good at absorbing.

One entire 5-hour session was gone in about five minutes of real work. Not because I wasted it — because Fable did exactly what I asked, at frontier prices, faster than I had any intuition for. Weeks of careful rationing, undone by five minutes of actually using the thing.

The Rationing Habit — and What I Finally Did Instead

I asked Claude to research 60 topics and fact-check every claim against a real, independently verifiable source before any of it went near a page I'd publish:

That's not a small ask, and I said yes to doing it the expensive-but-correct way: no fabricated citations, ever — I've been burned by that before.

That wasn't even the whole list. In the same window I was also chasing a genuinely ambitious, arguably ridiculous side-goal: trying to model how AI itself is going to transform the stock market — which sectors get hollowed out, which get supercharged, on what timeline — for a separate research project. Two different kinds of hard problems, both legitimate uses of frontier reasoning, both happy to eat as much compute as I'd hand them.

Claude Code has a tool for exactly this. You describe the shape of the job and it spins up a swarm of sub-agents — one per research topic, then a second wave to adversarially verify each one, then a synthesis pass to pull it all together into something usable. On paper, this is the dream: instead of me grinding through 60 topics one at a time, dozens of instances work in parallel and hand me a finished library.

It worked. The research is genuinely good — every one of those 60 entries independently source-checked, several twice. But getting there cost a lot more than I expected, and it cost it fast.

Where It Broke

Two separate times, mid-run, I hit a wall. The tool itself reported it as "You've hit your monthly spend limit" — which turned out to be wrong. What I'd actually hit, both times, was the ordinary session limit: Claude Code runs in rolling 5-hour blocks, and a heavy enough burst of work can exhaust an entire block in minutes, not hours. The error message named the wrong ceiling, but the ceiling was real either way.

That's the mechanic worth sitting with. It's not that I ran out of runway for the week — I had days of it left. It's that a single 5-hour session can vanish in minutes if you point enough parallel work at it. And once it's gone, it's gone until that session's own clock runs out.

The math that actually matters

  • 5 hours — the size of one Claude Code session block
  • Minutes — how fast a heavy parallel workflow can exhaust it
  • 4.5+ hours — how long you can end up waiting before you're allowed back in, even with a mountain of weekly runway still sitting unused on the other side of the wall

Both times the fix was the same: resume the job from where it cached off once the session reset, and it picked up cleanly. But the pattern was obvious by the second hit. A single research task — genuinely useful, not wasteful — had, on its own, chewed through roughly 9 million tokens across two sessions, worth something in the neighborhood of a normal month's subscription cost, inside a matter of minutes each time.

That's when I stopped and asked the model itself to explain what was actually happening to the spend. It told me straight: the workflow had fanned out into dozens of parallel sub-agents, each one a full Fable call — Anthropic's most expensive model, at Anthropic's most expensive per-token rate — each one thinking through its slice of the problem independently before the results got merged back together. Powerful. Also, apparently, expensive enough to flatten a 5-hour session in the time it takes to make coffee, if you don't watch it.

Nobody lied to me, exactly, but the tool's own error message did. I could see the usage panel the whole time, and it never once said "monthly" was the real limit — that framing came from the workflow tool itself, and it was simply mistaken. The gap that actually got me: "I can see the number going up" is not the same as "I have an intuitive feel for how fast an entire session can go up," and that's exactly where I fell.

The Real Lesson: Frontier Models Will Overthink and Over-Spawn If You Let Them

Here's the part that actually changed how I work, not just what I noticed. Partway through, I realized one piece of the job — "for every drug and supplement, tell me: with food or empty stomach, needs fat or not, how much water, what to space it away from" — wasn't a research project at all. It was almost a single prompt. A plain-language question a frontier model could answer directly, in one pass, as a table, using knowledge it already had.

Even GPT‑4 or Sonnet 3.5 could have handled this just fine in a single prompt in 2024. But the 2026 model spun up a crazy amount of excess work and overthinking.

That's the part that stopped me. This wasn't a case of new capability requiring new overhead — it was more capability finding more ways to spend itself on a question that hadn't gotten any harder in two years.

I'd been about to let the same 60-agent-swarm machinery handle it anyway, because that machinery was already running and it felt like the path of least resistance. It would have worked. It also would have been absurd — dozens of expensive parallel agents individually re-deriving something one plain conversational turn could produce for a fraction of the cost.

That's the actual lesson, and it generalizes past this one afternoon: a frontier model, left to its own judgment about how to tackle a task, will reach for its most powerful tools by default — more agents, more reasoning depth, more verification passes — because more capability is genuinely available and genuinely improves the odds of a good answer. Nothing in the model is incentivized to ask "could I do this the old-fashioned simple way instead?" That instinct has to come from the human giving the instruction.

The fix isn't "use AI less." It's "tell AI how much AI to use." Caution a frontier model, explicitly, to do the simple version of a task the plain old-fashioned way unless the complexity genuinely earns a swarm of agents. Left unsupervised, it will happily spin up 100 agents to answer a question that fit in one paragraph — not out of malice or incompetence, but because you never told it not to.

The Fix: Triage Before You Delegate

Once I switched to a cheaper, faster model and finished the last stretch of the job by hand — reading files directly and writing the synthesis myself instead of spawning another agent wave — the whole afternoon reorganized itself into a system I've now written down and will reuse every time this comes up again.

The idea is simple: before you let a frontier model loose on a big multi-part task, have a frontier model — the smartest one you've got — look at the whole task first and sort it into tiers by how much horsepower each piece actually needs. Then route each tier to the cheapest model that can actually do it.

Tier What lives here Model to use
Judgment / architecture The plan itself: what's the actual shape of this job, what can run in parallel, what's a trap that looks bigger than it is Top-tier frontier model, used once, briefly
Deep execution Genuinely hard reasoning steps that need real capability, one at a time Strong mid-tier model
Bulk mechanical work Formatting, straightforward lookups, drafting from a clear template, verification passes Fast/cheap model
"Almost a single prompt" Anything that turns out, on inspection, to just be a question with a knowable answer One plain conversational turn — no agents, no swarm, no tools

The single most valuable move in that whole system is the last row: catching the tasks that only look like they need machinery. That's exactly what the "how should I take each supplement" question turned out to be, and it's probably the single most common way solo operators like me overspend on AI — not through recklessness, but through defaulting to the biggest hammer because it's already in hand.

I've saved this as a reusable skill — a written methodology I can invoke by name in future sessions, so the discipline doesn't depend on me remembering it mid-crisis next time the meter's spinning. The short version: plan with the smartest model, execute with the cheapest one that can actually do the job, and always ask "is this secretly just a question?" before reaching for a swarm.

You don't need to re-paste a big prompt every time, either. Do it once: hand your AI tool the rule set below and ask it to fold the rules into its persistent project instructions (Claude Code calls that file CLAUDE.md; other tools have their own equivalent memory or system-prompt file). After that one-time setup, a short trigger phrase is all you need before any big task:

Prioritize this all and tell me what parts of this task
require which model and effort level, before proceeding.

That's genuinely all it took, once the rules were saved. Here's what it looked like in practice, in a separate project:

  • Me: "Proceed with tier A tasks."
  • It: worked through the whole list, then said on its own — "Okay, switch to Opus, then run list B."
  • Me: switched models, said go.
  • It: picked up exactly where the plan left off.

Everything cohered. Progress was cached the whole way through in case anything got interrupted. I never once had to re-explain the system mid-task.

Here's the one-time setup prompt — paste it once, ask your AI to absorb it into its permanent instructions, and you're done:

ROUTING RULES — save these to your permanent project
instructions / memory file (don't just answer in chat —
write them to disk so they persist across sessions).

You are the PLANNER, not the executor, of this task.

1. Read the whole task before doing any of it.
2. Break it into a numbered list of subtasks.
3. For EACH subtask, assign the LOWEST-tier model/effort
   level that can plausibly produce an EXCELLENT result —
   not "good enough," excellent. Never round up "just
   in case."
4. Any subtask that's really just a knowable question gets
   tagged ZERO-TIER: answer it directly, right now, in this
   reply. No agents, no tools, no swarm.
5. My available tiers, cheapest to most expensive:
   - [tier 1 — your cheapest/fastest model]
   - [tier 2 — your mid-tier model]
   - [tier 3 — your most expensive/frontier model]
6. Show me the routed list before executing anything.
7. As each subtask finishes: if a downshifted result came
   out shallow, wrong, or clearly straining above its tier,
   don't silently redo it higher. Flag it "[!] needs a
   higher tier" with a one-line reason, and keep moving.
8. At the end, show me every "[!]" item together so I can
   decide what's worth re-running.
9. From now on, whenever I say "prioritize this all and
   tell me what parts require which model and effort
   level, before proceeding" — run this exact process
   without me re-pasting these rules.

The Part I Actually Have to Learn, Same as Everyone Reading This

Here's the honest complication in writing an article about AI usage limits: I've probably been overusing AI anyway, limits or no limits. Not just on this one research library — on basically everything else I touch.

None of that is really an AI problem. It's an old problem — the "a million ideas, no way to execute" pattern that anyone with ADHD, or honestly anyone with a restless enough brain, recognizes instantly. AI didn't create that pattern. It just removed every piece of friction that used to slow it down. Building used to be the bottleneck that forced you to finish one thing before starting the next. Now building takes minutes, so the bottleneck moved — it's not "can I build this" anymore, it's "can I stop myself from building the next seven things instead of finishing this one." I haven't solved that. I'm writing about usage limits from outside a subscription plan while still very much inside that trap.

There's real research behind why this isn't just an ADHD thing. Psychologists Sheena Iyengar and Mark Lepper's well-known 2000 study on choice overload — the famous grocery-store jam-tasting experiment, published in the Journal of Personality and Social Psychology — found that a bigger display of options drew more browsers but converted far fewer of them into actual buyers than a smaller display did. Too many good options doesn't just feel harder to choose from; it measurably lowers the odds anyone finishes the choice at all. (Later replications found the effect is real but smaller and more conditional than the original headline suggested — it shows up most reliably when the options are similar and the stakes feel high, which describes an awful lot of AI-assisted "what should I build next" moments.)

Source: Iyengar, S. S., & Lepper, M. R. (2000). "When Choice Is Demotivating: Can One Desire Too Much of a Good Thing?" Journal of Personality and Social Psychology, 79, 995–1006.

If that's roughly right, a hard usage ceiling isn't only an inconvenience. It might be the first honest constraint a lot of us have had on this tool since it arrived. Scarcity forces sequencing. You can't spin up a sixth marketing plan for the same offer if finishing before the meter runs out matters more than generating the next idea. A limit that makes you choose is a limit that makes you ship.

That's the quieter, more optimistic version of everything else in this piece. The current era — nearly-free frontier intelligence, no real cost to trying six directions at once — is, in its own way, the Angelfire-and-GeoCities phase of AI: everyone throwing up whatever they can build the moment they can build it, because building suddenly got free and nobody's learned restraint yet. Real limits, even annoying ones, are usually what pushes a technology out of that phase. The web didn't mature by staying free-for-all forever; it matured once the cost of building things badly started to matter again, and the people who wanted actual results learned to build fewer things, better. I'd bet AI use goes through the same evolution — and honestly, I could use the push.

The Bigger Pattern — The Subsidy Is Ending

I'd heard the warning for months without really feeling it: consumer AI pricing right now is heavily subsidized. The $20-a-month plan, the $200-a-month plan — those flat prices are not what the compute underneath them actually costs to run.

Providers are eating the difference to win market share while the field is still hypercompetitive, the same way ride-sharing apps lost money on every ride for years to build the habit before prices found their real level.

You don't feel that subsidy while you're inside your normal monthly allotment. It's invisible — the meter just doesn't run. The moment you cross into overage, though, you're not paying the subsidized flat-rate price anymore. You're paying the official, un-subsidized, per-token rate — and that rate is startlingly higher than what the flat plan implies per unit of work.

That's the part that actually rattled me. I watched a single evening of legitimate, useful work quietly cross into overage pricing and burn something in the range of an entire month's normal subscription cost — not over a month, but in hours. Sometimes, with a big enough parallel fan-out, in minutes. The subsidy had been doing more work than I realized, and the instant I stepped outside it, the real economics showed up all at once.

This is the first time I've personally run into what people in this space have been saying for a year: the current era of cheap-feeling frontier AI is a land-grab price, not a stable one. Hypercompetition between labs is currently keeping consumer prices artificially low. That won't last forever — and the overage rate on any of these plans is a pretty honest preview of what "normal" pricing looks like once it doesn't have to.

This Isn't Just a Western Story

The same week I was writing this, Moonshot AI in China released Kimi K3 — a new 2.8-trillion-parameter model with a 1-million-token context window. My first assumption was "cheap Chinese alternative, undercutting Western frontier pricing." That assumption turned out to be wrong, and the way it's wrong is the actual point.

Model Price per 1M tokens (in / out) What that tells you
Kimi K3 (Jul 2026) $3 / $15 Priced at direct parity with Claude Sonnet — not a discount play, a capability-parity claim
Kimi K2.6 / K2.7 $0.95 / $4.00 The actual "cheap Chinese model" tier — this is what genuinely undercuts Western pricing
DeepSeek V4 Pro $0.435 / $0.87 Had a 75% introductory discount that expired May 31, 2026 — the rate then jumped straight to roughly 4x
DeepSeek V4 Flash $0.14 / $0.28 The genuine bargain-bin tier, small-model-scale pricing

Two things jump out:

There's also a practical wrinkle in treating "open-weight" as an escape hatch from any of this: Kimi K3's 2.8 trillion parameters make it a non-starter for genuinely local, on-your-own-hardware use — nobody is running this on a home rig. "Open weight" mostly benefits well-capitalized resellers who can rent the GPUs and undercut on hosting, not individuals looking to sidestep the subsidy cycle entirely.

The wall doesn't move. It just relocates — to a different company's balance sheet, on a different continent.

Sources: MarkTechPost on Kimi K3's specs and pricing; VentureBeat on the K3 launch; Kimi API pricing (K2.6/K2.5); DeepSeek/Kimi/Qwen/GLM pricing comparison.

What I Think Happens Next

None of this is inside information — it's a solopreneur's honest read after living through it once. Here's what I'd bet on, roughly in order of how confident I am, for you to poke holes in:

I don't think any of these are exotic. They're mostly just "what happened in every other compute-intensive tech category, applied here." The interesting question isn't whether they happen — it's which order, and how fast.

The Bottom Line

The runway wasn't wasted — the research library that came out of that week is genuinely good, and I'll be using it for months. But the way I got there was inefficient in a way I didn't have to accept, and wouldn't have accepted if I'd built the triage habit before the meter started running instead of during.

Growing pains, not a warning sign. This is what it looks like to actually run into the limits of a still-subsidized technology for the first time, instead of just hearing about it secondhand. It's not a reason to pull back from using AI hard — it's a reason to get deliberate about which model does which piece of the work, before you hit the wall instead of after.

My honest advice to anyone building the way I do — fast, with AI doing real load-bearing work, not just autocomplete: assume the subsidy ends on your watch, not someone else's. Build the model-tiering habit now, while it's a mild inconvenience, instead of later, when it's an invoice.

Watching the AI Economics So You Don't Have To

Real experiments, real costs, real lessons — from someone actually running a business on this stuff, not selling a course about it. No spam.

Unsubscribe anytime. Your email stays private.

Scott Covert. If you've hit your own version of this wall — or you think I'm wrong about where this goes — I want to hear it. Reach me here.

Follow Scott · Substack · Medium