Live Compression

Live compression rewrites the newest tool output in a request — the result of the call the agent has just made — before it reaches the provider.

It is the opposite end of the prompt from HiveState. History compression rewrites the head of the conversation, which is why it has to be careful with the provider's prefix cache. Live compression touches only the tail, past the reach of any cache, so shrinking it is pure gain. The two run together: live compression first, so HiveState sees an already-slimmer delta.

Why the tail is worth compressing

An agent's tool output is where the tokens go. A file read, a JSON API response, a test log or a diff arrives verbatim, indented, and is paid for at input rates on every turn that carries it. The content the model needs is a fraction of the bytes.

Measured on the transforms as shipped: a JSON payload of 11,802 bytes becomes 2,592 with every value identical — the saving is entirely indentation and encoding overhead.

Lossless by default

allow_lossy governs the difference between compacting and discarding.

Off (the default) leaves only transforms that cannot change what the model reads:

• json_compact — removes indentation and insignificant whitespace;
• ANSI escape stripping — removes terminal colour codes from logs.

On adds transforms that drop content: truncating long JSON arrays, collapsing rows in CSV and TSV tables, trimming context around diff hunks with the hunk headers recomputed. On the same test corpus these take 18,129 bytes to 678 — but the model no longer sees what was removed. That is a policy decision, not a default.

What is never touched

• Anything but the last turn. Only the live zone is rewritten; earlier turns stay byte-identical, because rewriting them would invalidate the provider's prefix cache and cost more than it saves.
• Tools that read by offset. read, grep and their kind return content whose line numbers and byte positions the agent will use. Compressing those would break the next call. The built-in list is extended with protected_tools, where an entry may end in * to cover a whole MCP server.
• Blocks below the floor. Under min_bytes nothing is attempted, and a transform has to save at least min_gain_percent to be applied at all.

Configuration

live_compression:
  enabled: true
  allow_lossy: false      # only lossless transforms
  canary_percent: 0       # 0 means every request
  live_turns: 1           # only the newest turn is the live zone
  min_bytes: 512
  min_gain_percent: 5
  protected_tools: []     # extends the built-in never-compress list

canary_percent: 0 means everyone

The canary picks by a hash of the API key, so a caller sees consistent behaviour rather than flickering between compressed and not. That also means a low percentage on an environment with few keys can exclude all of them, stably — which looks like the feature being off rather than partially applied. Zero, with enabled: true, means every request.

Per-request opt-out

curl https://api.modelhive.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-mh-..." \
  -H "x-hive-live-compression: false" \
  -d '{"model": "gpt-4o", "messages": [...]}'

What the response tells you

Header	Meaning
x-livezone-blocks	How many tool-output blocks were rewritten
x-livezone-bytes-saved	Bytes removed from the request body

Both are absent when nothing was compressed — including when the feature is off, which is how you tell the two apart from the outside.

Order of operations

PII is redacted before anything compresses, so a placeholder is what gets compacted — never the original value.