-
-
Savings Dashboard
-
Approval Screen
Inspiration
Inspiration — the idea
AI output is priced by the token, and today nearly all of those tokens are generated on the most expensive hardware in the chain — the cloud model — including the large share of output that is perfectly predictable from a shared vocabulary: product names, quantities, standard phrases, fixed formats. Expansion is mechanical work. Mechanical work does not need a frontier model; it needs a codebook and a small local program.
So: let the model emit a compressed dialect, and let the user's device expand it. The cloud generates a fraction of the tokens. The expansion happens deterministically on hardware the user already owns, at zero marginal cost, with no model involved on the receiving end at all.
PayPal's own published research shows why this matters at their scale: their internal LLM gateway meters on the order of 200 billion tokens a day (PayPal Inc., 2026), and PayPal researchers publish on prompt compression (Yan Song, PayPal Inc., 2026). Token volume is a first-class cost problem in production AI systems. This project attacks it from the output side — the side nobody else in this field is working.
What it does — the proof: Compact Checkout
A hackathon prototype has to run the mechanism somewhere concrete, so we ran it where mistakes cost money: agent checkout.
An AI shopping agent describes its intended purchase. Instead of verbose prose, it emits a Compact Checkout packet — the payment-intent dialect:
- A header, sent once: format version, codebook, merchant, currency, and the buyer's spending mandate stated as a claim in machine-checkable form — enforced against the mandate pinned on the buyer's own device. A header that does not match the pinned mandate is blocked: the packet cannot inflate its own policy.
- Line items as compact positional records, with amounts in integer cents in a verbatim lane — money is not coded, not compressed, and not represented as a float.
- A checksum sealing the packet.
The buyer's device runs the expander: a deterministic decoder (no model downstream of the packet, by design). It verifies the packet's schema, checksum, and totals, checks it against the buyer's mandate, and renders the approval screen from the packet itself — so the thing the buyer approves is byte-identical in meaning to the thing that gets charged. Only on the buyer's explicit confirmation does it call the PayPal Orders API (sandbox) to capture, and the receipt pairs the PayPal transaction ID with the packet checksum.
Live sandbox capture, verified November 11, 2026: scenario S1 (grocery), gate approved, packet checksum 2fd97b92, PayPal sandbox order 7TS33941CP075764J, payer approved in the sandbox checkout flow, capture COMPLETED, transaction 3PG84047F4385863A, amount $134.24 — exactly the packet total the buyer approved.
Measured results (tiktoken, o200k_base, reproducible via measure.py): flagship grocery basket 407 prose tokens → 182 packet tokens (2.24×); across four scenarios 1,056 → 514 tokens (542 saved); 1.62× at 1 item growing to 2.38× at 40 items because the header is paid once.
What it does
A hackathon prototype has to run the mechanism somewhere concrete, so we ran it where mistakes cost money: agent checkout.
An AI shopping agent describes its intended purchase. Instead of verbose prose, it emits a Compact Checkout packet — the payment-intent dialect:
- A header, sent once: format version, codebook, merchant, currency, and the buyer's spending mandate stated as a claim in machine-checkable form — enforced against the mandate pinned on the buyer's own device. A header that does not match the pinned mandate is blocked: the packet cannot inflate its own policy.
- Line items as compact positional records, with amounts in integer cents in a verbatim lane — money is not coded, not compressed, and not represented as a float.
- A checksum sealing the packet.
The buyer's device runs the expander: a deterministic decoder (no model downstream of the packet, by design). It verifies the packet's schema, checksum, and totals, checks it against the buyer's mandate, and renders the approval screen from the packet itself — so the thing the buyer approves is byte-identical in meaning to the thing that gets charged. Only on the buyer's explicit confirmation does it call the PayPal Orders API (sandbox) to capture, and the receipt pairs the PayPal transaction ID with the packet checksum.
Live sandbox capture, verified November 11, 2026: scenario S1 (grocery), gate approved, packet checksum 2fd97b92, PayPal sandbox order 7TS33941CP075764J, payer approved in the sandbox checkout flow, capture COMPLETED, transaction 3PG84047F4385863A, amount $134.24 — exactly the packet total the buyer approved.
Measured results (tiktoken, o200k_base, reproducible via measure.py): flagship grocery basket 407 prose tokens → 182 packet tokens (2.24×); across four scenarios 1,056 → 514 tokens (542 saved); 1.62× at 1 item growing to 2.38× at 40 items because the header is paid once.
How we built it
Compact Checkout is built in four layers, all in the public repo:
The dialect. A shared codebook plus a frozen packet format (spec v0): a header sent once (format version, codebook, merchant, currency, and the buyer's spending mandate as a machine-checkable claim), line items as compact positional records, amounts always in integer cents in a verbatim lane — money is never coded, compressed, or a float — and a checksum sealing the packet.
The expander. A deterministic decoder in Python (standard library only), mirrored in JavaScript for the in-browser demo. No model exists downstream of the packet, by design. It validates schema, checksum, and totals, enforces the mandate pinned on the buyer's own device (a packet whose claimed mandate differs from the pinned one is blocked), and renders the approval screen from the packet's structured fields only. Hostile seller text is confined to a length-capped, badged literal lane and rendered inert.
The payment rail. A payments layer (payments.py) with a mock adapter for offline runs and a sandbox adapter for the real PayPal Orders v2 API: OAuth2 client-credentials, order creation with intent CAPTURE, payer approval in the sandbox checkout flow, then capture. It refuses blocked, unconfirmed, or already-captured packets before any PayPal call (replay protection via an idempotency ledger), and the receipt pairs the PayPal transaction ID with the packet checksum.
Live sandbox proof, November 11, 2026: grocery scenario, gate approved, packet checksum 2fd97b92, sandbox order 7TS33941CP075764J, capture COMPLETED, transaction 3PG84047F4385863A, $134.24 — exactly the approved packet total.
- The evidence tooling. A savings dashboard built on AG Grid (Community, vendored) presenting the measured scenario table and basket-size sweep; token counts measured with a real tokenizer (tiktoken, o200k_base) — flagship grocery basket 407 prose tokens to 182 packet tokens (2.24x). Verification: 49/49 tests pass, including a 200-case seeded round-trip battery, decoder and attack fuzz harnesses, and a Python/JavaScript differential corpus with zero disagreements. The AI Output Verifier, included in the repo, is the gate used to check outgoing claims and outputs.
Challenges we ran into
Three real ones:
Honest measurement. Our first token-saving estimates used a characters-divided-by-four shortcut, which materially overstated the saving. We rebuilt the measurement on a real tokenizer (tiktoken, o200k_base) and published the smaller, true numbers — 2.24x on the flagship grocery basket — because a compression claim that only survives a friendly ruler is worthless. The fixed packet header (about 60 tokens) also means small baskets save less; the saving only grows with basket size, and the dashboard shows that curve honestly instead of hiding it.
Security of the packet itself. We red-teamed our own build with a penetration-test pass and found real holes: a packet could originally assert its own spending mandate (letting an inflated packet approve a purchase the buyer never authorized), a JavaScript prototype-chain bypass on merchant and category codes, and our demo checksum (FNV-1a) can be re-sealed by anyone who tampers with a packet and recomputes it. We closed the first two — the mandate is now pinned on the buyer's device and the packet header is only a claim checked against it, and the decoder uses own-property checks throughout (all attack probes blocked, fuzz harnesses pass). The checksum limitation we disclose rather than hide: it is labeled demo-grade in the spec, and production packets take a cryptographic signature (HMAC) in the same slot.
The live PayPal flow. A sandbox capture is not create-then-capture: PayPal requires the payer to approve the order first (ORDER_NOT_APPROVED), and only REST API app credentials authenticate against the sandbox token endpoint — other PayPal app types are rejected as invalid_client. We wired the full flow end to end — gate approval, order creation, payer approval in the sandbox checkout, then capture — and completed a live $134.24 sandbox capture on November 11, 2026 (transaction 3PG84047F4385863A).
Accomplishments that we're proud of
The mechanism works end to end, not as a slide: a compressed payment packet, expanded deterministically on the buyer's device with no model downstream, approved by the buyer from the packet itself, and settled through PayPal — proven with a live sandbox capture (November 11, 2026): $134.24, transaction 3PG84047F4385863A, packet checksum 2fd97b92, capture COMPLETED for exactly the approved total.
Real, reproducible numbers: 2.24x fewer tokens on the flagship basket (407 to 182 tokens, tiktoken o200k_base), 542 tokens saved across the four demo scenarios, and the saving growing to 2.38x at 40 items because the header is paid once. Every figure is reproducible from the repo (measure.py, dashboard_data.py).
Lossless and battle-tested: 49/49 tests pass — a 200-case seeded round-trip battery, decoder and attack fuzz harnesses (111 and 42 cases), and a Python/JavaScript differential corpus with zero disagreements. Blocked packets demonstrably never reach the payment layer, and a tampered packet fails closed with the pay button locked.
We attacked our own build, published the findings in our process, and fixed them: device-pinned mandate enforcement and prototype-chain hardening came out of our own penetration-test pass, and the one limitation we did not close — the demo-grade checksum — is disclosed in plain language with its production replacement (a cryptographic signature in the same slot) named.
A complete, public, runnable system: encoder, decoder, mandate gate, PayPal payments layer, AG Grid savings dashboard, an in-browser demo, and the AI Output Verifier — Apache-2.0 licensed, standard-library-only core, no build step to run the demo.
What we learned
Compression is a trust problem before it is a size problem. Anyone can make output shorter; the hard part is proving the expansion is identical in meaning to what was intended. That is why the design rules fell out the way they did: money in a verbatim lane, a closed vocabulary, no free-form fields, no model downstream of the packet, and a fail-closed pay button. Every one of those rules is a lesson from a specific failure we found in our own earlier drafts.
Measured beats estimated, every time. Our early savings figures were flattering and wrong. Rebuilding the measurement on a real tokenizer cut our headline number — and made it defensible. We also coined a rule we now design by: the rework tax. An omission or shortcut in the dialect is only worth building where the cost of reconstructing the omitted material on the device is zero, or provably negligible against the measured saving.
A policy header is an attack surface. Letting a packet state the buyer's spending mandate felt natural — until our own red-team pass showed an inflated packet could approve itself. Policy belongs on the device, pinned by the buyer; a packet may claim a mandate, but the device decides.
Integration details are the product. PayPal's sandbox taught us the difference between app types that look alike (only REST API app credentials authenticate), and between creating an order and being allowed to capture it (payer approval comes first). None of that is in the pitch deck version of an integration, and all of it decides whether the demo is real.
What's next for Compact Checkout
Ship the production seal: replace the demo FNV-1a checksum with a cryptographic signature (HMAC) in the same slot, with key handling settled, then re-measure with the real tokenizer. That closes the one disclosed limitation.
Add a packet nonce and expiry to the wire header (format v1.1), so legitimate repeat purchases of an identical basket stay possible while true replays stay rejected at both the decoder and the provider.
Widen the dialect: the same device-expansion split applies anywhere model output follows a vocabulary — order confirmations, invoices, status reports, form responses. Payments were the proof because payments are where an expansion changing the meaning is unacceptable, and the mechanism held. Codebook and schema/default omission lanes are designed and waiting; predictive omission stays a named research direction, governed by the rework-tax rule.
Integrate Compact Checkout as the Authorized Payment discipline inside the Real Ninjas Intelligence orchestration suite — Katana (the guide) on the surface, the suite as the hands, the AI Output Verifier as the gate, and PayPal as the money rail only after orientation, work, verification, and the buyer's own confirmation.
Built With
- ag-grid
- css
- html
- javascript
- muse
- paypal-orders-api
- python
- tiktoken
