Zed Is Open Source and Can Drive Every Frontier Model on Bedrock

#ainative #agents #infrastructure #patterns

TL;DR

Zed is GPL v3 open source — the harness is free. Wired to Bedrock, the only bill is inference.
Native config covers the Claude family (Fable 5, Sonnet 5, Opus 4.8, Sonnet 4.6, Haiku 4.5) with a handful of JSON lines and an AWS profile.
GPT 5.5, GPT 5.4, and Grok 4.3 require a local proxy for two reasons: Bedrock issues short-lived credentials (~50 min) that Zed's static settings cannot auto-rotate; and GPT 5.x additionally needs the Responses API, which Zed does not speak natively.
A macOS LaunchAgent keeps the proxy alive at login — once set up, it is invisible.

Zed is open source under GPL v3. That matters more now than it did a year ago, because the editor is no longer just a text surface — it is the harness that runs your agentic coding work. A GPL-licensed harness that you can inspect, build from source, and extend is a different proposition than a closed one that gates model access behind its own subscription.

Wired to Amazon Bedrock, Zed becomes something specific: a single open source editor that drives frontier models from Anthropic, OpenAI, and xAI through one model picker. Claude Fable 5, GPT 5.5, Grok 4.3 — all reachable from the same agent panel, billed through the same Bedrock account, with no per-model subscription on the editor side.

That is the point. Here is the working setup.

The Native Bedrock Config

Zed's native Bedrock provider takes an AWS profile and region:

{
  "agent": {
    "default_model": {
      "provider": "amazon-bedrock",
      "model": "claude-sonnet-4-6",
      "effort": "high",
      "enable_thinking": true
    },
    "favorite_models": [
      { "provider": "amazon-bedrock", "model": "us.anthropic.claude-fable-5" },
      { "provider": "amazon-bedrock", "model": "us.anthropic.claude-sonnet-5" },
      { "provider": "amazon-bedrock", "model": "claude-opus-4-8" },
      { "provider": "amazon-bedrock", "model": "claude-sonnet-4-6" },
      { "provider": "amazon-bedrock", "model": "claude-haiku-4-5" }
    ]
  },
  "language_models": {
    "bedrock": {
      "authentication_method": "named_profile",
      "profile": "<your-aws-profile>",
      "region": "us-west-2"
    }
  }
}

Three choices worth explaining:

enable_thinking: true — Zed passes extended thinking parameters when the model supports them. For Claude Sonnet 4.5 and later the effective difference on hard reasoning tasks is measurable. The cost is latency. Leave it on for the default model, add it explicitly to favorites where you want it.

effort: "high" — Controls how much reasoning budget Zed allocates for thinking-capable models. The default is already high for Claude Opus 4.8. Set it explicitly so the config is readable.

Model IDs — Zed's native Bedrock provider uses short-form IDs for models in its internal catalog (claude-sonnet-4-6, claude-opus-4-8, claude-haiku-4-5). For newer models not yet in Zed's catalog, use the Bedrock inference profile ID directly: us.anthropic.claude-fable-5, us.anthropic.claude-sonnet-5. Both formats work in favorite_models.

The Multi-Provider Expansion

Some Bedrock accounts expose a separate OpenAI-compatible endpoint that carries frontier models beyond the standard Bedrock catalog: OpenAI GPT 5.5, GPT 5.4, and xAI Grok 4.3. These are not in the regular list-foundation-models output. They require an endpoint specifically designed for OpenAI-wire-format clients, and the API surface splits further: GPT 5.x uses the Responses API (/openai/v1/responses), while Grok uses Chat Completions (/openai/v1/chat/completions). These are different wire formats.

The proxy is needed for two reasons, not one. The first is credential rotation: Bedrock issues short-lived tokens (roughly 50 minutes) and Zed's openai_compatible provider takes a static API key in settings — it cannot auto-rotate expiring credentials. The proxy regenerates the token transparently on expiry, for all three models. The second reason is specific to GPT 5.5 and 5.4: they require the Responses API (/openai/v1/responses), which Zed does not speak natively. Grok 4.3 actually uses Chat Completions — the same wire format Zed already understands — so for Grok the proxy is purely a credential rotation bridge.

The proxy runs on localhost:4327, presents a single /v1/chat/completions endpoint to Zed, and routes each model ID to the right upstream surface with the right format. It generates short-lived credentials from the AWS profile rather than storing static keys. Grok gets reasoning_effort: "none" added to avoid spending the token budget entirely on internal reasoning before producing output.

