Cut LLM Token Costs with UCCP Compression

Key Takeaways:

• UCCP rewrites HTML, JSON, and source code into compact text that LLMs read directly, so there is no decompression step and no token cost to expand it.
• The repository reports an 87% byte reduction on a full marketing-site HTML page, but about 19% on an academic article and 12% on a JSON array.
• Token savings with the system prompt amortized over 10 messages are reported near 78% for HTML, 43% for JSON, and 7% for code, counted with tiktoken’s cl100k_base encoding.
• The system prompt is overhead. On a single message, compression can cost more tokens than it saves, which is why UCCP ships an automatic skip decision.
• It is early software: v0.0.11, Go only, one GitHub star as of September 2026, with Python, JavaScript, and Rust libraries still planned.

The Cost of Long Context

Context windows grow faster than inference infrastructure keeps up with, and the bill scales with what you put in them. A research team from NYU, Columbia, Princeton, the University of Maryland, Harvard, and Lawrence Livermore National Laboratory published a June 2026 paper on Latent Context Language Models, covered by VentureBeat, describing encoder-decoder models that compress input context before the decoder prefills. The paper reports 4x compression holding 91.76% accuracy on the RULER benchmark against 94.41% uncompressed, and 16x compression at 75.06%.

That work attacks the problem at the model layer and requires a trained encoder-decoder pair. UCCP works at the text layer instead: it rewrites the payload into a shorter readable form before the API call, and the model reads it directly, given a small system prompt. No training, no model swap, no decompression pass.

UCCP reports that a full marketing-site HTML page dropped from 75,749 bytes to 9,945 bytes, an 87% reduction, and that the same page consumed about 78% fewer tokens once the system prompt was amortized across ten messages. Those figures come from the project’s own README and benchmark harness. The honest version is messier: the same tool shaved about 19% off an academic HTML article and 12% off a JSON array.

That spread is the useful part. UCCP (Ultra-Compact Content Protocol) was built to cut token spend inside a production LLM content pipeline and then open-sourced under MIT. If you pay per token for scraped pages, tool-call payloads, or agent-to-agent messages, the question is which of your inputs look like the 87% row and which look like the 12% row.

What UCCP Actually Does

gzip and Brotli are built for transport, not for models. Their output is binary, so a language model cannot read it, and getting the content into a prompt requires expanding it first, which costs tokens for the expanded text anyway. UCCP rewrites content into a shorter but still plain-text form, and a system prompt teaches the model the notation.

The practical consequence is one API call instead of two. There is no decompression pass, no second model invocation to unpack the payload, and no binary blob the tokenizer chokes on. The compressed string goes into the prompt, the system prompt goes above it, and the model answers against it.

It is important to clarify what UCCP is not, because several token-compression tools get lumped together. UCCP is a Go library and CLI that transforms text. It is not a proxy that intercepts traffic, and its JSON handling is a dictionary of abbreviated keys rather than a general-purpose structural crusher. Projects like Headroom take the proxy approach, sitting between your application and the provider with content-type-specific strategies. The README’s own comparison table places UCCP’s range at roughly 10% to 90% content-dependent against gzip at 70% and Protobuf at 60%, with the caveat that binary formats are not model-readable. UCCP’s advantage is the zero-decompression property, not a superior ratio.

How UCCP Works

The transformation set is domain-aware. HTML, JSON, and source code each get different rules, because the redundant parts of a web page have nothing in common with the redundant parts of a tool-call response.

• Type prefixes tag what follows: F: for framework, J: for job, f: for file.
• Symbol operators replace common verbs: an arrow for implements, a left arrow for uses, a check mark for success.
• Abbreviations shorten recurring words: fn for function, impl for implementation, comp for component.
• Path compression collapses directory names, so src/components/ becomes src/comp/.
• Article removal and whitespace collapse strips “the”, “a”, and “an” and folds repeated spaces.

A sentence like “Successfully implemented ActivityFeed with infinite scroll” becomes impl ActivityFeed with infinite-scroll. A 487-byte project-architecture JSON object, in the README’s example, becomes a 187-byte line: F:R+TS|B:Vite|L:TS|P:api->api.get()<-src/l/api.ts. The model reconstructs framework, build tool, language, and API pattern from that, given the system prompt.

The design detail that matters most in production is the skip decision. core.ShouldCompress evaluates size and expected ratio before doing anything, and declines to compress when the output would not be shorter or when the system-prompt overhead exceeds the savings. On a one-shot “Hello” call, UCCP does nothing. That guardrail exists because the README is explicit that compression past roughly 90% is lossy summarization rather than faithful abbreviation, and that lossless abbreviation-only compression lands closer to 20% to 70% depending on content shape.

