A long TTL is earned, never assumed
Freshness is decided per endpoint from what the data actually is — not read off a Cache-Control header the upstream set for a browser, and not guessed from the size or shape of a payload.
Platform / Earned
Freshness you can defend.
Caching is where a data layer either earns trust or quietly loses it. Cache too eagerly and
you serve yesterday's number as today's; cache too little and you throw away the compression
that makes the whole thing worth it. swarmsDB treats a long TTL as something a class has to
earn — and makes the safe choice the default when it cannot.
ttl: earned, else 3600 What cannot be proven fresh demotes
If a class cannot compute its own freshness boundary, it does not get the benefit of the doubt. It falls back to a one-hour default rather than being cached long on a guess.
ttl: earned, else 3600 Every TTL is capped, so mistakes self-heal
No cache entry lives longer than thirty days, whatever the calculation says. A boundary set too generously corrects itself within a bounded window instead of serving stale data indefinitely.
cap: 30 days Why it matters
Freshness is the load-bearing part of the pricing model. A cache is only worth riding if what it serves is trustworthy — so the rate you pay to ride a warm cache is defensible only because the cache itself is disciplined about when it may be warm.
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.
Measured on our own agent-swarm workload. swarmsDB is battle-tested, not yet widely adopted — external traction is the next milestone.