Set Up a Custom LLM Provider in Zed for Go and Multi-File Refactoring

Zed can use a custom OpenAI-compatible provider, but the connection has three pieces that are easy to mix up: the base URL lives in settings.json, the API key belongs in your system keychain, and the model name must match the provider’s exact ID. If one of those is wrong, the editor may show the provider while every request still fails.

Here is a complete configuration for GlideflowAI. It follows Zed’s current language_models.openai_compatible settings shape and uses glm-5.2 as a concrete model ID. The same structure works with another compatible service when you replace the URL, provider ID, and model ID.

Add the provider to Zed settings

Open the command palette and run zed: open settings. Switch to the JSON view if the settings editor opens in its graphical form, then merge this object with your existing configuration:

{
  "language_models": {
    "openai_compatible": {
      "glideflow": {
        "api_url": "https://api.glideflowai.com/v1",
        "available_models": [
          {
            "name": "glm-5.2",
            "display_name": "GLM-5.2 via Glideflow",
            "max_tokens": 1000000
          }
        ]
      }
    }
  }
}

Do not replace the whole settings file if it already contains themes, language settings, extensions, or key bindings. Add language_models at the top level and preserve the rest.

The fields have distinct jobs:

The 1000000 value matches the 1M context tag in Glideflow’s current GLM-5.2 catalog entry. Treat it as a capacity to verify, not permission to send an unfiltered repository. If your tested route has a lower limit, lower this setting too. An inflated value can make Zed retain more conversation than the endpoint accepts; a low value can make it compact earlier.

Zed documents this provider shape on its official API-access page. Settings and command names can move between releases, so use that page as the version-specific reference if your installed UI differs.

Store the key outside settings.json

For an OpenAI-compatible provider, Zed derives an environment-style secret name from the provider ID: uppercase the ID and append _API_KEY. Because the configuration uses the ID glideflow, the expected secret is:

GLIDEFLOW_API_KEY

Open Zed’s language-model or agent settings, select the custom provider, and enter the key when prompted. Zed stores provider credentials in the operating system keychain rather than writing them into settings.json.

This separation matters if you share workspace settings. The model ID and API URL are not secrets; the key is. Do not paste sk-your-key into a project file, commit it to Git, or place it in a shell command that will remain in shared history.

If Zed does not prompt for a key, open the agent panel, choose the model selector, find the provider, and use the authentication control exposed by your current release. The exact button label may change. The stable rule is that the secret name must correspond to the provider ID.

You can create a restricted key after choosing a route on /start. Use a disposable repository or branch for the first editor test.

Select and verify the model

Open Zed’s agent panel and select GLM-5.2 via Glideflow. Begin with a request that does not edit anything:

Read the open file and name its package. Do not modify files or run commands.

A successful answer proves that Zed found the model entry, retrieved the key, reached the endpoint, and parsed a chat response. It does not prove tool calling or multi-file editing.

The second test should exercise only one controlled edit:

In the current branch, add a table-driven unit test for ParsePort.
Change only the existing test file. Run the named package test and stop.

Review the diff and terminal output. If the model can answer but cannot use tools, check the capabilities supported by your Zed version and the model route. Zed’s default capabilities for a custom OpenAI-compatible provider are not a promise that every backend implements every agent feature.

You can also separate API connectivity from editor behavior with curl:

export GLIDEFLOW_API_KEY="sk-your-key"

curl https://api.glideflowai.com/v1/chat/completions \
  -H "Authorization: Bearer $GLIDEFLOW_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.2",
    "messages": [
      {"role": "user", "content": "Reply with exactly: connection ok"}
    ],
    "max_tokens": 128
  }'

If this request succeeds but Zed fails, the problem is likely in the local provider ID, stored key, JSON shape, or editor capability settings. If it fails too, inspect the HTTP status and API error before changing Zed. Copy the current model ID from /models; display names are not valid substitutes.

Use Zed’s Go tools before asking the model to guess

