The loop

Most LLM gateways route traffic and log it. prxy runs a closed loop on every call:

compress  →  prove  →  learn  →  (next call re-enters at compress)

Each step is backed by pipeline modules, signed receipts, and explicit APIs — not vibes.

01 · Compress

Shrink context before the model sees it.

Pre-provider modules trim tool definitions, fold bulky tool results, cache near-identical requests, and inject patterns from past successful calls. The default cloud pipeline:

mcp-optimizer → exact-cache → semantic-cache → structured-crusher → code-crusher → ipc → patterns

Module	What it does
`mcp-optimizer`	Prunes unused MCP tool definitions from the request.
`exact-cache` / `semantic-cache`	Short-circuits repeat or near-match calls before the provider.
`structured-crusher`	Compresses JSON `tool_result` payloads; optional CCR blob archival.
`code-crusher`	Folds long code bodies in tool results.
`ipc`	Inter-prompt compression for long multi-turn sessions.
`patterns`	Injects reviewer-promoted patterns (the learn step feeding back).

Optional stacks

CCR (lossless retrieval) — archive compressed blobs, retrieve on demand:

structured-crusher (ccr:true) → ccr-inject → ccr-retrieve

Web research — browse live pages, compress into tool results:

steel-browser → mcp-optimizer → structured-crusher → code-crusher → ipc → patterns

Set modules per API key via PRXY_PIPE or the lair module picker. See Pipeline execution.

02 · Prove

Every call ships a signed receipt.

The gateway canonicalizes a JSON receipt body (RFC 8785 JCS + Unicode NFC), signs it with Ed25519, and returns three headers:

Payment-Receipt: https://receipts.prxy.monster/r/<receipt_id>
Payment-Receipt-Digest: sha-256=:<base64>:
Payment-Receipt-Kid: prxy-receipt-2026-q2

Receipts record identity, provider attribution, tokens, cost with pricing provenance, cache_status, module_chain, policy decisions, and per-module savings (e.g. structured-crusher.tokens.saved, code-crusher.tokens.saved). Anyone can verify offline against the public JWKS — no prxy code required.

See Receipts and the public ledger at receipts.prxy.monster.

03 · Learn

Compound only from verified outcomes.

A receipt records what happened. An outcome records whether the call solved the problem:

curl https://api.prxy.monster/v1/outcomes \
  -H "Authorization: Bearer $PRXY_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "receipt_id": "<from Payment-Receipt>",
    "outcome": "succeeded",
    "source": "agent_runner",
    "labels": ["auth-fix"]
  }'

Positive outcomes (succeeded, partially_solved, user_satisfied, tool_chain_succeeded) queue memory candidates. A human reviewer in lair promotes useful candidates into the patterns table. The patterns module injects them into future requests — anchored on proof, not self-reported memory.

No auto-promotion today. Every pattern promotion is a reviewer decision. See Memory candidates.

The full chain:

receipts → outcomes → memory_candidates → reviewer → patterns → compress (next call)

See Outcomes.

One env var

Drop prxy in front of your existing SDK:

- ANTHROPIC_BASE_URL=https://api.anthropic.com
+ ANTHROPIC_BASE_URL=https://api.prxy.monster
+ PRXY_KEY=prxy_xxx

Your provider key still runs inference. prxy bills the control layer separately and never marks up BYOK provider tokens.

Try it

Sandbox — five real calls, five signed receipts, no signup.
Quickstart pipeline — configure PRXY_PIPE for your workload.
Web research agent recipe — Steel + crushers stack.