Point Claude Code at Any Model: One Base URL

Claude Code is most useful when the feedback loop is short: give it a repository task, let it inspect and edit under your controls, then run the tests. The model choice is part of that loop. You may want a long-context coding route for a large codebase, an agentic coding route for a multi-step change, or a different route for a lower-risk maintenance task.

The safe way to experiment is to change configuration, verify a small request, and then run the same repository task with a fixed budget. This is a configuration guide, not a claim that different models produce the same results. Model behavior, context support, tool use, and cost differ by route. Keep your normal code-review and test process in place.

The two compatible endpoint shapes to keep straight

There are two related but distinct settings in this guide.

For an OpenAI-compatible SDK or a direct chat-completions test, use the versioned URL:

https://api.glideflowai.com/v1

Claude Code itself uses an Anthropic-compatible connection configuration. For ANTHROPIC_BASE_URL, use the host without /v1:

https://api.glideflowai.com

This distinction matters. Appending /v1 to ANTHROPIC_BASE_URL is a common configuration error. The model selection is still explicit through ANTHROPIC_MODEL. Copy an exact ID from the model catalog rather than relying on a display name.

Before you change anything

Have these four things ready:

• A local Claude Code installation.
• A GlideflowAI API key created in the dashboard.
• A small non-sensitive repository or a disposable branch for the first agent run.
• A model ID from the catalog. This article starts with glm-5.2 because it is listed for long-context coding; it is a starting point, not a universal recommendation.

Keep the key in your shell environment or local settings file. Do not commit it, paste it into a browser bundle, or include it in screenshots. If you use a secret manager, point your shell configuration at the injected value rather than copying the key into a repository-specific file.

Fastest path: configure one shell session

Use these exports for a one-session test:

export ANTHROPIC_BASE_URL="https://api.glideflowai.com"
export ANTHROPIC_AUTH_TOKEN="sk-your-key"
export ANTHROPIC_MODEL="glm-5.2"

claude

Inside Claude Code, begin with something observable and low-risk, such as “inspect the repository and list the test commands; do not edit files.” Confirm the model name in the session information if your version exposes it, then ask the tool to make a small change on a branch and run the relevant test.

This is intentionally a narrow validation. It tells you that the credential, endpoint, and selected model can establish a session. It does not prove that a route is suitable for every project or that it will always complete an agent loop.

Persist the configuration locally

If the session test works, you can persist the same values in Claude Code’s settings file:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.glideflowai.com",
    "ANTHROPIC_AUTH_TOKEN": "sk-your-key",
    "ANTHROPIC_MODEL": "glm-5.2"
  }
}

Save this as ~/.claude/settings.json if that is the settings location used by your installation. Merge the env object with existing settings rather than overwriting unrelated configuration. If your team manages environment variables centrally, prefer that mechanism; it keeps credentials out of dotfiles that could be copied between machines.

To change routes later, change only the model value and repeat the same validation task:

export ANTHROPIC_MODEL="kimi-k2.7-code"
claude

Model IDs are case- and punctuation-sensitive. For the current menu, use the catalog, not a model name from an old terminal history or social post.

Select models by the task, then test them

It is tempting to call one model “the coding model” and leave the configuration there. Coding agents make that fragile: a task that involves repository-wide reading is different from a constrained refactor or a sequence of tool calls.

Start by assigning a hypothesis to each route. glm-5.2 is described in the catalog as a long-context coding model for coding agents, tool use, and large-document workflows. kimi-k2.7-code is described as coding-focused for agentic programming and repository-level edits. Qwen3.7 routes can be evaluated for planning, multimodal automation, or lower-cost experimentation according to their catalog descriptions and your own test results.

Then give every route the same task:

1. Check out a clean branch with a known failing test or a small requested change.
2. Give Claude Code the same prompt, file scope, and tool permissions.
3. Set the same maximum number of turns or time budget, if your workflow supports it.
4. Record whether the tests passed, how many retries occurred, and what you had to fix manually.
5. Record input and output token usage separately.

The final item matters because agent runs can be output-heavy. Public menu prices are listed per million tokens; calculate input and output separately rather than relying on a single blended figure. At the current configured menu rates, the routes below are displayed as USD per 1M input / output tokens.

Those rows are transparent menu data, not a performance score. Check the catalog for current values before using them in a budget model.

Verify the same key outside Claude Code

When a configuration fails, separate the client problem from the API problem. The direct OpenAI-compatible endpoint uses /v1; test it with a small curl request before changing several settings at once.

curl https://api.glideflowai.com/v1/chat/completions \
  -H "Authorization: Bearer sk-your-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model":"glm-5.2",
    "messages":[{"role":"user","content":"Say OK."}],
    "max_tokens":512
  }'

Use at least 512 output tokens for a first test with a reasoning-oriented model. Very small limits can be consumed before visible text is emitted, which makes a valid request look like an empty answer.

The matching Python check uses the OpenAI SDK shape:

from openai import OpenAI

client = OpenAI(
    api_key="sk-your-key",
    base_url="https://api.glideflowai.com/v1",
)