Zed has native Go support through Tree-sitter, gopls, and Delve. Those language tools should handle deterministic operations such as symbol resolution, diagnostics, and rename. The model is better used for changes that require intent: splitting responsibilities, changing an interface, updating callers, or drafting tests across packages.

The official Zed Go documentation recommends installing the latest gopls and making sure it is available on your path:

go install golang.org/x/tools/gopls@latest
which gopls
gopls version

For an exact symbol rename, put the cursor on the symbol and use Zed’s rename action (F2 in the default keymap). Zed’s language configuration guide says a multi-file rename opens a preview in a multibuffer. gopls understands references better than a text replacement and lets you review the affected files before saving.

Use the model when the task is semantic. For example:

Refactor package internal/session so persistence is behind a Store interface.
First inspect the package and list affected files.
Do not change exported behavior.
Then make the smallest edit, run gofmt on changed Go files, and run:
go test ./internal/session/...
Stop if the test fails and show the failure.

This prompt gives the agent a boundary, an invariant, and a test. It also asks for inspection before editing, which lets you stop a mistaken plan before it becomes a large patch.

A safe sequence for multi-file refactoring

Large “refactor this project” prompts are difficult to review and expensive to retry. Split the work into checkpoints.

1. Establish the current contract

Ask Zed’s agent to list the public types, callers, tests, and generated files involved. Tell it not to edit. Verify the list with go-to-definition and find-references.

2. State the invariant

Name the behavior that must remain stable: exported method signatures, JSON field names, database schema, error types, or command output. “Clean this up” gives the model no testable finish line.

3. Limit the writable scope

Name the packages or paths the agent may change. Generated files, migrations, and lockfiles should be excluded unless they are part of the task.

4. Require formatting and tests

For Go, ask for gofmt on changed files and the narrowest useful go test command. Run broader tests yourself after the focused package passes.

5. Review the diff in stages

Inspect interface changes before their implementations, then inspect callers and tests. A passing test does not prove that an exported API remained compatible or that an error path still conveys the same information.

This process applies to any model route. Changing the model can change the quality and length of the proposal, but it should not change your repository’s merge rules.

Choose a model by the refactoring job

Do not select a route from the vendor name alone. Give each candidate the same bounded issue and record:

• whether it identified the right files;
• whether the patch compiled and passed the named test;
• number of agent turns and retries;
• input and output tokens;
• manual cleanup time.

A stronger, higher-priced route may be appropriate for architecture changes if it reduces failed turns. A lower-priced route may be enough for repetitive tests or mechanical edits. Those are hypotheses to test, not benchmark claims.

The /pricing page exposes current input and output rates separately. Agent work can be output-heavy, so compare total run cost rather than input price alone. Our GPT, Claude, and Gemini price comparison shows the arithmetic for several workload shapes.

For Zed specifically, confirm that the model route handles the tools and request format used by your installed build. A plain chat response is not enough evidence for a repository-wide agent run.

Troubleshoot the custom provider

The model does not appear

Validate the JSON syntax, then check that language_models, openai_compatible, the provider ID, and available_models are nested exactly as shown. Zed cannot display an entry it cannot parse.

Restart or reload Zed after editing settings if the current release does not refresh the list immediately. Look at Zed’s log for a settings parse error before rewriting the configuration.

Zed asks for a key repeatedly

Confirm the provider ID is glideflow and the stored credential corresponds to GLIDEFLOW_API_KEY. Renaming the provider in JSON changes the derived secret name.

Requests return 404

Use https://api.glideflowai.com/v1 for the OpenAI-compatible api_url. A missing /v1, a duplicated /v1/v1, or a chat path pasted in place of the root can all produce routing errors.

Requests return “model not found”

Copy the exact ID from the public catalog. In this example it is glm-5.2, not GLM 5.2 or the display_name.

Chat works but edits fail

Check agent/tool support in Zed and on the selected route. Reduce the test to one file and one command. Capture the error instead of granting broader shell or filesystem permissions.

Once the read-only prompt and one-file edit both work, open the Zed app page for the connection checklist, create a clean branch, and run one bounded Go refactor with an explicit go test command.