Changelog

The authoritative, detailed changelog lives in the monorepo CHANGELOG.md. This page summarizes what is shipped and documented here, by phase.

Plug-and-play learning (preview)

• 2026-10-29 — choosing BYOK funding is part of setup. A new workspace starts on prepaid UR credits, which never pay your own provider keys or a provider you run. Choose BYOK funding once with POST /v1/workspaces/{id}/billing/funding (Providers & BYOK). Until then such a request is refused with HTTP 403 permission, which names that route. It used to be a retryable 502 provider_unavailable.
• 2026-10-29 — Get started and copy-to-agent setup. Connect your agent, wire a trusted outcome signal, turn on learning, then watch, pause or roll back, or copy one prompt into Claude Code or Codex. The prompts come from versioned setup recipes, served at /setup-recipes.json. The differences between the two coding agents are on Set up with Claude Code or Codex; the MCP servers and plugins, built from source, on MCP servers for Claude Code and Codex. The evidence status page states what is and is not demonstrated: learning is a preview, and improvement for a given agent is not yet demonstrated.

Phase 10 — the Flywheel (documentation)

• 2026-09-20 — the no-training promise was reversed. Earlier docs carried a blanket no-training promise. That promise has been reversed: ultrarouter may now train and evaluate models exclusively for a workspace, behind a six-conjunct train_allowed gate (never a shared or cross-workspace model; raw items never cross a workspace). The switches and the train_allowed enforcement are built (row TRN0b); what is not built yet is a governed trainer, so no customer-data training run happens until it ships. See How training is governed.
• The broad Flywheel documentation set, agent-first: the five-product overview (Products), the outcome-loop concept (The Flywheel), and the evidence-integrity concept (Holdout and lift) — the standing holdout, the exposure arms, superiority, and why a merged PR is never a lift.
• The Record outcomes guide: the thesis walkthrough in TypeScript, Python and curl across all five recording modes — instant, delayed, batch, warehouse backfill (the ur outcomes CLI) and the durable-queue flush — with the raw-REST path executed against the live stack by the snippet gate.
• The Self-learning agents guide (FLW-71): point an unmodified OpenAI-compatible agent at the gateway with a key that carries a default call type, keep the agent unchanged, and report one outcome per finished episode — the gateway serves the agent its own verified past episodes (most similar first, with the actions that worked) on each step. TypeScript and Python examples over the stock OpenAI SDK read x-ur-request-id from the raw response and post the outcome. It states what is learned and what never is (only reported passes; the holdout untouched; consent-gated; identifiers redacted; per-workspace, never shared — retrieval, not training) and makes no performance claim while the held-out confirmation is still running. The call type's Agent memory panel in the dashboard shows the status, the verified/unverified counts and a small learning trend.
• The Import history guide: usage-only vs intact-trace classes, the capability report, per-record idempotency, and repairable per-row receipts.
• The training-ready export guide: what the export contains, what not_trainable means (a first-class label, never a silent drop), the owner-only consents that gate it, and how any training is governed (per-workspace, behind train_allowed).
• Two laws documented as they are enforced in code: a proposed objective never teaches (a compiler guarantee) and the holdout is sacred (no lever ever reads it). Flywheel learning surfaces remain honestly unavailable / collecting until a live confirmation has run.
• The context runtime guide (DOC-51 / CTX-10..60): the pure lift → compile → render → exit path with real SDK code (TypeScript and Python where parity exists), compatibility profiles, memory classes, the lazy SOP catalog and phase gate, native-delivery adapters and the ONE inline fallback, adopt-in-one-file / leave-in-one-file, and the Flywheel learned slot. The gateway is a witness of ur.manifest, never its author.
• Product-select blocks for agents (DOC-51): five ≤ 300-token "choose when / not when" blocks on For agents — Router, Evals, Scoring, Flywheel and Context — each verifiable through the docs MCP. The AGENTS.md snippet gains the one-line outcome instruction (POST what happened next after an answer is accepted or corrected) and a product-select pointer.

Phase 6 — SDKs & agent-first docs

• TypeScript SDK (@ultrarouter/sdk) and Python SDK (ultrarouter), OpenAI-shaped with the ur.* extensions, contract-tested against the live stack.
• The OpenAPI spec is generated from the gateway's zod route schemas and drift-gated in CI; served at /openapi.{json,yaml}.
• This documentation site (Fumadocs): agent surfaces (llms.txt, llms-full.txt, <url>.md, the docs MCP server), the human IA, and the docs-drift + snippet-exec CI gates.
• A Bench section: the quickstart (capture → freeze → paired run → report → CI gate), the evidence & honesty vocabulary (dataset cards, power plans, dual-interval verdicts, trust classes, evidence bundles), and the CI gate exit-code contract + GitHub Action.

Phase 5 — routing & commitments

• Continuous evals feed model-migration recommendations.
• Canary rollouts with automatic rollback-on-dip, promotion, and a kill switch.
• Commit-aware marginal routing and renewal packs.

Phase 3 — compression

• Deterministic transform tier (whitespace + exact dedupe), property-tested. Superseded by the CMP-60 safety taxonomy: reclassified as semantic_safe, off by default, evidence-qualified — not a semantic-identity guarantee.
• Opt-in adaptive tier with never-touch rules, a verbatim-intent guard, verify-and-retry, a 40 ms budget, and a per-call-type circuit breaker.
• Shadow testing + per-call-type compression reporting.

Phase 2 — dashboard

• The customer control plane: overview, call types, logs explorer with export, providers/BYOK, savings statements, and settings (retention, webhooks, members).

Phase 1 — gateway

• The OpenAI-compatible proxy: chat completions (+ streaming), embeddings, the model catalog, effective-config precedence, the routing engine, hot-path protection (idempotency, spend caps, per-key RPS), BYOK + custom providers, and the remaining /v1 surface.

Phase 0 — foundations

• Tenancy + RLS, auth + RBAC + 2FA, API keys + the versioned config cache, the operational spine (audit, flags, telemetry, rate limits, jobs), and the real-HTTP e2e layer.