Two builders, same budget, same month. One is on a $200 plan and cruises through a heavy refactor. The other is on the same $200 plan, doing similar work, and hits a wall by Thursday. Same price, same task, completely different experience.

The difference isn’t the model. It’s the meter — the unit each vendor counts to decide when you’ve had enough. And almost nobody reads it before they buy.

In the first article we covered which model to reach for. This one is about the thing underneath every pricing page: three completely different ways of counting, each with its own hidden accelerator that empties your budget faster than you’d expect.

The evergreen idea: the meter matters more than the price

Sticker price — dollars per million tokens, or dollars per month — tells you what a unit costs. It does not tell you how fast you consume units, and that is where budgets actually live or die. A cheap unit you burn through recklessly is more expensive than a dear one you spend with discipline.

There are three meters in this market, and every product you use is one of them wearing a friendly UI:

  • Raw tokens (the API). You pay per token in and per token out. Honest, granular, and completely usage-based. The whole game here is reducing tokens — through caching and batching — not switching models.
  • Compute-hours (Anthropic’s subscriptions / Claude Code). Your plan gives you a pool of “active working time” that is really token-throughput in disguise. Dense context and long sessions drain it fast, because every turn re-sends the growing conversation.
  • Messages (OpenAI’s Codex / ChatGPT plans). You get an allowance of prompts per window. A message counts as one message — unless it’s a heavy reasoning request, which quietly counts for more.

Same work, three meters, three different bills. If you don’t know which one you’re on, you can’t optimise it — you can only be surprised by it.

Three ways your AI usage is metered, and what drains each one fastest Anthropic · Claude Code METER: compute-hours Drains fastest Dense context & long repos — every turn re-reads the whole thing Main lever Prune context; cache; shorter sessions OpenAI · Codex / ChatGPT METER: messages Drains fastest High reasoning effort — each hard turn counts for more Main lever Lower effort by default; fewer, denser turns Raw API · all vendors METER: tokens Drains fastest Input volume — context dwarfs output on most calls Main lever Prompt caching (~-90%); batch API (-50%)

The current state (as of 19 July 2026)

The prices below are confirmed against vendor and aggregator pages. The subscription caps are not — vendors don’t publish exact hour or message numbers, they change often, and most of what’s “known” is community-reported. So treat the API prices as fact and the plan limits as directional. Verify your own plan before you lean on any figure here.

As of 2026-07-19:

Raw API — token prices per 1M (input / output): - Claude: Fable 5 $10/$50 · Opus 4.8 $5/$25 · Sonnet 5 $2/$10 (intro) · Haiku 4.5 $1/$5. - OpenAI GPT-5.6: Sol $5/$30 · Terra $2.50/$15 · Luna $1/$6. - Challengers: GLM-5.2 $1.40/$4.40 · Kimi K3 ~$3/$15 · DeepSeek V4 Flash $0.14/$0.28.

Caching & batch (the real API levers): - Claude: cached input roughly −90%; batch −50%. - OpenAI: cached input reads −90%, cache writes billed ~1.25×, ~30-min cache life; batch −50%.

Subscriptions (structure firm, numbers community-reported): - Anthropic meters compute-hours. Community figures put Pro ($20) around 40–80 active hours/week, with Max ($100 / $200) scaling roughly 5× and 20×. Dense-context coding burns the pool fast. - OpenAI meters messages. Community figures put higher tiers in the low thousands of messages/week, but high-reasoning requests draw down harder. Sub-window limits (rolling few-hour caps) bite before the weekly one on bursty days.

Notice what this does to the “which plan is cheaper” question: on the API you optimise tokens; on Claude subscriptions you optimise context length and session discipline; on OpenAI subscriptions you optimise effort level and turn count. Three different disciplines for what looks like the same job.

The same build, three meters

