Benchmarks

Measured,
not promised.

Reproducible, offline measurements of every package — headline claims and runtime cost. No network and no API key anywhere in the suite: model calls use fake, provider-shaped clients.

reproduceoffline · no keys · runs on your laptop
$ uv run python benchmarks/run_all.py                    # all tables below
$ uv run --with tiktoken python benchmarks/run_all.py    # adds exact-token accuracy
Headline numbers

Five numbers we stand behind.

0.0%
token error
exact mode (default)
99.7%/30.1%
log compression
repetitive / mixed-entropy — both shown, honesty is the brand
136×
replay speedup
modeled at 4 ms/call
11.66 µs
instrument() overhead
per call
5/5
compressions restore byte-for-byte
expand() == original, every kind
env·Python 3.12·Windows 11·tiktoken installed·generated 2026-07-07
cendor-coreFoundation

Token counting, Decimal pricing, and the event bus every tool rides — measured for accuracy first, speed second.

MetricResultNotes
Offline heuristic error vs tiktoken — prose35.8%heuristic 163 vs exact 120 tokens
Offline heuristic error vs tiktoken — code8.4%heuristic 103 vs exact 95 tokens
Offline heuristic error vs tiktoken — json18.4%heuristic 62 vs exact 76 tokens
Exact mode error (default)0.0%OpenAI counts are exact out of the box — tiktoken is a required dependency
Offline subword fallback vs o200k (Claude/Gemini)33.2%the defensive no-tiktoken fallback; by default Claude/Gemini use o200k directly
tokens.count throughput — OpenAI heuristic1.24M ops/son a 1.4 KB string
tokens.count throughput — tiktoken exact9.7K ops/son a 1.4 KB string
instrument() overhead per call11.66 µsbus emit + usage extraction + Decimal pricing; over a no-op client
bus dispatch (3 subscribers)1.96M emits/ssynchronous fan-out to subscribed tools
cendor-contextkitAssemble

Context assembly under a hard token budget — the claim isn't speed, it's that the budget is never exceeded and the output is deterministic.

MetricResultNotes
Budget utilization100%used 3500/3500 tokens (reserve 500); never overflows
Overflow safety0 over budget3/25 blocks kept/shrunk, rest dropped by priority
Determinismexact ✓identical inputs → byte-identical messages
assemble() latency (25 blocks)23.80 msincludes per-block token counting + eviction + ordering
cendor-squeezeCompress

Reversible payload compression — ratios depend heavily on input shape, which is why the logs row appears twice.

MetricResultNotes
JSON compression48.9%90.1 KB → 46.0 KB; 50.1% fewer tokens
Logs (repetitive) compression99.7%70.1 KB → 0.2 KB; 99.8% fewer tokens
Logs (mixed-entropy) compression30.1%80.9 KB → 56.5 KB; 35.9% fewer tokens
Code compression52.5%11.9 KB → 5.7 KB; 42.4% fewer tokens
Prose compression49.1%8.6 KB → 4.4 KB; 46.6% fewer tokens
Reversibility (expand() == original)5/5 exactevery kind restores byte-for-byte
compress() throughput (JSON)56 MB/s90 KB payload, 1.57 ms/call
cendor-tokenguardBudget

Budgets and spend tracking layered on instrument() — the question is what @budget adds to every call.

MetricResultNotes
Added overhead per call (@budget + track)4.09 µsrecords spend by tags + checks the active budget(s)
report() over 5000 spend rows7.64 msgroup-by aggregation into per-tag cost rows
cendor-cassetteTest

Record once, replay forever — the speedup is measured against a fake client sleeping 4 ms/call, a deliberate floor.

MetricResultNotes
25-call run: replayed vs live852.44 µs vs 116.03 mslive = fake client sleeping 4 ms/call (real LLMs are far slower)
Replay speedup136×at the modeled 4 ms/call; scales with real latency
Replay overhead per call34.10 µshash the request, look up the recorded response, reconstruct it
cendor-acttraceAudit

A tamper-evident hash chain with no server — append/verify throughput, signing cost, and that a single edited byte is caught.

MetricResultNotes
Append throughput (in-memory)16.4K entries/ssha256 chain + default PII redaction per entry
HMAC signing overhead+2%per-entry HMAC-SHA256 on top of the chain hash
Append throughput (file-backed)2.5K entries/sflush + fsync a JSONL line per entry on a kept-open handle
verify() throughput58.7K entries/sre-walks a 2001-entry chain in 34.1 ms
Tamper detection✓ detectedone edited byte → chain hash mismatch → verify() returns False
Method & caveats

How the numbers were made — read before quoting.

Every caveat below is part of the result, not fine print. If a number above looks too good, its honest bound is here.

No network, no keys.

Every model call is a fake client matching the provider's shape.

Token accuracy is measured against tiktoken.

The offline heuristic is compared to tiktoken's exact counts; the Claude/Gemini rows are a cross-tokenizer ballpark, not ground truth.

The cassette speedup models a live call at 4 ms.

Production LLM calls are 100–1000× slower, so real-world speedup is far larger — the number shown is a floor of the mechanism, not a promise.

Compression depends on input shape.

The log rows report both a repetition-heavy sample (~55% identical heartbeat lines) and a mixed-entropy one (~15%) — the mixed row is the honest lower bound.

Throughput is single-machine and relative.

Re-run locally for your own figures: uv run python benchmarks/run_all.py.