Measured Savings From the Repository

Every figure below is reported by the project’s README and benchmark package. The harness counts tokens with tiktoken’s cl100k_base encoding and amortizes the system prompt over a fixed ten-message depth, exposed in the code as DefaultAmortizationDepth = 10. There is no independent third-party evaluation of UCCP as of September 2026, so treat these as author-measured numbers on specific documents, not a general performance guarantee.

Bytes shaved and tokens shaved are different quantities, and most write-ups on prompt compression blur them. UCCP’s symbols and prefixes can tokenize into more than one token depending on the model’s vocabulary, so a byte reduction is not a token reduction. The benchmark package addresses it by reporting both: a raw token compression figure with no system-prompt overhead, and a net ratio with that overhead baked in.

Read the three headline token numbers together and the shape of the tool becomes clear. HTML with heavy boilerplate is the win. JSON with repeated keys is a moderate win. Code is close to a wash, which makes sense: source code is already dense with information and short on filler.

Install and Run the CLI

Version v0.0.11, tagged in September 2026, ships the uccp CLI and GoReleaser-built binaries for Linux, macOS, and Windows on amd64 and arm64. If you have Go 1.21 or newer, the install is one command:

go install github.com/aguzmans/uccp/cmd/uccp@latest

# Or skip Go entirely and grab a prebuilt binary:
# https://github.com/aguzmans/uccp/releases/latest

Compressing a live page and printing the savings report works like this:

Note: The following code is an illustrative example and has not been verified against official documentation. Please refer to the official docs for production-ready code.

# Fetch a URL, compress, and print stats to stderr
uccp --url https://example.com/ --stats > page.uccp

# --- uccp stats ---
# source: https://example.com/
# domain: html
# original bytes: 75759
# compressed bytes: 9945
# byte reduction: 86.9%
# tokens saved (~): 20934

# Pipe content in from anywhere
curl -s https://example.com/some/article | uccp --stats > page.uccp

# Compress a local file with an explicit domain
uccp --file api-response.json --domain json > out.uccp

# See all flags
uccp --help

# Note: production use should bound response size, set request timeouts,
# and cache compressed output rather than re-fetching on every call.

The --domain flag matters more than it looks. Pipe a JSON tool-call response without declaring it JSON and you get the generic path, losing the dictionary-based key abbreviation that release v0.0.8 added for exactly that traffic pattern. Set the domain explicitly for anything you compress at volume.

Using the Go Library

If you are calling the API from a service rather than a shell, the compressors live in domains and the shared helpers in core:

go get github.com/aguzmans/uccp

package main

import (
 "fmt"

 "github.com/aguzmans/uccp/core"
 "github.com/aguzmans/uccp/domains"
)

func main() {
 compressor := domains.NewCodeCompressor()

 original := "Successfully implemented ActivityFeed with infinite scroll"
 compressed, _ := compressor.Compress(original)

 // "impl ActivityFeed with infinite-scroll"

 ratio := core.CalculateCompressionRatio(original, compressed)
 fmt.Printf("Compression: %.1f%%\n", ratio*100)

 // Let UCCP decide whether compression is worth it at all.
 result := core.ShouldCompress(compressor, original, core.DefaultThresholds)
 if result.WasCompressed {
 // Prepend compressor.SystemPrompt() before sending to the model.
 prompt := compressor.SystemPrompt() + "\n\n" + compressed
 _ = prompt
 }

 // Note: production use should cache SystemPrompt() per compressor version,
 // retry on transient model errors, and log the WasCompressed decision
 // so you can audit when the skip logic fires.
}

Two operational details from the README deserve attention. Always send the system prompt from the compressor version that produced the output. Older prompts do not document newer abbreviations, and a model handed notation it has no key for will guess. Compressed output can also change between versions as new abbreviations are added, so if your test suite snapshots compressed bytes, expect to refresh those snapshots on upgrade. Decompression is backward compatible: newer versions still read files written by older ones.

Threshold tuning is available if the defaults do not fit. core.DefaultThresholds compresses above 200 bytes with a minimum 30% saving, and the README also documents AggressiveThresholds, ConservativeThresholds, and a custom struct with MinSize and MinRatio fields. For a pipeline where one misread call is expensive, raising MinRatio is the safest knob.

Where UCCP Sits Among Other Approaches

Prompt compression of the LLMLingua school, where a small model scores each token’s informativeness and drops the low-value ones, reduces tokens across arbitrary input, including prose, but it is lossy by construction and requires a second model in the loop. UCCP is rule-based and preserves structure, but it only shines on content with removable boilerplate. The prompt compression overview at leanlm.ai frames the tradeoff well: informativeness scoring preserves essential meaning but cannot recover what it dropped.

