How to connect Reality Router to Zed

One provider block in settings.json. Zed's agent panel routes every call through Reality Router — and because it's a separate provider, not an override, your real OpenAI models stay exactly where they were.

Zed is the editor people switch to when they care about latency, so it's a little ironic to watch its agent panel sit there waiting on a flagship model to write a one-line commit message. Reality Router fixes the economics of that without touching the part you came for:

• Per-call model selection. The agent's cheap steps go to cheap models; the hard ones escalate.
• Zed calls the router from your machine, so a local router works directly — no tunnel, nothing exposed.
• Your existing OpenAI setup survives. This adds a provider; it doesn't hijack the built-in one.
• Every call is metered in a dashboard you own.

1. Add Reality Router as a provider (1 minute)

Open ~/.config/zed/settings.json and add:

{
  "language_models": {
    "openai_compatible": {
      "reality-router": {
        "api_url": "http://localhost:8000/v1",
        "available_models": [
          {
            "name": "auto",
            "display_name": "Reality Router (auto)",
            "max_tokens": 128000,
            "capabilities": {
              "tools": true,
              "images": false,
              "parallel_tool_calls": false,
              "prompt_cache_key": false
            }
          }
        ]
      }
    }
  },
  "agent": {
    "default_model": { "provider": "reality-router", "model": "auto" }
  }
}

Use openai_compatible, not the built-in openai provider. Older guides (ours included, until now) told you to override language_models.openai. That works, but it replaces your real OpenAI configuration, so your direct OpenAI models stop being available. A named openai_compatible provider sits beside them instead.

capabilities matters: tools: true is what lets the agent panel call tools through the router. Leave parallel_tool_calls off — the router resolves each call before replying, so there's nothing to parallelise.

2. Give it the key

Zed asks for the API key in the provider's settings, or reads it from an environment variable named after the provider id. For reality-router, that's:

REALITY_ROUTER_API_KEY=rr-local zed

Any placeholder works with a local router. Zed's own docs ask that keys stay out of settings.json, which is why it isn't in the block above.

3. Verify it worked (20 seconds)

Open the Agent panel, confirm Reality Router (auto) is the selected model, and ask anything:

what does this project do?

Then open the dashboard at http://localhost:8000/metrics/dashboard. Zed shows up in Agent Activity by name, with its full version string — something like Zed/1.20.2+stable.… (macos; aarch64).

If you want to see routing rather than a single call, give the agent a task instead of a question. In our run, one small request fanned out across three models in three seconds.

Why bother

Zed's whole argument is that the editor shouldn't make you wait. The agent panel is the one place where it does, because a flagship model takes as long as a flagship model takes — including for the calls that never needed one.

• Latency follows the model. Routing a trivial step to a small fast model isn't just cheaper, it's quicker.
• No subscription tier decides your models. Your keys, your pool, your choice per call.
• The bill is visible. Per request, per model, in real time.

Same editor, same agent panel, same keybindings. Just not paying flagship rates for every step.

→ realityrouter.dev

Reality Router is open source and self-hosted. Setup verified with Zed 1.20.2 against a running Reality Router, September 2026.