Data / Measured

What actually compresses.

Every claim on this page is measured against our own production telemetry, and the honest part is the shape of it: savings are real but not uniform. 76% smaller is true on requests that project a section — and a mid-sized response compresses under 1.2×. Stating both is what makes the headline survive a sceptical reader.

The proof

Compression is the product.

On requests that project a section, smaller payloads — 392 million chars served where the upstream sent 1.64 billion chars. That is the difference between an agent reading one source and reading several within the same context window.

Across projected requests 76% smaller · 4.2×
Raw upstream1.64 billion chars
Served392 million chars

Not uniform — concentrated. Savings concentrate in wide payloads rather than spreading evenly: the top 10% of requests account for 87% of all characters saved, while a mid-sized response typically compresses under 1.2×.

largest single reduction
5,608×
8,457,367 chars from upstream
1,508 delivered to the caller

eodhd/eod_bulk_last_day — a live upstream fetch, not a cache replay. Bar not to scale; at true ratio the served bar is a fifth of a pixel.

More in this area

Provider catalogue53 providers, 454 live endpoints.Bring your ownWrap any REST, GraphQL or MCP source as a first-class connector.

Point one agent at it.

Connect over MCP or REST. If your agents read more than one source, the context bill is the first thing you will see move.

Start building See how it works

Measured on our own agent-swarm workload. swarmsDB is battle-tested, not yet widely adopted — external traction is the next milestone.