Latent context compression, the LCLM work described above, compresses at the model layer and delivers real compute savings, but it requires a compatible model and a training pipeline. UCCP requires neither.

Proxy-layer compressors are the closest practical peers. Headroom sits between your application and the provider and compresses tool outputs, logs, files, and RAG chunks before they reach the model, with content-type-specific strategies and no code changes. That is a different integration model: UCCP is a library you call, Headroom is a layer you install. The two are not mutually exclusive, and the choice depends on whether you want to control compression in application code or intercept it at the transport boundary.

Prompt caching is the lever UCCP is most often confused with, and it is not a substitute. Caching cuts the cost of repeated identical context; UCCP cuts the size of the context in the first place. They stack, and for a workload with a stable system prompt and repeated content, caching usually moves the bill more on its own. Our analysis of inference cost trends covers where caching and model routing sit relative to compression in the cost stack.

Limitations and Trade-offs

UCCP is a v0.0.x project. The repository showed 30 commits and one star in the GitHub API check run for this article, and the README describes the release line as early. Go is the only first-class language, with Python, JavaScript, and Rust libraries listed as planned rather than shipped. If your RAG stack is Python and you want to avoid a subprocess call per document, you are waiting on that roadmap or writing your own binding.

Compression ratios are the second caveat, and the repository is unusually upfront about it. The 60% to 90% range applies to boilerplate-heavy inputs. Lean prose, small JSON payloads, and most code come in far lower. A pipeline that scrapes documentation portals will see a very different return than one compressing chat transcripts.

Then there is the lossy boundary. Compression above roughly 90% involves summarizing structure rather than preserving every field, per the README, and a field you dropped is a field your downstream task cannot read. Before enabling aggressive thresholds, decide per pipeline whether the consumer needs full fidelity or just the gist. A retrieval-ingestion job and an agent-to-agent status message have different answers.

The system prompt itself is a real cost that most compression discussions ignore. It is a fixed token block attached to every compressed payload, and it only earns its keep if you use it many times. On a single call it is pure overhead, which is why the skip logic exists. The ten-message amortization depth the benchmark uses is an assumption, not a law: if your real traffic reuses the prompt across only two or three messages, the net savings fall well below the reported figures.

Finally, the notation needs validation on your model. A model that misreads field boundaries or nested arrays will produce a confidently wrong interpretation of compressed data, and you pay for that in rework rather than tokens. No published independent evaluation of comprehension accuracy on UCCP output exists as of September 2026. Until one does, treat the compressed string as something to test against your own eval set, not something to trust because the byte count went down. The same held true for the compact tool-manifest approach in our coverage of a token-efficient MCP client, where the project’s headline reduction described one narrow operation rather than the whole interaction.

When to Reach for UCCP

The clearest use case is scrape-and-feed pipelines. If you pull full HTML pages, strip nothing, and shove the result into a prompt, the boilerplate is pure waste and UCCP attacks it directly. The measured 87% on a marketing page is the row to test your own corpus against: run uccp --url against twenty representative pages and look at the distribution before committing.

The second fit is multi-agent messaging, where the same verbose JSON structure travels between workers repeatedly. That is the pattern where a fixed system prompt amortizes well and a repeated schema compresses hard. The README’s own illustrative agent scenario, which it labels a best case rather than a benchmark, describes exactly this shape.

Reach for something else when the payload is prose, when the consumer needs every field intact, or when the whole interaction is a single short call. In those cases UCCP either does nothing or adds overhead. It is also not a substitute for the cheaper wins: routing routine requests to smaller models, caching stable context, and trimming retrieved passages before they enter the window usually move the bill more, and they do it without adding a notation layer your team has to learn.

The strongest argument for UCCP is that it stacks with those levers, it runs locally, it costs nothing to license, and its skip logic means a wrong guess degrades to no compression rather than to a broken prompt. For a tool at v0.0.11 with one star and no independent benchmark, that is a reasonable risk profile for an experiment. It is not yet a reason to build a cost model around 87%.

Related Reading

More in-depth coverage from this blog on closely related topics:

• Enterprise Kubernetes DNS via Tailscale VPN
• Implementing Kruskal’s Algorithm in Go

Sources and References

Sources cited while researching and writing this article:

• GitHub – aguzmans/uccp: Ultra-Compact Content Protocol · GitHub
• Context compression finally works in production: new research cuts LLM input 16x without the accuracy hit
• Prompt Compression: Cut LLM Token Costs 2-20× – leanlm.ai