AI Costs Are Full of Illusions — Token Economy, Credits, Compression

Intro: The first-ever "AI TV host" wasn't AI at all

On April 4, 1985, a British Channel 4 TV movie called Max Headroom: 20 Minutes into the Future introduced something billed as a world first: Max Headroom, "the world's first computer-generated TV host." He stuttered and glitched, his voice skipped, digital noise crawled across the background behind him — the very picture of "a computer talking to you."

Except it was an elaborate illusion. Underneath was a human actor, Matt Frewer. Latex and foam prosthetics, contact lenses, a fiberglass suit — and four and a half hours in the makeup chair every single time. The only part that was actually computer-generated was the background. The "host" was a man. Harsh lighting and editing did the rest, making a real person look "obviously CGI" (Wikipedia).

Term — CGI (computer-generated imagery): visuals produced by a computer. Max Headroom is the rare case of effort spent in the opposite direction — enormous human labor to make a human look like he was generated by a machine.

A note for readers outside the UK/US: Max Headroom became a genuine 1980s pop-culture phenomenon — talk-show appearances, a Coca-Cola ad campaign, an ABC sci-fi series. If the name doesn't ring a bell, the one thing to keep is the punchline: the "first AI presenter" was a costume. Hold onto that; the article's last twist depends on it.

Forty years later, we're still mixing up "how something looks" with "what it actually is" all over the AI world — especially when it comes to cost. Credit balances, subscription invoices, per-token billing: every one of them betrays your intuition.

This article dissects three cost illusions I personally walked straight into in a single day, using primary sources only (my own experience, my own measured logs, official documentation). As a technical topic it's unglamorous, but understanding the structure of what you're paying for changes how you use AI at all.

Term — token: the smallest unit an LLM (large language model) uses to process text. Loosely, "a fragment of a word." A single character in some languages can become several tokens, and crucially, both billing and rate limits are measured in tokens. AI cost doesn't run on dollars first — it runs on tokens first. Keep that in mind throughout.

Illusion #1: The unit-price trap — "I asked the AI its own price, and it inflated it by two orders of magnitude"

One day I left an agent feature running for half a day — "agent" meaning the mode where the AI autonomously works on a task for a long stretch on its own. When I checked back, my balance read 6,333.14 credits. How much is a "credit," anyway? So — against my better judgment — I asked the AI service itself.

Term — credit: an in-service virtual currency. The exchange rate to real money (dollars, etc.) is set by the provider, so there's always a "cushion" — an extra conversion step — between the number on screen and the actual cost. That's exactly why your gut fails you here.

Me: "How much is 6,333.14 credits?"
AI: "1 credit = approximately $1. Therefore 6,333.14 credits = $6,333.14 worth."

…over six thousand dollars. For half a day, that's a catastrophe. The blood drained from my face.

I scrambled to contact support. The correct answer was —

Support: "100 credits = US$1.00. 6,333 credits is roughly $63.33."

Off by 100×. And the error wasn't random — it was exactly 100×, which is precisely the credit-per-dollar ratio. This was not an exchange-rate problem. The AI swapped 1 credit = $1 for 100 credits = $1 — a units mix-up that translated directly into a two-orders-of-magnitude scare.

The lesson here is quietly heavier than it looks

In this one case of mine, the AI got the magnitude wrong by two orders — about its own provider's pricing, which is primary-source information about itself. I won't generalize this to "AI always gets things wrong." But since an LLM is fundamentally a machine that generates plausible-sounding strings probabilistically, the possibility of error on numbers and on self-reference (facts about the model itself) is structurally always present. So: never take numeric or self-referential answers at face value.
The "credit" unit itself is a UX that hides real cost. Insert two cushions — dollars → credits → (back to) dollars — and the user can no longer judge "expensive or cheap?" by instinct in the moment. I can't verify intent from the outside, but structurally it makes real cost harder to see (it's close to selling "gems" in mobile games). If it is deliberate, it's the kind of design that qualifies as a dark pattern.

