billion-context: ultra-long context setup and cost

billion-context is not a bigger context window; it is a compression proxy between the agent and the model API. It rewrites consumed dialogue into layered summaries so a session runs longer, at the cost of compression calls and some information loss.

A proxy, not a window

The model window is a hard limit; a plugin cannot change it. billion-context compresses history before the request reaches the model, reducing carried tokens (source).

It targets long-session degradation. When the context fills, sessions either truncate or lose the main thread after compaction; a proxy makes compression controlled and partially reversible.

The word proxy matters. Every request passes through it, which also means an extra processing layer and an extra call.

Three mechanisms: layers, increment, restore

Three mechanisms define its capability boundary.

Layered summaries keep the thread. Older content is compressed harder, recent content keeps more detail; good for long work, poor for verbatim recall.

Incremental writes avoid recompressing everything. Only new content is processed, but summary depth grows, so retrieval crosses more layers.

Decompression is the remedy. Detail lost in summaries can be restored, but not automatically; the model or you must trigger it.

When to use the four tools

The plugin injects four context management tools.

1. compress: force compression, useful at a task boundary.
2. decompress: restore detail when a summary missed something important.
3. search_context: search summaries and compressed content for earlier decisions.
4. acp_status: inspect proxy state when compression did not happen or output changed.

Normal use does not require manual calls. The model decides timing and content; manual tools are for diagnosis and correction.

Check status before searching. Status tells you whether compression ran and at which layer; search tells you whether detail remains.

The cost equation

Two entries, not just "saved tokens."

Savings: later requests carry less history, lowering input tokens; long sessions accumulate the benefit.

Spending: compression calls the model to generate summaries; decompression and search may also call.

Net effect depends on session length. Short sessions do not recover compression cost; long sessions clearly save. Enabling it for every short task can be more expensive.

Prefix caching is the third variable. Compression rewrites the request prefix, which may invalidate the cache; lower cache hit rates can raise actual cost above expectations (source).

Enable by scenario. Long projects and multi-day sessions benefit; one-off Q&A and short tasks should leave it off.

Fit and poor fit

It fits long, not exact.

Do not rely on summaries for verbatim accuracy. Contracts, regulations, and line-by-line code review need originals; use search or decompression when exact text matters.

Do not enable for short sessions. Compression is an investment that pays back only over length.

Configure and verify

Three steps: install, configure, verify.

1. Install billion-context from the Hub or CLI and restart so it registers.
2. Confirm the proxy is enabled and choose a compression strategy for the task.
3. Open a long session and watch for compression records.
4. Use acp_status to confirm layer count and the last compression time.
5. Use search_context to retrieve an early conclusion.

The core verification is "thread intact, detail retrievable." A successful compression is not enough; the model must still answer questions about early agreements.

Test in a throwaway session first. Enabling it in production makes it hard to tell whether compression or the task caused a problem.

Risks: lost detail and invalidated cache

Two risks to know before enabling.

1. Summaries lose detail. Lossy compression is unavoidable; write important conclusions explicitly or store them separately.
2. Cache invalidation. Rewriting the prefix lowers cache hits and raises cost; watch actual spend in long sessions.
3. Deep layers. Long incremental compression deepens the structure and slows retrieval; do a full reorganization periodically.
4. Harder diagnosis. An extra proxy layer means a problem may be compression, not the model; check acp_status first.

Risks are not a reason to avoid it; they are a reason to plan. Save key conclusions, monitor cost, and check status first when debugging.

Next steps

Judge session length before enabling. For the built-in compaction mechanism, read What context compaction is. For compaction failures, read What to do when compaction fails. For context overhead, read Plugin context overhead.

Sources: billion-context plugin page, DeepSeek Harness docs, DeepSeek Harness docs - Context and compaction