Does compressing inputs make the agent dumber?

The transforms keep what the agent needs. A PDF keeps its text and loses only the rendered page image. A build log keeps errors, warnings, and the head and tail. A CSV keeps the header, inferred column types, sample rows, and the row count. Anything compressed is cached by content hash, so justokenmax retrieve hands back the original when the agent genuinely needs it.

Where do the biggest savings come from?

Two places. First, the things you attach: a PDF is billed as text plus a rendered page image, and dropping the image channel alone is most of the 56 percent. Second, how agents read code: pulling a whole file to find one function is the biggest avoidable input cost, and a symbol lookup that returns file, line, and signature is about 97 percent cheaper.

Does it work outside Claude Code?

Yes. In Claude Code it is a plugin whose Read hook swaps heavy files for cheap artifacts in place. For any MCP-capable agent, including Codex CLI, OpenCode, and Cursor, justokenmax install registers it. There is also a plain justokenmax CLI.

There is no OCR, so a scanned, image-only PDF has no text layer and is passed through unchanged. The per-page PDF token figure is a conservative model rather than a billed number. Image savings apply to the base64 pipeline, because native vision downscales regardless. The code index is a snapshot, so re-run the index after large changes.

Which side of a coding agent's bill does jusTokenMax attack?

The input tokens that enter the context window

The output tokens the agent writes

The input tokens that enter the context window

The provider's per-request overhead

The number of model calls per task

Why does dropping a PDF's page-image channel save so much?

A page is billed as text plus a rendered image, and the image is the expensive part

Images are stored at higher precision than text

PDF text is already compressed by the provider

A page is billed as text plus a rendered image, and the image is the expensive part

The model never looks at images

What makes the savings compound inside an agent loop?

Each iteration re-reads files, so a cheaper read is paid for repeatedly

Compression improves as more data passes through

The provider discounts repeated requests

The model gets faster on each iteration

Each iteration re-reads files, so a cheaper read is paid for repeatedly

← All posts

jusTokenMax: Cut Coding-Agent Token Costs Before the Model Sees Them

Your agent's bill is an input-token bill. jusTokenMax intercepts the PDFs, logs, JSON, lockfiles, notebooks, CSVs, and whole-file reads that bloat the context and swaps in a faithful, far cheaper equivalent. Measured reductions of 56 to 99 percent.

7/8/2026 · 5 min · jusCode · Read as Markdown

token economicscost-optimizationai coding

TL;DR

Coding-agent bills are input-token bills. jusTokenMax compresses each heavy input before it reaches the context window, so the same work costs a fraction of the tokens. One pass over a real project went from 259,819 to 103,745 tokens, and the savings compound as the agent re-reads files.

The cheapest token is the one that never enters the context. jusTokenMax intercepts heavy inputs before they are billed, rather than trimming the conversation afterwards.
Measured, not hand-waved: PDFs down 56 percent, build logs and large JSON down 99 percent, and a symbol lookup instead of a whole-file read down 97 percent.
It compounds inside an agent loop. Every iteration that re-reads a file pays again, so an input-side reduction multiplies across iterations.
Reversible and auditable: originals are cached by content hash and can be retrieved, secrets are masked, and every transform is deterministic Python with no trained model and no network.

Coding-agent bills are input bills. The PDFs, build logs, API responses, lockfiles, and source files that pile into the context window are what you pay for, and they arrive long before the model writes a single line. We made this point in The Cost of a Loop: a loop reads far more than it writes, often ten to one.

jusTokenMax attacks exactly that side of the ledger. It sits between your heavy inputs and the context window and replaces each one with a faithful, far cheaper equivalent before it costs you a token.

The cheapest token is the one that never enters

Most token advice is about trimming after the fact: shorten the system prompt, summarize the conversation, pick a cheaper model. Those help at the margin. They do not touch the thing that actually fills the window, which is the material the agent reads.

jusTokenMax inverts the order. Every expensive artifact is intercepted on the way in.

What you feed it	Typical reduction
PDF spec or paper	56 percent on real PDFs
Verbose build or CI log	99 percent
Large JSON or API response	99 percent
Jupyter notebook	99 percent
CSV with thousands of rows	99 percent
Git diff with lockfile churn	lockfile collapses to one line
Finding a symbol instead of reading the file	97 percent

The two biggest levers

