← All Notes

Anthropic just put a meter on Fable 5. Not a higher subscription tier — actual usage fees, pay-per-call, billed like electricity. At the same moment, companies across the industry are capping employee AI usage. Both things happened in the same week. That's not a coincidence. That's the market telling the truth.

There's no such thing as a free lunch. The subscription model in AI was always a fiction — a flat fee wrapped around a resource that doesn't cost flat. Go hit Claude or ChatGPT hard enough and you find the walls anyway. Rate limits. Queue times. Capacity errors. The unlimited buffet was never unlimited. Fable 5 is just too expensive to keep hiding the walls.

This was always coming. The question is what you do about it.

It's a Physics Problem

AI inference isn't like streaming music. Spotify pays the same cost whether you listen to a three-minute pop song or a three-hour symphony. The cost is mostly bandwidth and licensing — it doesn't vary much by what you do.

AI inference varies by orders of magnitude. A simple question is cheap. A complex reasoning chain with deep context is expensive. A multi-step agent that calls the model forty times to complete a task is very expensive. You cannot hide that variance under a flat monthly fee without either overcharging casual users or getting destroyed by power users.

The moment a model gets good enough that power users run it all day for real work — the subscription math breaks. Fable 5 crossed that threshold. So did the models companies are now capping internally. This isn't Anthropic being greedy. It's physics.

A vast server hall stretching to the horizon, warm industrial light on row after row of humming machines, the scale of the compute visible

The Lazy Developer Principle

Here's the right response — and it's one good developers already understand instinctively.

The best developers are lazy. Not in the pejorative sense — in the precise sense. When a good developer looks at a problem, they ask: how do I loop through these elements, handle my edge cases, and solve this while typing as little as possible? Not because they're cutting corners. Because brevity and elegance are the same thing. A process and its exceptions. Graceful. Clean. Reusable.

That's exactly what prompt writing is, now that it costs money.

A bloated prompt is like bloated code. It works, but it's wasteful, fragile, and hard to maintain. A well-structured 200-token prompt that precisely specifies the task will outperform a meandering 800-token prompt on cost and quality. The model isn't rewarded by your verbosity — it's taxed by it. Both of you are.

Context tuning is the new code review. The question isn't just "does this prompt work?" It's "does this prompt work efficiently?" That means knowing what the model already knows, eliminating redundancy, handling edge cases explicitly but concisely, and structuring input so it compresses naturally.

The Abbreviation Question

Here's something I've been sitting with: do abbreviations and shorthand actually save compute?

The obvious intuition is yes — fewer tokens in means cheaper inference. Send "JWT" instead of "JSON Web Token." Use "API" instead of "application programming interface." You're shipping fewer tokens into a context window that bills per token.

But there's a subtler question. If the model has to expand the abbreviation internally before it can reason about it — some internal lookup table process — then you've just moved the cost downstream. The tokens you saved on input get paid for in compute somewhere else.

Here's how it actually works: for abbreviations that live in the model's weights — JWT, API, LLM, SQL, RAG, every acronym that appears thousands of times in training data — the model resolves them natively. There's no lookup step. The meaning is embedded in the parameters, the same way you don't consciously decode the word "the" when you read it. Sending "JWT" is genuinely cheaper, with no quality loss.

For custom shorthand you define in the prompt — "let's call the user U and the system S from here on" — you've spent tokens on the definition and save tokens on each use. That's a breakeven calculation. If the definition costs 15 tokens and each use saves 5, you need three uses just to get even. In a long conversation or a large structured document, that math tips in your favor. In a short prompt, you're losing.

The real win is JSON. Send the model a structured object with a schema definition at the top and use it throughout — the model comprehends it natively, through weights, with no overhead. Structure is compression. Models are trained on millions of structured documents and parse them efficiently. You can define a field name once and reference it repeatedly, and the model attends to the schema without needing prose re-explanation every time.

The practical principle: trust what's in the weights. Don't explain REST. Don't define what a database index is. Don't walk the model through OAuth. It knows. Every token you spend explaining something the model already knows is pure waste. Your real efficiency gain isn't shorthand — it's elimination.

A close-up of hands at a keyboard, a single focused beam of light on the keys, the surrounding workspace spare and deliberate

What to Do Right Now

If you're building on AI, this is your architecture memo:

Route by task. Not every call needs Fable 5. Most tasks don't. A model-agnostic routing layer sends heavy reasoning tasks to the frontier model and everything else to something cheaper. We built this into our stack from day one because we knew metering was coming.

Cache aggressively. System prompt caching (Anthropic has it; others are following) lets you write your scaffolding once and not pay for it on every call. If your system prompt is 2,000 tokens and you're making 10,000 calls a day, that's 20 million cached tokens. The math is material.

Treat every call like it has a price tag. Because it does. Always did.

Write prompts like code. One clear purpose. Explicit edge cases. No redundancy. Structure over prose. Trust the model's knowledge. Review for bloat the same way you'd review for unnecessary dependencies.

The developers who built for metered pricing before it arrived are fine. They were already operating on the principle that resources have cost — that elegance matters, that waste compounds at scale.

Everyone else has some refactoring to do.

— J.P. Howlett


Related:


Sources