Does rendering text as images cut Claude's token bill?

The headline version, the one that travels, is this:

“Fable 5 consumes up to 3× fewer tokens when text context is sent as an image instead of as text.”

Two things in that sentence are worth separating. One is a mechanism: does imaging text reduce input tokens? The other is a framing: is this a Fable 5 property you should factor into model choice? I tested both on the first-party Claude API, using count_tokens for exact, free measurements and live messages.create calls to confirm the billed usage and check whether the model could still read what I sent.

Three corpora, chosen to mirror the content types these pipelines target, generated deterministically so the test is reproducible:

Each corpus has specific facts embedded in it (numbers, names, one hex constant) so I could check not just the token count but whether the model could still read the imaged text. Every corpus was rendered at three densities on identical 2000×2560 px pages, monospace, black on white:

Here is the whole story in one picture. Each bar is the image cost divided by the text cost for the same content. The dashed line is break-even.

Three mechanics explain every bar:

• Flat page cost. Every full page costs about 4,850 to 4,890 tokens regardless of what is printed on it. That is why prose costs the same in all three configs: it always fits on one page.
• Break-even is one page of text. A page has to carry more than roughly 4,850 tokens’ worth of text, about 19k characters, before the image beats simply sending the text.
• Density is the entire effect. Same handbook, same page size: it moves from 0.88× to 0.30× purely by packing tighter. At the tightest setting I measured 9.9 characters per image-token, versus roughly 2.8 to 3.0 characters per text-token.

Cheaper input is worthless if the model cannot read it back. On the live billed runs, the input tokens matched count_tokens exactly, and Opus 4.8 answered every embedded-fact question correctly at every density, including a verbatim hex constant on the 8px, 4-column page that held the entire handbook.

My embedded facts are easier than a large-scale verbatim reproduction test, so I would not claim images are lossless for every use. But at the densities where the savings actually appear, reading held up.

One thing I did not go looking for. Fable 5’s cyber safety classifier repeatedly refused harmless experiment content: the Python standard-library JSON parser, a fictional support-system prompt, and, as refusals piled up in a short window, even prose that had passed minutes earlier. A few observations:

• Refusals were content-sensitive: parser-flavored code and “system prompt with tool schemas” documents refused consistently; a math-flavored module passed consistently.
• The scope widened after many refusals in a short window, then needed a cool-down, consistent with stateful escalation at the account level.
• The same document sometimes passed as an image but refused as text, and the reverse. The classifier does not treat the two modalities identically.

Opus 4.8 refused nothing at any point. The practical warning for anyone building these pipelines on Fable 5: the context you would image (agent prompts, tool docs, parser code) is exactly the content that can trip the classifier, in either modality.

1. The mechanism is real. Dense text packing beats text tokenization by a wide margin, up to about 70 percent fewer input tokens at maximum density.
2. The “3× on Fable 5” framing is misleading twice over. The savings depend entirely on packing density and document size, and naive rendering costs more, not less. And Fable 5 and Opus 4.8 tokenize identically, so nothing about the savings is Fable-specific; only the price per token differs.
3. Small documents always lose. Below roughly one page of text, about 19k characters, a single page’s flat cost is more than the text you are trying to replace.