Attachments. A PDF is not billed as text. It is billed as text plus a rendered page image, roughly 1,500 tokens per page after the API clamps the page. jusTokenMax extracts the text layer to clean Markdown and drops the image channel. You keep the words, stop paying for the picture, and gain something searchable, quotable, and diffable. Almost every spec, design doc, and README an agent reads is born digital with a real text layer, which is why text-first extraction is the right default.

Reading code. Pulling an entire file to find one function is the largest avoidable input cost in agent work. jusTokenMax parses the repository into a symbol map, so a lookup returns the file, the line, and the full signature instead of the file. Re-reading is handled too: a delta read returns only what changed since the last read, not the whole file again.

Measured, not hand-waved

Every number is measured with a real tokenizer, and the benchmark ships in the repository so you can regenerate it.

Single input	Before	After	Reduction
Attention Is All You Need, 15 pages	37,074	14,574	60 percent
Build log, 4,345 lines	107,668	396	99 percent
API response, 2,000 rows	168,023	374	99 percent

Whole tasks, measured in one pass:

Scenario	Before	After	Reduction
Extend an existing website codebase	259,819	103,745	60 percent
Build a project from a PRD	532,789	117,354	77 percent

It compounds inside a loop

Those are single-pass numbers. An agent loop does not read a file once. It reads, edits, re-reads, runs the tests, reads the log, and goes around again. Every iteration pays the input cost afresh, which is why an input-side reduction multiplies rather than adds. The delta reader turns the second and every later read of a file into a diff, and a terse output style caps what the agent writes back.

If you have read our breakdown of the 11 layers of the AI inference stack, this is the context layer doing its job before the cache and the serving engine ever see the request.

Reversible, and safe by construction

Compression is only acceptable if it is not lossy in the ways that matter.

Every original is cached by content hash, and justokenmax retrieve hands the full version back.
Secrets and base64 blobs are masked inside every text digest, so a token saving is also a leak prevented.
Converters are bounded: PDFs are capped, the decompression-bomb guard stays on, nothing shells out, and the read hook fails open.
Every transform is deterministic Python. There is no trained model, no network call, and nothing you cannot read.

Limits, stated plainly

There is no OCR. A scanned, image-only PDF has no text layer, so jusTokenMax detects no saving and passes the original through untouched.
The per-page PDF token figure is a conservative model, not a billed number.
Image savings apply to the base64 pipeline. Native vision downscales regardless, so the reliable win there is bytes.
The code index is a snapshot. Re-run the index after large changes.

Try it

Inside Claude Code, one slash command per prompt:

/plugin marketplace add https://github.com/Kalmantic/jusTokenMax.git
/plugin install justokenmax@justokenmax
/reload-plugins

From then on, reading PDFs, logs, JSON, CSVs, notebooks, and diffs is compressed automatically. For any MCP-capable agent, including Codex CLI, OpenCode, and Cursor, justokenmax install registers it. There is also a plain justokenmax CLI, and justokenmax stats keeps a lifetime ledger of what you saved.

jusTokenMax is MIT licensed and lives at github.com/Kalmantic/jusTokenMax.

Test yourself

1. Which side of a coding agent's bill does jusTokenMax attack?
2. Why does dropping a PDF's page-image channel save so much?
3. What makes the savings compound inside an agent loop?

Does compressing inputs make the agent dumber?: The transforms keep what the agent needs. A PDF keeps its text and loses only the rendered page image. A build log keeps errors, warnings, and the head and tail. A CSV keeps the header, inferred column types, sample rows, and the row count. Anything compressed is cached by content hash, so justokenmax retrieve hands back the original when the agent genuinely needs it.
Where do the biggest savings come from?: Two places. First, the things you attach: a PDF is billed as text plus a rendered page image, and dropping the image channel alone is most of the 56 percent. Second, how agents read code: pulling a whole file to find one function is the biggest avoidable input cost, and a symbol lookup that returns file, line, and signature is about 97 percent cheaper.
Does it work outside Claude Code?: Yes. In Claude Code it is a plugin whose Read hook swaps heavy files for cheap artifacts in place. For any MCP-capable agent, including Codex CLI, OpenCode, and Cursor, justokenmax install registers it. There is also a plain justokenmax CLI.
What does it not do?: There is no OCR, so a scanned, image-only PDF has no text layer and is passed through unchanged. The per-page PDF token figure is a conservative model rather than a billed number. Image savings apply to the base64 pipeline, because native vision downscales regardless. The code index is a snapshot, so re-run the index after large changes.