{
  "language_models": {
    "openai_compatible": {
      "bedrock_mantle": {
        "api_url": "http://127.0.0.1:4327/v1",
        "available_models": [
          {
            "name": "openai.gpt-5.5",
            "display_name": "OpenAI GPT 5.5 (Bedrock)",
            "max_tokens": 128000,
            "supports_tools": true
          },
          {
            "name": "openai.gpt-5.4",
            "display_name": "OpenAI GPT 5.4 (Bedrock)",
            "max_tokens": 128000,
            "supports_tools": true
          },
          {
            "name": "xai.grok-4.3",
            "display_name": "xAI Grok 4.3 (Bedrock)",
            "max_tokens": 1000000,
            "supports_tools": true
          }
        ]
      }
    }
  }
}

Then add the proxy models to favorites:

{ "provider": "openai_compatible", "model": "openai.gpt-5.5" },
{ "provider": "openai_compatible", "model": "openai.gpt-5.4" },
{ "provider": "openai_compatible", "model": "xai.grok-4.3" }

Tested results: GPT 5.5 and 5.4 respond in under 5 seconds. Grok 4.3 is slower — it is a reasoning model and spends time on internal reasoning even with effort set low. The OSS models (GPT OSS 120B, OSS 20B) also work through the same proxy, but they are less interesting as favorites since Claude Haiku 4.5 is in the same speed tier and available natively.

Keeping The Proxy Alive

A proxy that dies when the terminal closes is not a usable setup. The right pattern on macOS is a LaunchAgent: a plist in ~/Library/LaunchAgents/ that starts the proxy at login and restarts it if it crashes.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.yourname.zed-bedrock-proxy</string>
  <key>ProgramArguments</key>
  <array>
    <string>/path/to/venv/bin/python</string>
    <string>/path/to/proxy.py</string>
  </array>
  <key>EnvironmentVariables</key>
  <dict>
    <key>AWS_PROFILE</key>
    <string>your-bedrock-profile</string>
    <key>AWS_REGION</key>
    <string>us-east-1</string>
  </dict>
  <key>RunAtLoad</key>
  <true/>
  <key>KeepAlive</key>
  <true/>
  <key>StandardOutPath</key>
  <string>/path/to/proxy.log</string>
  <key>StandardErrorPath</key>
  <string>/path/to/proxy.err.log</string>
</dict>
</plist>

Load it with launchctl load ~/Library/LaunchAgents/<label>.plist. Verify with launchctl list | grep <label> — a non-zero PID in the first column means it is running.

The Zed settings then point api_url at http://127.0.0.1:4327/v1 and the proxy is just infrastructure that stays out of the way.

What This Architecture Does Not Solve

Internal model routing. Some coding agents use a fast cheap model for classification and a premium model for the visible reasoning path. Zed's native agent uses whichever model you select in the picker for the session. The proxy does not change that. If you want tiered routing, it needs to be built into the proxy or handled by an external agent through ACP.

Automatic model selection. There is no logic in this setup that chooses the right model for the task. That is a deliberate choice — the picker forces explicit selection and the favorites list keeps the set small. A picker full of models becomes a decision you make on every session. Curate the favorites to three to five models maximum.

Streaming. The proxy currently buffers the full response and returns it as a single chunk. Zed handles this gracefully, but you lose the token-by-token streaming that native models provide. For fast models (GPT 5.5, Claude) this is barely noticeable. For slower reasoning models like Grok, it means the interface shows nothing until the full response lands.

The Three-Layer Model

The setup becomes legible when you keep the three layers separate:

Layer	What It Is	Who Owns It
Model plane	Bedrock: account access, region, billing, model availability	AWS + your account configuration
Editor plane	Zed: harness, tools, file context, model picker, thread surface	Zed Industries
Adapter layer	Local proxy: API format translation, credential rotation, model routing	You

The adapter layer exists because of two concrete gaps: Bedrock issues short-lived credentials that Zed's static config cannot rotate, and GPT 5.x requires the Responses API while Zed speaks Chat Completions. The proxy bridges both.

So What

One editor, eight frontier models, no separate model subscriptions, credentials from the profile already configured for everything else. The cost is Bedrock inference pricing, which is the same whether you reach the model through a UI or through Zed.

The open thread: the model is available. Whether Zed's harness gets the best out of GPT 5.5 or Grok — tool behavior, context management, multi-turn coherence — is not something I have measured yet. Having the model in the picker is not the same as knowing the harness is well-matched to it.