response = client.chat.completions.create(
    model="glm-5.2",
    messages=[{"role": "user", "content": "Say OK."}],
    max_tokens=512,
)
print(response.choices[0].message.content)

And Node.js:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.GLIDEFLOW_API_KEY,
  baseURL: "https://api.glideflowai.com/v1",
});

const response = await client.chat.completions.create({
  model: "glm-5.2",
  messages: [{ role: "user", content: "Say OK." }],
  max_tokens: 512,
});

console.log(response.choices[0].message.content);

The direct check is not a real Claude Code run. It narrows the problem: if curl works but Claude Code does not, re-check the Anthropic-compatible base URL and the environment seen by the claude process.

Switching models without losing the experiment

Changing the model ID is easy; comparing model runs rigorously requires discipline. Create a small log in the repository or your issue tracker with fields for task, commit, model ID, input tokens, output tokens, tool turns, test result, and manual cleanup. Include the prompt. If you change the prompt midway through a run, note that too.

For example, a useful test prompt might be: “In this branch, identify why the named unit test fails. Make the smallest fix. Run only the relevant test. Explain the changed files and stop if the test still fails.” It gives the agent a bounded goal and gives you a repeatable result across routes.

Avoid switching a production repository’s default model after one impressive demo. Use a branch, keep write permissions constrained, review the diff, and retain a known-good configuration. The gateway makes configuration changes relatively small; it does not make model output safe to merge without review.

Troubleshooting checklist

The endpoint is wrong

ANTHROPIC_BASE_URL must be https://api.glideflowai.com with no /v1. The OpenAI SDK and curl examples use https://api.glideflowai.com/v1. These are different settings for different protocol paths.

The model ID is wrong or unavailable to the key

Copy the exact model ID from /models. An HTTP 503 response containing 无可用渠道 means the ID is incorrect or is not enabled for the key; it is not an instruction to keep retrying the same request.

The response has no visible text

Increase the output-token allowance to at least 512 for the first check. A reasoning-oriented route may use a very small limit before returning visible content.

The key is present in one terminal but not another

Run claude from the same shell session where the export was set, or confirm that your launcher inherits the environment. Do not print a full key into logs while debugging.

The agent’s behavior changed after the connection succeeded

That is a model-evaluation question, not necessarily a configuration fault. Reduce the task, capture the prompt and tool output, compare against the same test on another route, and keep the result as evidence rather than extrapolating from one run.

Keep configuration separate from repository policy

Pointing Claude Code at a compatible endpoint changes how the tool reaches a model. It should not silently change the policies around your repository. Keep the same branch protection, code-review expectations, and test requirements that you would use with the default configuration. In particular, do not grant broader filesystem or shell permissions merely because an experiment needs to complete quickly. A narrow first task is valuable precisely because it tests the integration without increasing the blast radius.

For a team project, write down the configuration contract next to the experiment record: the tool version, the endpoint type, the model ID, the environment-variable names, and the date of the test. Do not store the key itself. This gives another developer enough information to reproduce the setup while preserving normal credential handling. It also prevents an ambiguous report such as “Claude Code stopped working after an upgrade,” where nobody knows whether the change was in the client, the model ID, or the inherited shell environment.

If a model route is selected for a recurring task, make the choice explicit in the project instructions rather than relying on one developer’s terminal history. Describe the task class and the validation requirement, for example: “use this route only for documentation edits; run the docs build before proposing a change.” That is more durable than calling any one model a general default.

Diagnose failures one variable at a time

When an agent session does not start, avoid changing the endpoint, key, model ID, and prompt together. First confirm that the shell contains the expected variable names without printing the credential. Then run the direct API connectivity check. Next, verify the Claude Code base URL has no /v1. Finally, copy a known catalog model ID and retry with the small “OK” prompt.

When a session starts but an edit run goes badly, preserve the transcript before trying again. Was the model asked to operate outside the stated file scope? Did a test command fail because of local dependencies? Did the agent stop because the turn or output limit was reached? These are actionable observations. They are more useful than attributing every unsuccessful run to the route itself.

For longer tasks, give the agent checkpoints: inspect first, propose a plan, make the smallest edit, run the named test, and summarize. Checkpoints create natural places to stop an expensive or confused run. They also produce a review trail that makes later comparisons between configurations fairer.

Finally, keep the first successful configuration deliberately boring. Use one documented model ID, one small repository task, and one observable test command. Only after that baseline is repeatable should you try a larger prompt, a different model route, or broader tool permissions. This sequence may feel slower than copying a configuration snippet into a production repository, but it tells you exactly what changed when an agent run succeeds or fails. It also gives reviewers a compact diff, a known command to rerun, and a clear boundary for deciding whether the configuration is appropriate for a wider team workflow.

Next steps

Once your first session is working, browse the current model menu and retain only the two or three routes that your repository tests support. The companion guide, choosing an OpenAI-compatible gateway for coding agents, explains how to account for token usage. For model-specific selection, read GLM-5.2 vs Kimi K2.7 vs Qwen3.7 for coding agents.