Where the metaphor breaks: I said "just like game gems," but game gems are consumed once, whereas credits are metered against ongoing work. The only shared trait is "real cost is unreadable by intuition." Don't push the analogy further than that.

— quick breath —

That's the first illusion: unit price drifting away from intuition. Next, the opposite — the nagging feeling that you're overpaying — which I'll flip on its head with real measurements.

Illusion #2: The true value of flat-rate — how to correctly read "am I getting my money's worth?"

I subscribe to Claude (Anthropic's AI) on the Max 20x plan ($200/month). One day I got nervous. "It's not a trivial amount — am I actually getting my money's worth out of this?"

The key thing here: a flat-rate plan like Max is not a 'usage meter' — it's a 'rate limit.'

Term — usage-based (metered) billing: you pay for exactly what you use. Taxi-meter style.
Term — rate limit: a cap on speed — "this much per 5 hours / per week." Unused capacity does not roll over; it just evaporates. Closer to the amperage rating on your electricity contract.
Term — subscription (flat-rate): a fixed monthly fee, use up to the cap as much as you like.

So "am I using it fully?" actually has two meanings: (A) am I getting my money's worth (value), and (B) am I hitting the ceiling (consumption). These are easy to conflate, but they're entirely different questions.

So I measured it

To measure value, you just compute: "if I had paid for this exact usage at pay-as-you-go API rates, what would it cost?" I took my own usage logs accumulated locally (about 54,000 messages) and converted them at current official API unit prices.

Period	API-equivalent cost	Multiple vs. $200/month
This month (as of day 20)	~$6,400	~32×
30-day projected pace	~$9,600	~48×
Last month	~$2,920	~15×

Basis for the unit price: Claude Opus (the top-tier flagship model on the Max plan) costs, via API, $5 input / $25 output (per million tokens). Against that, Max is flat-rate. Converted, this month alone the plan did 32× the work — a $200/month subscription pushing through roughly $6,400 worth of usage that pay-as-you-go would have billed.

Caveat: This 32× is specific to a heavy workload — long-running autonomous agent work. For ordinary conversation-centric usage, the multiple is far smaller, because cache reuse doesn't kick in the same way. As I'll explain below, this conversion evaluates all usage at the top-tier Opus unit price, so it's an upper-bound-leaning number; in reality you should discount it for the cheaper models (Sonnet, etc.) mixed in.

…and here's where "if a number looks unusually good, audit its breakdown" (honest disclosure)

The 32× is real, but if you don't break it down, you'll overstate it. Roughly half of that converted figure was cache reads.

Term — prompt cache: when you repeatedly send the same context, the second and later sends can be reused at roughly 1/10 the unit price. In long-running autonomous work, these cache reads pile up enormously — in my case, 9 billion tokens.

So "9 billion tokens × a dirt-cheap rate" is what's inflating the dollar figure. This isn't padding — it's the correct conversion of "what list-price billing would actually charge." But the honest way to read it is to look at what the dominant term is, not to do a naive "unit price × total volume." The dominant term is "cache reads: 9 billion tokens," which means this multiple depends heavily on cache reuse — i.e., it's workload-dependent. Keep that front and center.

Conclusion: (A) I'm completely getting my money's worth (32×). (B) Whether I'm hitting the ceiling is a separate question, read in two stages: if "you've reached your limit" pops up often, you're at the ceiling; if it doesn't, you still have headroom. (Note that word — headroom — it comes back at the end.)

The connection to FullSense: a design with no "open-ended bill" surprise, by construction

I'm building FullSense, a set of three independent open-source projects under the banner "a responsible, well-meaning AI ecosystem that runs on your own PC." The root design principle is local-first — personal data, corporate secrets, and sensor data never leave the machine.

This Illusion #2 illuminates the value of local-first from the back side. The open-ended pay-as-you-go surprise (left it running half a day and… a thousand-dollar bill?!) cannot happen, in principle, with local execution — because your electricity bill is a physical ceiling. The contrast between cloud AI ("convenient, but the invoice is unpredictable") and local AI ("slower, but predictable") is, I believe, where adoption forks.

— That's the story of "the cost you already have." Next: "reducing it before you pay at all." —

Illusion #3: Cut it before you pay — an OSS called "Headroom," and the punchline in its name

The third illusion is the blind spot in the assumption that "tokens can be reduced before they ever reach the model." Most people believe "what you used, you have to pay for, full stop."

What lands squarely on that blind spot is Headroom, an open-source project released in January 2026 by Tejas Chopra, a senior engineer at Netflix (github.com/chopratejas/headroom, Apache-2.0, actively maintained — as of 2026-06-21 it's past 40k stars on a v0.2x line, and The Register covered it). Star counts and version numbers move fast, so check the official repository for the latest.

What it actually does

It's a "context-compression layer" that sits between your app and the LLM API. Before an agent hands content to the LLM, Headroom compresses tool outputs, logs, files, RAG chunks, and conversation history according to their content.

Content-aware compression: for a JSON array, keep only the outliers; for a build log, keep only the failing lines. Redundant machine metadata, repetitive JSON schemas, and duplicated templates are far more compressible than human prose — and that's exactly what it exploits.
Reversible: it leaves a marker where it compressed and keeps the original locally, so the model can fetch the source back if it needs it (the repo calls this reversible compression / CCR). On public benchmarks (GSM8K, TruthfulQA, SQuAD v2, and BFCL — four in total), accuracy is reported as roughly maintained.
Implementations: a Python/TypeScript library, a transparent proxy, a wrapper for agents like Claude Code, and an MCP server — so you can choose how invasive it is. Internally it's built in Python/Rust, switching between purpose-built algorithms per data type (JSON-specific, code-specific, a trained compression model, etc.).

The headline claim is 60–95% token reduction (stated plainly in the GitHub description). The Register's reporting (an as-of-2026-05-31 stated estimate) puts aggregate user savings at roughly $700,000 and 200 billion tokens.

Term — RAG chunk: a fragment of a reference document pulled in by search. RAG (Retrieval-Augmented Generation) means "fetch relevant docs and feed them to the LLM as source material." Those chunks are one of the prime culprits for token consumption.
Term — MCP server: an implementation of the Model Context Protocol, a standard for connecting AI to external tools and data.

…and here, too, audit the breakdown (honest disclosure)

The flashy "95%" is the upper bound. Let me lay out the caveats honestly.

The 95% is for "input that is mostly machine output." It works because the targets are logs, JSON, and repetitive schemas. For human prose (ordinary writing), the reduction is far smaller. The project itself acknowledges that "machine output is more compressible than human prose."
The higher the compression ratio, the thinner the accuracy margin. Even on its public benchmarks, SQuAD v2 shows "97% accuracy at 19% compression" and BFCL shows "97% accuracy at 32% compression" — i.e., conditions where compression ratio and accuracy trade off against each other. So it is not "95% off any input with no accuracy change." At a given input, "95% reduction" and "accuracy maintained" do not hold simultaneously.
"Same answers" is a benchmark-level claim. Because it's a content-aware heuristic (a rule of thumb), the risk remains that, say, in a security or forensics use case a log line judged "redundant" still carried a detection signal that got dropped. Before adopting it, prove on your own data that "cutting doesn't degrade the result."
It's still v0.x. It moves fast, but production use warrants verification.

The punchline in the name: AI history comes full circle and rhymes

And this tool — there's no official statement on the origin of its name, but I read it as an homage to Max Headroom. "Headroom" is also a general technical term for "spare room / margin," which makes it a natural name for a tool that creates headroom under your token ceiling — and on top of that, it resonates doubly with the opening's "first AI presenter (actually a man in a costume = an illusion)." It's almost too perfect.

So the shape of it is this: forty years ago, a human disguised as AI (Max Headroom) debuts; forty years later, a tool borrowing that name (Headroom) is shaving down the illusions of AI cost. The original was on the "creating illusions" side; the modern one is on the "cutting illusions" side. The name comes full circle. (This is purely my interpretation — I couldn't confirm the developer ever said so explicitly.)

The three-layer model: decomposing "what you're paying for, and how much"

The three illusions are, in truth, just paying at different layers. Laid out, it looks like this (the bottom row of the table is a "fourth layer" this article touches on — the architecture layer).

Layer	What the illusion really is	The effective countermeasure
Unit-price layer (credit/token pricing)	A display illusion (the two-cushion credit detour)	Convert to real currency to recover your intuition
Billing-model layer (flat-rate subscription vs. metered)	A structural illusion (conflating "am I using it fully?")	Measure value = API-equivalent multiple, and consumption = rate ceiling, separately
Preprocessing layer (compression)	Overlooking the room to cut	Trim with Headroom etc. before it reaches the model
Architecture layer (llcore)	A retention-cost illusion (memory grows in proportion to token count)	Constant-state linear attention so memory doesn't balloon even on long text

And what FullSense/llcore is aiming at is the fourth layer beneath all this.

Architecture layer: my in-development research framework llcore is exploring how to replace the Transformer's attention mechanism with constant-state linear attention, so that the memory holding context does not scale with token count.

Plain-language: ordinary attention keeps holding onto "all of the past" as the context grows, so the memory cost climbs and climbs. Linear attention folds that memory into a fixed-size state, so memory stays roughly flat even on long text. But because it folds, fine details can get dropped — that's where the "compress and carry" metaphor breaks.

Headroom (preprocessing layer) and llcore (architecture layer) are complementary, not competing. Headroom "reduces how much gets read"; llcore "lowers the cost of holding it." Two different altitudes under the same north star of "token efficiency." They work in tandem.

A practitioner's prescription

Here's how to actually move, once the illusions are dispelled.

Pay-as-you-go API (an app where you call the API yourself) → adopt Headroom to cut real cost. This is where dollars come off directly. It's Apache-2.0 and a local proxy, so you can do it without increasing external data transmission (which sits well with the local-first philosophy).
Flat-rate subscription (Claude Code, etc.) → it doesn't save money; it buys you "rate-cap headroom." Headroom officially provides a Claude Code wrapper. Fewer tokens means you hit the 5-hour / weekly ceiling less often — literal headroom, in the original sense of the word.
Measure first; talk later. Convert your own usage logs at API rates to get your value multiple. And if you get an unusually good number, audit its breakdown before you feel like you've won (my 32× was half cache, too).

Closing: the eye that separates appearance from substance

AI cost is decided not by the unit price on display, nor by the number on the month-end invoice, but by structure. The presentation of a credit, the billing model of flat-rate vs. metered, and the preprocessing room to cut before you ever hand it over. Get pulled by "appearance" on any of these and you'll judge wrong.

What the 40-year-old Max Headroom teaches us, in the end, is just this: separate the flashy appearance (the illusion) from the unglamorous substance (the reality). Just as that glitchy, futuristic AI host turned out to be a man under four and a half hours of makeup.

FullSense's banners — "local-first" and "honest disclosure" — are tools for exactly that. Before you fear the invoice, take stock of your own token economy by structure, once. Chances are the real cost lives somewhere other than where you think it does.

References

Headroom (OSS, Tejas Chopra): https://github.com/chopratejas/headroom
The Register coverage (2026-05-31): https://www.theregister.com/ai-ml/2026/05/31/netflix-wiz-creates-app-to-slash-ai-bills-then-open-sources-it/5248702
Max Headroom (Wikipedia): https://en.wikipedia.org/wiki/Max_Headroom
FullSense / llive design concept: https://qiita.com/furuse-kazufumi/items/cab6bb47a72ebedf5436

The figures in this article (credit conversion, the 32× on the Max plan, the token breakdown) are based on my own first-hand experience and measurements of my own usage logs. External figures for Headroom (star count, version, savings, etc.) are values based on public information as of writing (2026-06) and all of them fluctuate. Because AI plan pricing, rate limits, and OSS specifications change rapidly, please confirm the latest information from each official source when making an adoption decision.