Where Firstpass fits

The same wire seat, a different number#

Firstpass sits in the same wire seat as the provider — same dialects, same request, byte-identical unless configured otherwise. It changes only which model answers: every call opens on the cheapest rung, its real output is proved against a gate, and only calls that fail escalate one rung. Cheap-and-proven for the easy majority, strong only where earned — the bill drops, the wire contract doesn't move.

Everything in Part A happens whether or not Firstpass exists — it's just how agents and models work. Firstpass sits in the same wire seat: you point your agent's base URL at it instead of the provider, and it speaks the identical dialects (/v1/messages, /v1/chat/completions). Nothing about your request changes. What changes is what happens to each call behind that seat — and it maps one-to-one onto the modules you just read.

Same request in, same dialect out. Firstpass changes only which model actually answers — cheapest-first, proved against a real gate, escalating only on failure. The full mechanism is How it works; the payloads and receipts for every case are in Every scenario, end to end.

One gated call, over time

Here is what happens behind the seat for a single call that turns out to be hard — the cheap rung tries first, fails its gate, and only then does the strong rung get involved. This is the Module-4 loop's inner mechanic, on a time axis:

The cheap attempt (②③) and the gate (④⑦) are the only overhead Firstpass adds; the strong tier (⑤⑥) is paid once, and only because the gate proved it necessary. On the easy majority of calls, the gate passes at step ④ and the strong rung is never touched at all — the call is served cheap and proven, and step ⑧ still leaves a receipt.

On the wire: the request you send, the receipt you get

Concretely, for one call of our /orders task. The request is byte-identical to a provider call — you changed one thing, the base URL:

bash

# the ONLY change: base URL points at Firstpass, not the provider
curl https://firstpass.internal/v1/messages \   # was api.anthropic.com
  -H 'content-type: application/json' -H 'x-api-key: $KEY' \
  -d '{ "model": "claude-sonnet-5", "max_tokens": 1024,
        "tools": [ ... ], "messages": [ ... same body, unchanged ... ] }'

You get back a normal completion — the same shape the provider returns. Separately, Firstpass writes a receipt (a hash-chained Trace) recording what actually happened: the cheap rung was tried, its gate passed, and it served — no escalation, and the savings versus an always-strong baseline:

json

{
  "trace_id": "tr_7b31…", "mode": "enforce",
  "request": { "api": "anthropic.messages",
              "features": { "tool_count": 3, "has_images": false } },
  "attempts": [
    { "rung": 0, "model": "anthropic/claude-haiku-4-5",
      "in_tokens": 5120, "out_tokens": 210, "cost_usd": 0.0062,
      "gates": [{ "name": "pytest", "verdict": "pass" }],
      "verdict": "serve" }
  ],
  "final": {
    "served_rung": 0, "served_from": "anthropic/claude-haiku-4-5",
    "total_cost_usd": 0.0062, "escalations": 0,
    "counterfactual_baseline_usd": 0.0185,   // same call, always on sonnet
    "savings_usd": 0.0123                     // ← proven, not guessed
  },
  "prev_hash": "sha256:9c1a…"
}

Under the hood Every number in that receipt is measured on the real call, not modeled: the tokens are what the provider reported, the pytest verdict is the actual gate result, and savings_usd is this call's cost against an always-strong baseline. The full anatomy — the hash chain, every field — is Receipts & audit. (One honest limit: the baseline prices cached input at the full rate, so on heavily-cached traffic the stated savings can run slightly high.)

Module by module: what Firstpass does, and what it doesn't#

Each fundamental from Part A creates a cost. Here is the honest mapping of what Firstpass does about it — and, where there's a limit, exactly what it is. No over-claims:

Fundamental (Part A)	The cost it creates	What Firstpass does
Model tier (M2)	The strong model costs 15–75× the cheap one, paid even on easy calls.	Opens every call on the cheapest rung and escalates only when a gate proves it necessary. This is the core lever. → simple / complex
Output tokens (M2)	Output is ~5× input; strong-model output is the priciest thing you buy.	Serves the cheap rung's output whenever it passes the gate, so most output tokens are billed at the cheap rate.
Multi-turn (M3)	The whole transcript is re-read every turn; input cost compounds.	Re-proves each turn independently, cheapest-first — so a long session doesn't pin every turn to a strong model. Caps total spend with a per-session budget. It does not summarize history — that stays the client's job.
Tool loops (M4)	One task = many calls, each re-billing transcript + tools.	Routes and proves every call in the loop on its own. Tool presence is a routing/fidelity signal (kept verbatim), not something Firstpass verifies or re-prices.
MCP (M5)	More connected tools = fatter `tools` array on every call.	Forwards the tools array byte-for-byte; it's MCP-agnostic on the data plane. (Firstpass's own `firstpass mcp` is a separate audit surface — it exposes your receipts to an agent, not the routed traffic.)
Prompt cache (M6)	Repeated prefix re-read at full price unless cached.	Forwards your `cache_control` untouched, so provider caching keeps working. Honest limit: its own savings math reads only input/output totals — cache-read tokens are counted at full input price in the counterfactual baseline, a known modeling gap.
Cost is invisible (all)	You rarely see per-call cost until the monthly bill.	Writes a hash-chained receipt per call: cost, the rung served, and the savings vs an always-strong baseline. → Receipts

The same bugfix, end to end#

Tie it together with the tool loop's four-call bugfix. Run vanilla, all four calls hit the strong model — the Part A baseline. Run through Firstpass, each call opens cheap and only the one that fails its pytest gate escalates. Same task, same wire, different number:

vanilla · Part A

Every call → strong model. The safe reflex, applied to all four calls.
No proof. A wrong patch ships unless your own harness catches it later.
≈ $0.063 for the task — the always-strong baseline (illustrative).
Cost is invisible until it aggregates on the bill.

with Firstpass · Part B

Cheapest rung first, each call proved against the real test suite.
Only the failing call escalates one rung — proof of need, not a guess.
≈ $0.0128 served vs the $0.063 baseline — ≈ $0.05 saved on this task (illustrative).
Every call leaves a receipt — cost, rung, gate verdict, savings.

Where the measured numbers live The dollar figures above are illustrative teaching numbers — your savings depend entirely on your models and workload. What is measured: on a live run of 974 real coding tasks scored by their unit tests, 82% of cheap-rung outputs cleared the serve gate at a 7.7% served-failure rate, under the 10% target at 95% confidence. The full run is in Benchmarks; the guarantee behind it is The guarantee.

Where Firstpass fits

The same wire seat, a different number#

Module by module: what Firstpass does, and what it doesn't#

The same bugfix, end to end#

Where to go next#

How it works →

Every scenario, end to end →

Quickstart →