We Merkle-seal our token savings — here is how to verify them yourself

The trust problem with orchestrator claims

Every orchestrator, wrapper, or "AI cost optimizer" in this space publishes a savings number. Some are honest. Some are cherry-picked demos. Some are just marketing copy with a percentage sign attached. As a developer, you have no way to tell the difference without running the tool yourself for weeks and doing your own accounting — and even then, you're trusting whoever built the logging pipeline not to have thumbed the scale.

We ran into this problem from the other side: we built Chaser, an orchestrator that reduces token consumption for Claude Code workflows, and we didn't want to ask anyone to take our word for it. So instead of a landing page with a big number, we publish a cryptographically sealed log of the underlying measurements and ship a verifier you can run completely offline, with no dependency on our servers or our goodwill.

How the sealing works

The mechanism is a Merkle tree, built the same way certificate transparency logs do it (RFC 6962). If you haven't touched this outside of blockchain contexts, here's the short version:

• Every individual measurement (a before/after token count for a given run) is hashed.
• Pairs of hashes are combined and hashed again, recursively, until you get a single root hash.
• That root hash is published, timestamped, and never changes without invalidating everything under it.
• Anyone holding a single leaf (one measurement) and an "inclusion proof" (the sibling hashes along its path to the root) can recompute the root hash themselves, offline, with zero trust in our infrastructure.

The RFC 6962 part matters because it also defines consistency proofs: you can verify that a newer version of the log is strictly an append-only extension of an older one, which prevents us from quietly rewriting history — removing an inconvenient bad run, for instance. If the tree grows, old entries stay provably in place.

Concretely: we log raw token counts per run into an append-only structure, build the Merkle tree over those entries, publish the root, and expose the leaves plus the proofs. You don't need to trust our dashboard. You need arithmetic and a hash function.

The numbers, with context

We're not going to round these up or replace them with best-case screenshots. These are the medians from our recorded traces, and they should be read as exactly that — medians, not averages, not peak performance, not cherry-picked runs.

• Max compression mode: median 71.7% reduction, measured on our traces (123 observations). This is the aggressive setting, where Chaser restructures context more heavily before it hits the model. It costs some latency in exchange.
• Relay pruning: median 64.8% reduction, measured on our traces (72 observations). This is a lighter-touch mode that trims relay/handoff context between agent steps without touching the core prompt structure. Smaller sample, smaller intervention, still meaningful.
• −52.5% measured on AI-Scientist-v2 vs baseline. This one is a single, named external benchmark rather than an aggregate over our internal trace set — we're flagging that distinction explicitly rather than blending it into the other two numbers.

Medians matter here because token savings distributions are not symmetric: a handful of huge wins on long, redundant contexts will drag an average up in a way that misrepresents what a typical run looks like. Medians are more boring and more honest.

How to verify it yourself

You don't need our word, our dashboard, or a support ticket. The workflow is:

1. Pull the published example bundle — a real entry from our sealed journal (13,000+ entries) with its inclusion path and root — from the verification section. Bundles for any other journal entry are available on request.
2. Run the offline verifier against it — it recomputes hashes locally and checks that your leaf reduces to the published root.
3. Optionally, pull an older root and check a consistency proof to confirm nothing was rewritten between versions.

No network calls are required for step 2 or 3 beyond fetching the published data itself. If the verifier reports a mismatch, that's a finding worth publishing, not a bug report to file with us quietly.

What to actually do with this

If you're evaluating orchestrators for Claude Code and you keep hitting vague "up to X% savings" claims with no way to audit them, that's a reasonable place to be skeptical. The alternative we're proposing is narrow but concrete: don't read our numbers, recompute them.

Start with the transparency log itself, then try the lightweight plugin if you want to see the effect on your own traces rather than ours:

npx skills add HQU-kenaxvi/chaser-lite

Every figure above carries its population and its reservation on purpose. Full methodology, service-level commitments and the sealed manifest live on the transparency page (French; the verification walkthrough is bilingual).