Surfil
Surfil/Products/Cap
// surfil cap · consumerlive

Cut token spend with measured, signed savings.

Most of an agent's bill is context, and most of that context goes through the prompt cache - where a write costs 1.25x and a read costs 0.10x. Whether that trade pays depends on how often each write is read back, and nothing in your stack tells you.

surfil verify rcpt_8f2a
Signed savings receiptVALID
receiptrcpt_8f2a
typeprefix-cache + prune
saved48,200 tokens
measuredbefore / after
signatureed25519:… (epoch 7)
verifiedoffline · no account
Run surfil verify on any receipt - the signature is the proof.
What it does

Trim tokens. Sign the result.

Cap measures every write and every read from the provider's own token counts, groups them by conversation, and shows the premium your bill carried, how often it was earned back, and what one context token therefore costs. Reported in tokens, never an invented dollar figure. Where a request carries no cache breakpoint, Cap also removes context a later turn already superseded - and says zero when there is none.

Cache economics - Your provider bills a cached write at 1.25x and a read at 0.10x. Cap measures which of your writes ever earn that premium back.
Measured, not asserted - Reports what your traffic actually cost, measured and signed. No savings percentage is published.
Signed receipts - Every savings figure is a server-signed output - verifiable, not asserted.
Token-denominated - Savings are stated in tokens. No conversion to dollars you didn't ask for.

Proof, not promises

Cap produces one metric type on the shared spine: cache premium, measured per conversation. Every paid output is signed (Ed25519) and verifiable offline with no account. Zero-trace: your source never leaves the device.

$ surfil verify rcpt_8f2a
✓ VALID (offline · epoch 7)
In your dashboard

Cap, as you'd actually see it

hub.surfil.com/cap
275Kcache premium paid, in token-equivalents
71%cache-read ratio
1.9xreads per written token
12signed receipts issued
Illustrative Cap ledger - your numbers come from your own measured traffic.
How it works

How Cap does it

1Cap sits on the one interception layer and watches every agent call.
2Prefix-cache tuning keeps the provider prefix hash byte-exact so cache keeps hitting.
3Writes that are never read back are named, per conversation, from the provider's own counts.
4The measured saving is signed into a receipt - verify it offline, no account.
Use cases

Where Cap earns its place

Runaway monorepo bills

One repo, four agents, no shared cost view - Cap measures the recoverable spend.

Invoice-grade numbers

Agencies cite signed savings receipts on client invoices, never rough guesses.

Model spend control

See which model is cheapest per fix on your own work, measured by Bench.

Claude CodeCursorCodexCopilotMCP agents
FAQ

Questions developers ask first

Are the savings real or estimated?

Measured and signed, never estimated. We publish no savings percentage: whether Surfil can cut tokens at all depends on whether your agents already use prompt caching, and Cap measures which case you are in.

Does tuning the cache break it?

No. Passthrough is byte-exact; the provider prefix hash is preserved and asserted in CI.

Do you report dollars or tokens?

Tokens where the fact is tokens; we only ever translate to currency conservatively.

Works well with

One spine - products compound

Add Cap to your agents.

Core installs with Starter; Cap plugs into the same interception point - no second layer, no new setup.