Picture a medium feature: some planning, a few hundred lines of new code, tests, a review pass. Roughly the same work in all three worlds. Here’s what actually moves your bill:

  • On the API, the cost is dominated by how many tokens you push, and most of those are input — the context you re-send every turn. Two builders writing identical code can differ 3× on cost purely because one keeps a tidy, cached context and the other drags a 200k-token repo into every call. The model choice barely matters next to that.
  • On Claude Code, the same context bloat shows up as compute-hours evaporating. A long, meandering session in a big repo eats the weekly pool even if the code produced is modest — because the meter is throughput, and throughput is mostly re-read context.
  • On OpenAI Codex, token volume matters less and turn behaviour matters more. Thirty crisp messages at moderate effort cost far less against the cap than the same work dragged out over eighty high-reasoning turns. The meter rewards decisiveness.

The lesson isn’t “one meter is best.” It’s that the optimisation you should reach for depends entirely on which meter you’re standing on — and the single most common mistake is applying API instincts (just pick a cheaper model) to a subscription meter (where context hygiene or effort discipline is the real lever).

Where the challengers sit

Most challenger usage — GLM, Kimi, DeepSeek, Qwen — happens on the raw-token meter, via their APIs or OpenRouter. That’s the meter where they’re strongest, because their whole advantage is price-per-token. Zhipu’s GLM Coding Plan (roughly $18 / $72 / $160 a month, community-confirmed) is the notable exception: a subscription-style meter aimed squarely at Claude and OpenAI coding plans, and worth a look if your work is GLM-friendly. But for most builders the challengers are a token-meter play: cheap muscle you rent by the token, not a subscription you live inside.

The playbook

  • Know your meter before you buy. Ask one question of any plan: what unit am I actually spending — tokens, hours, or messages? The answer determines your entire optimisation strategy.
  • On a token meter, chase caching, not cheaper models. A −90% cache discount beats most model downgrades and costs you nothing in quality. Batch anything that isn’t interactive for another −50%.
  • On a compute-hour meter, treat context as the budget. Prune aggressively, start fresh chats instead of dragging a bloated one, and don’t keep a giant repo in scope for a two-line change.
  • On a message meter, treat effort as the budget. Default to moderate reasoning; reserve high effort for the turns that genuinely need it; and get more done per message so you spend fewer of them.
  • Re-read the meter monthly. Vendors quietly retune caps and cache rules. The structure is stable; the numbers are not.

The Khula Take

The consensus advice is “compare the plans and pick the cheapest per token.” We think that’s a trap dressed as prudence. Sticker-price shopping optimises the one number the vendor wants you to stare at, while the meter — the thing that actually decides how far your money goes — stays invisible. You can win the price comparison and still run out of budget on Thursday.

The contrarian move for a South African business isn’t to hunt for the cheapest meter. It’s to build so that the meter barely matters — to design workflows where the expensive, metered AI turn happens rarely and deliberately, wrapped in cheap deterministic code that does the repetitive lifting for free. A business that reads its meter and then engineers around it stops being a price-taker at the mercy of the next pricing change. That’s the Applied AI difference: not finding the cheapest tariff, but building the system that makes the tariff a footnote — and turning the money you’d have burned on busywork into capacity to take on more work.

Where this is heading

Reading the meter by hand — remembering which discipline applies on which plan, month after month as the numbers drift — is exactly the kind of overhead the Token Economy harness is meant to absorb. The estimator we’re building reports cost in your meter’s units: not just “$X of tokens,” but “≈ N five-hour windows” or “≈ Y% of your weekly pool,” because that’s the number you actually feel.

Until it exists, the discipline is free and immediate: find out what you’re spending — tokens, hours, or messages — and optimise that. Confirm the current caps against your own plan before you trust any figure here; in this market, the meter’s fine print changes faster than the sticker price.

Sources (July 2026): - Anthropic pricing & caching — platform.claude.com/docs, finout - OpenAI GPT-5.6 pricing & cache terms — OpenAI Help Center, eesel - ChatGPT/Codex limits (community/aggregator) — IntuitionLabs - GLM Coding Plan — docs.z.ai pricing

Subscription caps are community-reported and change frequently; API prices are point-in-time. Confirm against your own plan and the vendor pages before making budget decisions.