Language models charge for context by the character. So we stopped sending characters. Moxby renders bulky context as compact images and sends the model pictures of its own working memory, losslessly, and far more cheaply.
On a real coding session, it cut the token bill by 97%.
| Metric | Result |
|---|---|
| Imageable context sent as text | 8,196,892 tokens |
| The same context sent as images | 237,783 tokens |
| Tokens saved | 7,959,109 (97%) |
| Cost saved on the session | $20.73 |
| First reads (cold) | 1.42M tokens saved · $14.19 |
| Re-sends (cached) | 6.54M tokens saved · $6.54 |
The idea
An agent’s context is not sent once; it is re-sent on every turn. A long coding session re-transmits its whole growing history dozens of times, and the token bill scales with it. The usual answer is to forget more: summarize, truncate, evict. Context Rasterization takes the opposite route: send the same information in a cheaper form, and keep the original one lookup away.
The trick is a pricing asymmetry. Vision models bill an image by its pixel area, not by the number of characters it depicts. Render text densely enough and a single tile carries thousands of characters for a flat, small vision-token cost. So at the moment a request leaves Moxby, we swap bulky, gist-tolerant blocks (the system prompt, tool results, older conversation) for compact renderings of that same text. Nothing is deleted: the full text stays in the database and on disk, and the transcript you read is untouched. Only the wire carries pixels.
What we measured
A real coding session, read from the bill
The headline number is not a benchmark; it is one of our own debugging sessions on Claude Fable 5, taken straight from the usage ledger. Over 110 tool calls, the imageable context (tool results, file reads, and the standing system context) would have cost 8,196,892 tokens as text. As images it cost 237,783. That is 7,959,109 tokens (97%) saved, and $20.73 off a single session.
Most of that is from the initial cold reads of rasterized tool and skill files; in addition to the re-sends via the chat history as it evolves. A file read early in a session rides along in context for every subsequent turn; imaged once, it becomes a cheap cache-read forever after cutting saving another ~5 to 8x on cached reads as well.
A controlled study: same task, imaging on vs. off
To isolate the effect cleanly we ran the identical multi-turn task in parallel chats that differ only in whether imaging is on, on the same model:
| Per turn | Off | Context Rasterization |
|---|---|---|
| Input tokens on the wire | 35,840 | 18,650 |
| Input-token reduction | n/a | 48% |
| Input cost | $0.142 | $0.029 |
| Input-cost reduction | n/a | 79% |
| Exact-value errors | 0 | 0 |
~48% fewer input tokens, ~79% lower input cost, every turn. The cost reduction outruns the token reduction for a subtle reason: a growing text history gets cached, but at anywhere from 5 to 8 times the size of the rasterized version. A 2,500 text token cache can be a 400 token rasterized token cost, forcing expensive cache-writes every turn, while an imaged prefix is byte-stable and stays a cheap cache-read. Imaging does not just shrink the payload; it moves spend from the expensive lane to the cheap one.
Where it wins, and where it doesn’t
The 97% figure is a tool-heavy coding session, with dozens of file reads and command outputs accumulating in context. That is exactly where Context Rasterization is transformative, because the bulk is large, gist-tolerant, and re-sent constantly. A short back-and-forth chat with little tool use has little to compress, and will see modest savings. The heavier the task (coding, research, long agent runs), the larger the win. Light chats save a little; coding sessions save fortunes.
Another big win is in context window handling and compaction. Since this enables much deeper context usage within the same context window, the model is armed with more information. And a compaction that resets it back to say 25,000 tokens, is equivalent to 125,000 to 200,000 of tokens of context so the conversation will rarely need to compact (as we have a threshold and eviction process) while maintaining that minimum level of context on follow-up chats for a more continuous experience.
Why it’s safe
Imaging has exactly one real weakness: a model reads dense pixels for gist reliably, but can misread an exact string such as a version number, a file path, or a hash. Moxby is built so it never has to. Because imaging is wire-only and the full text is always retained, whenever an exact value is needed the agent fetches it through the same file-read and history-search tools it already uses. Imaged context therefore degrades, at worst, to one extra cheap lookup, never to a confidently wrong answer.
In our controlled runs this held: across imaged chats the model never once fabricated a value. When it could not read an exact identifier off an image, it fetched it or said so, and quoted every legible value correctly. To the user it is invisible: the answer is exact, and the bulk that produced it rode as cheap pixels.
- Lossless to the store. Imaging happens on a throwaway copy of the outbound request. Your data and transcript keep full text; only the wire carries images.
- Cache-stable. Imaged context is rendered deterministically so its bytes do not change turn to turn, the difference between a permanent cheap cache-read and re-paying every turn.
- Retrieval-backed. Exact values come from tools, never from reading a rendering, so precision is guaranteed even when compression is aggressive.
The tradeoff, measured
We quantified the recall cost directly. In one round we planted eight exact facts in a reference card, then imaged that card and asked the model to quote each back verbatim. Plain text recalled all eight; the imaged tiers recalled fewer (five and three of eight in that round), yet neither imaged chat invented a single value. On identifiers it could not read, the model did exactly the safe thing: it flagged the uncertainty and pointed back to the retained text. Recall rises or falls with whether a retrieval path exists for a given fact; confabulation stays at zero regardless. That is the property that makes imaging safe to run by default.
How it works
Three ideas do the work. Area-based pricing is the lever: dense monospace renderings carry many characters per vision-token, so gist-tolerant text costs a fraction of its literal token count. Cache-stable rendering makes the saving recur: because the same context is re-sent every turn, an imaged block only pays off if its bytes are identical each time, so it stays a cached prefix rather than re-billing. And retrieval, not OCR is the safety backstop: the full text always persists, so exact values are fetched, never guessed.
One layer of three
Context Rasterization is the visual layer of Moxby’s broader Token Condensor, which shrinks what actually reaches the model across three cooperating layers. A semantic output condenser reduces verbose tool results (git status, test logs, build output) to their signal. For example, instead of giving the model a log with the same error repeating 8 times, we give it the error and how many times its recurred. A proxy-RAG and codebase index serves the relevant spans on demand instead of dumping whole files. And Context Rasterization, described here, renders the remaining bulk as images. The layers compose: a tool result the condenser has already shrunk can then be imaged, and anything evicted from the wire stays indexed for retrieval.
Density tiers
Density trades against legibility, and legibility against recall. Measured character density (characters per image-token) sets the ceiling on savings, since image tokens are simply the same content re-priced by area:
| Renderer | chars / img-token | ≈ font-equiv | block saving |
|---|---|---|---|
| ab_glyph font 9 (old default) | 18.3 | n/a | 78% |
| Atlas Spleen 5×8 | 18.2 | ≈ font 9 | 78% |
| ab_glyph font 7 (Medium) | 29.1 | n/a | 86% |
| Atlas Tom Thumb 4×6 (Aggressive) | 31.3 | ≈ font 7 | 87% |
An anti-aliased font-7 render already sits near the legibility ceiling at roughly 86% block-level reduction. Moxby ships two tiers: a balanced Medium default, and an Aggressive tier (a crisp 1-bit atlas) for vision-strong models. Both are on by default for capable models.
The stubborn residue: tool schemas
Imaging the system prompt and history still leaves one text residue: the tool definitions and skill files. These are pre-imaged, while leaving the front-matter to ensure the models can consume them properly. Because a description is guidance, not a checked contract, Moxby keeps each tool’s name and input schema verbatim (the model needs those exact bytes to make a valid call) and relocates the prose into the imaged, cached system block. The bulky text becomes pixels; the exact bytes stay one lookup away; the window stretches several times further per dollar.
What’s Next
We look forward to going even further for coding projects to give agents deeper context without sacrificing quality or the context window itself. We are working on this and will be sharing actual benchmarks. More to come on this soon.
Moxby is a collaborative browser, IDE, and workspace, ideal for builders. Context Rasterization is live in production. Figures are measured from billed provider usage and controlled A/B runs.
