On June 12, 2026, the tensorzero/tensorzero repository on GitHub was archived. The founders wound the project down; the repo is read-only, and there is no maintaining team behind it anymore. If you built on TensorZero, you didn’t pick a bad tool. You picked one of the most technically serious pieces of open-source LLM infrastructure ever shipped, and it stopped being maintained anyway. This post is a practical map for what to do next.
Credit first, because it’s earned. TensorZero gave the industry its best articulation of the inference flywheel: every request produces data, feedback attaches outcomes to that data, and optimization feeds it back into better prompts, better routing, and better models. Inference → feedback → optimization, as one loop with one data model. Plenty of tools logged LLM calls; TensorZero was the one that treated the loop itself as the product, and it proved that developers want a gateway that gets better with use, not just one that forwards requests. Its users aren’t shopping for a vendor right now. They lost a tool they believed in.
What “archived” actually changes
The code is still there, still Apache-2.0, and still runs. What’s gone is everything a production dependency quietly relies on: security patches, issue resolution, provider-API breakage fixes, and a roadmap. Model provider APIs churn monthly, which means an unmaintained gateway doesn’t degrade gracefully, it breaks on someone else’s schedule. You can maintain a private fork, and for teams deeply invested in TensorZero’s experimentation machinery that may genuinely be the right short-term call. For everyone else, the question is what a maintained path forward looks like, and what survives the move.
The migration map
Here is the honest concept-by-concept mapping from TensorZero to Routeplane. “Honest” means the third column includes the things we don’t do.
| If you used | Nearest Routeplane equivalent | The honest difference |
|---|---|---|
| The OpenAI-compatible gateway endpoint | POST /v1/chat/completions, same shape |
A base-URL change. This part is boring, by design. |
| The feedback → optimization flywheel | The savings flywheel: difficulty-aware routing, RTK token compression, caching, LLM-as-judge evaluation | Ours optimizes cost and quality automatically; it is not an experimentation platform. |
| ClickHouse observability store | Durable telemetry plus usage, logs, and FinOps APIs | No ClickHouse-grade analytical store in the open core. You get APIs and rollups, not SQL over every raw inference. |
| Embedded PyO3 in-process mode | None | Routeplane is an HTTP proxy. There is no embedded mode, full stop. |
| Experiments / A-B testing | Prompt cohorts via the x-routeplane-cohort header |
Narrower: cohort tagging and comparison, not adaptive experiment allocation. |
| Self-hosted deployment (gateway + ClickHouse) | Community Edition, Apache-2.0, one container | A docker run one-liner; there is no analytical database to operate. |
Two of those rows deserve more than a table cell, because they’re the ones where TensorZero was genuinely ahead.
The embedded mode. TensorZero could compile into your Python process via PyO3, so a gateway call cost no HTTP hop at all. That was a real innovation, and we don’t replicate it. Routeplane is deliberately a network data plane: residency enforcement, guardrails, and audit only work if they sit at a boundary every client passes through, in every language, and an in-process library trades that boundary away. If sub-millisecond in-process dispatch was the reason you chose TensorZero, we are not a drop-in for that, and you should know it before you migrate rather than after. Our overhead posture is a single-digit-millisecond design target for the proxy hop, and we don’t publish benchmark victories we haven’t published methodology for.
The experimentation depth. TensorZero’s adaptive A/B testing, dynamic in-context learning, and fine-tuning pipelines had no open-source peer, and Routeplane does not claim to match them. What we ship instead is a flywheel with a different center of gravity: the gateway watches your traffic and optimizes cost and quality on its own, rather than giving you an experiment framework to drive. If adaptive experiment allocation is the core of your workflow, the archived codebase or a maintained fork of it may still serve you better, and that’s a fine reason not to switch.
Where the flywheel goes next
What we kept from TensorZero’s thesis is the part we think was permanent: a gateway should compound. Every request through Routeplane feeds a loop with four rungs. Difficulty-aware routing sends easy prompts to cheap models and hard ones to the best, per request and automatically. RTK token compression deterministically strips redundant tool_result blocks before they hit the meter, with a fail-safe guarantee that a request never grows. Exact and semantic caching turn repeat traffic into free traffic. And LLM-as-judge evaluation scores responses, so a low score re-routes to a better model and a high score validates cheap-model eligibility instead of assuming it. Feedback comes in through the API, savings are measured against your real traffic rather than promised, and the loop tightens with use, which is the flywheel property that made TensorZero worth believing in, pointed at your bill instead of your experiments.
What you gain that TensorZero never targeted
Migration isn’t only subtraction. TensorZero was an LLMOps platform; it never aimed at governance, and Routeplane’s other half lives there:
- Sovereign routing. Regulated-data classification on every request, with region-locked provider eligibility enforced per request, not per deployment.
- Guardrails. Deterministic PII and secret redaction in the data plane, on the way in and the way out.
- Agentic security. An MCP gateway that default-denies agent tool calls, with per-(server, tool) authorization and tool-result inspection on the return leg.
- 14 providers behind one surface: OpenAI, Anthropic, Gemini, Azure OpenAI, Bedrock, Mistral, Cohere, Groq, DeepSeek, Together, Fireworks, xAI, OpenRouter, and a generic adapter for Ollama/vLLM/self-hosted models, with fallback chains and circuit breaking across them.
- Developer tooling that shipped this month: Python and TypeScript SDKs, a CLI, and an MCP server so your coding agent can query the gateway directly.
The two-minute start
The Community Edition is open source on GitHub under Apache-2.0, and it starts as one container: docker run -p 8080:8080 ghcr.io/routeplane-core/routeplane:latest with your provider keys in the environment. Point your existing OpenAI client’s base_url at it, send a request with your virtual key, and you’re routed. No ClickHouse, no Postgres, nothing to operate before the first request works. The quickstart covers it end to end, and the self-host guide takes it to production.
TensorZero deserved a longer run. The best way we know to honor what it proved is to make sure the idea outlives the implementation: inference should feed a loop, and a gateway should be worth more on day ninety than on day one. That idea doesn’t belong to any single codebase now. We intend to keep it moving.
See the full Routeplane vs TensorZero comparison, or start with the quickstart.