DEV Community: xiaohan lin (Ethan lin)

"How to Use OpenAI Codex with Any Model: Claude Opus 4.8, Grok 4.5, Kimi K3, GLM-5.2"

xiaohan lin (Ethan lin) — Wed, 22 Jul 2026 08:37:10 +0000

canonical_url: https://glideflowai.com/blog/use-any-model-in-openai-codex-opencodex

Most coding agents ask you to pick one model and live with it. That made sense when one model was clearly ahead. It does not describe how people actually work now: a long repository investigation, a five-line typo fix, and a design discussion are three different jobs, and the model that is best at one of them is rarely the cheapest or fastest at the others.

The setup below lets you choose the model per task, inside Codex, without changing your key or your workflow. You run OpenCodex locally and add Glideflow as a custom OpenAI-compatible provider. OpenCodex receives Codex's Responses API traffic on your machine, translates it to Chat Completions, and sends it to the route you selected. Switching models becomes one flag or one dropdown, so the choice costs you seconds instead of a reinstall.

One key then reaches Claude Opus 4.8, Claude Sonnet 5, Grok 4.5, Kimi K3, Kimi K2.7 Code, Qwen3.7-Max, and GLM-5.2, among others. kimi-k3 is used as the first example below only because it is a convenient starting point, not because it is the answer for every task.

This is a BYOK setup: you use an API key from your own Glideflow account and pay for the requests made with that key. OpenCodex, Codex, and Glideflow are independent products. Treat the proxy as a local developer tool, keep normal code review in place, and follow the terms and policies that apply to each product.

One thing to read before you install rather than after: uninstalling is not a single clean command, and two kinds of leftovers can make a working Codex look broken. They are both fixable, and they are documented in the "Return Codex to its original state" section below.

What OpenCodex changes—and what it does not

Codex normally speaks the OpenAI Responses API. Glideflow exposes an OpenAI-compatible API, including Chat Completions and model listing endpoints. OpenCodex is the bridge between those two shapes: its openai-chat adapter sends requests to {baseUrl}/chat/completions and translates streaming text, tool calls, and usage back into the format Codex expects. See the project's adapter reference for the precise translation boundary.

That makes OpenCodex useful when a coding workflow needs model choice rather than a single fixed default. It does not mean that every route has identical context behavior, tool reliability, reasoning controls, latency, or output quality. Use the same task, branch, tests, and budget for each comparison; then keep the routes that work on your repository.

The useful mental model is:

Codex CLI or App → OpenCodex on your computer → Glideflow API → selected model

Your Glideflow key stays on your computer in the OpenCodex configuration or, preferably, in an environment variable. It is not an access token for ChatGPT or a way to bypass account quotas, subscriptions, or authentication requirements.

Before you start

You need:

Node.js 18 or newer. OpenCodex bundles its Bun runtime during installation; you do not need a separate Bun installation. OpenCodex installation notes
A working Codex CLI or Codex app installation.
A Glideflow account and an API key from the dashboard.
A small, non-sensitive repository or a clean branch for the first run.

Create a separate Glideflow key for this experiment if your account supports multiple keys. It makes revocation and spend review simpler. Do not put a live key in a repository, config.json shared with a team, a screenshot, or a support post.

For the examples below, export the key in the shell that will start OpenCodex:

export GLIDEFLOW_API_KEY="sk-your-key"

The shell will retain the value only for that session. Use your operating system's secret store or approved environment-management approach if you need a persistent setup.

Install OpenCodex, then preserve the native Codex route

Install the current package with a user-owned Node installation. Avoid sudo unless your Node setup explicitly requires it:

npm install -g @bitkyc08/opencodex

Then check that the command actually landed before you go further:

which ocx

This step is not a formality. The package registers two binaries, ocx and opencodex, and on one of our machines neither symlink was created even though the install reported success — every later command in this guide would have failed with command not found. If which ocx returns nothing:

Confirm your npm global bin directory is on PATH (npm prefix -g, then check that <prefix>/bin is in $PATH).
Reinstall and read the output rather than scrolling past it. The package's postinstall step fetches a Bun runtime, and a failure there can leave a partial install.
If your npm setup blocks install scripts, that postinstall step is what is being blocked. Re-run the install with scripts permitted for this package, using whatever mechanism your package manager provides. Do not paste a flag from another package manager; npm and pnpm do not share the same option names here.

Do not work around a broken install by editing Codex configuration files by hand. Everything below assumes ocx runs.

For a multi-model Codex setup, start OpenCodex before adding Glideflow. This keeps OpenCodex's built-in OpenAI forwarding provider in place, so your normal Codex model choices remain available alongside the Glideflow routes:

ocx start

On a first run, OpenCodex creates its local state in ~/.opencodex, starts a loopback proxy (normally on port 10100), and points Codex at that local proxy. It also retains a fallback copy of the native Codex configuration.

One point deserves precision, because it is easy to overstate. OpenCodex does not add a second provider beside Codex's own; it repoints Codex's built-in OpenAI provider at the local proxy, and the proxy then routes by model ID — bare IDs forward to the Codex backend, glideflow/<model-id> goes to Glideflow. In a local verification, the native OpenAI models stayed listed in the picker after Glideflow was added, and the new routes appeared separately. We did not run a full native task through the proxy, so treat native forwarding as something to verify on your own machine with one small task before you rely on it.

The consequence of that design is worth stating plainly: while OpenCodex is installed, every request goes through the local proxy, native ones included. There is no automatic fallback to the official endpoint if the proxy stops. That is the trade for getting one picker with every model in it.

OpenCodex's guided ocx init flow is useful for a single-provider setup, but it creates a new provider configuration. For this particular goal—keep native Codex choices and add a second provider—the dashboard or a careful merge is the safer path. Its configuration reference documents every field.

The normal local binding is 127.0.0.1, which is the right choice for a personal development machine. Do not change it to a LAN or public bind merely to make the setup more convenient. A network-exposed proxy can expose access to every provider credential it holds. If you ever have a genuine remote-use case, first read OpenCodex's remote-access authentication requirements.

Add one Glideflow provider, then choose from multiple models

The easiest way to add Glideflow without disturbing the native route is the local dashboard:

ocx gui

Choose Add Provider, select the custom OpenAI-compatible option, then set the provider name to glideflow, the base URL to https://api.glideflowai.com/v1, and a Glideflow API key. Leave the existing OpenAI provider and its default selection unchanged. Then choose a small set of models for the Codex-visible allowlist.

You can also merge a named provider such as glideflow into ~/.opencodex/config.json. One provider holds your endpoint and key; the selectedModels list determines the model routes you can switch between in Codex. The important detail is that the existing openai provider stays in the file. This example starts with a short evaluation set, which keeps the picker readable and avoids treating a large catalog as a promise that every model suits every task.

{
  "port": 10100,
  "providers": {
    "openai": {
      "adapter": "openai-responses",
      "baseUrl": "https://chatgpt.com/backend-api/codex",
      "authMode": "forward",
      "codexAccountMode": "pool"
    },
    "glideflow": {
      "adapter": "openai-chat",
      "baseUrl": "https://api.glideflowai.com/v1",
      "apiKey": "${GLIDEFLOW_API_KEY}",
      "defaultModel": "kimi-k3",
      "selectedModels": [
        "claude-opus-4-8",
        "claude-sonnet-5",
        "grok-4.5",
        "kimi-k3",
        "kimi-k2.7-code",
        "qwen3.7-max",
        "glm-5.2"
      ]
    }
  },
  "defaultProvider": "openai"
}

Four details are important here:

The base URL includes /v1. This is an OpenAI-compatible Chat Completions integration, not the Anthropic-compatible configuration used by a direct Claude Code setup.
apiKey references an environment variable. Do not replace it with a literal production key in a dotfile that may be copied or backed up.
Keeping openai and defaultProvider: "openai" preserves the native Codex path. Glideflow still appears as separately selectable glideflow/<model-id> routes; defaultModel selects a starting Glideflow route only when that provider is chosen.
selectedModels is an allowlist for the Codex picker, not a permanent statement about Glideflow's catalog. Omit it if you intentionally want OpenCodex to discover and display all models available to your key.

OpenCodex fetches a provider's /models catalog by default. If you use an allowlist, update it whenever you intentionally add another model to your evaluation. The provider guide explains the difference between live discovery, models, and selectedModels. Read the provider configuration guide

Start the local proxy, then refresh its model catalog and Codex integration:

ocx start
ocx sync

If OpenCodex reports that the chosen port is busy, let it select a free loopback port or resolve the existing local process before proceeding. Do not solve a local port conflict by exposing the proxy to the network.

What this setup was verified to do

The configuration path above was tested with one Glideflow provider and a six-model allowlist. Every allowlisted model appeared in the proxy's catalog as glideflow/<model-id>, and a short non-streaming request through the proxy completed successfully with Kimi K3 before any repository task was attempted.

Being precise about scope: that verification covered the routing mechanism and one model end to end. The other routes in the allowlist above were not individually driven through the proxy in that session. Run the small connectivity check below against each route you plan to depend on, rather than assuming that one working route certifies the rest.

This check matters because it separates three different problems: whether the Glideflow key and model work, whether OpenCodex can translate the request, and whether the Codex model picker has been refreshed. Do the small connectivity check first; do not debug all three layers at once.

Return Codex to its original state

When you no longer need OpenCodex, stop it:

ocx stop

This stops the local proxy and restores the connection settings it injected into ~/.codex/config.toml. In a local verification, that part worked: the injected loopback base URL was removed, and running ocx restore afterward was harmless and reported that no OpenCodex configuration remained.

Two things it does not clean up. Both are easy to fix once you know they exist, and confusing if you do not, so read this before you install rather than after.

1. The model cache

To make its routes appear in Codex's native picker, OpenCodex overwrites ~/.codex/models_cache.json with its own catalog. Removing the proxy does not restore the original file. The leftover glideflow/* entries are missing a field that Codex's parser requires, and Codex rejects the entire cache rather than skipping the bad entries:

ERROR codex_models_manager::cache: failed to load models cache:
missing field `supports_reasoning_summaries` at line 88 column 5

The visible symptom is an empty or stale model list, which looks like a broken Codex install rather than uninstall residue. The fix:

rm ~/.codex/models_cache.json

Then run Codex once so it refetches the catalog from the official endpoint, and restart the Codex desktop app if you use it — a running app keeps the old list in memory and will not pick up the repaired file on its own.

2. Conversations that ran through the proxy

This one is easier to miss. A model served over the Chat Completions adapter has no native reasoning item to return, so the proxy synthesises one. Those synthesised items carry plaintext in a content array, and the official Responses API requires that array to be empty. While the proxy is running it absorbs the difference. Once it is gone, Codex replays the full thread to the official endpoint, and every turn is rejected:

Invalid 'input[109].content': array too long.
Expected an array with maximum length 0, but got an array with length 1 instead.

The thread is stuck permanently — retrying cannot help, because the bad item is in the stored history. Threads created before you installed the proxy are unaffected.

You can tell a synthesised item from a genuine one: real reasoning items carry a long encrypted_content payload and a provider-issued id, while the synthesised ones have encrypted_content: null, an empty summary, and a short generated id. Session transcripts live in ~/.codex/sessions/<year>/<month>/<day>/rollout-*.jsonl, one JSON object per line. Removing the affected records from the transcripts of those threads restores them; back the files up first.

If none of that appeals, the low-effort alternative is simply to start a fresh thread. The practical rule: while OpenCodex is installed, use it in throwaway threads, and keep conversations you want to keep on native Codex.

Switch models in Codex without changing anything else

With the provider above, OpenCodex addresses a route as provider/model. Start a small Codex CLI task with Kimi K3:

codex -m "glideflow/kimi-k3" \
  "Inspect this repository. List the test command you would run, but do not edit files."

In the Codex app, the routes in selectedModels should appear in the model picker after a successful sync. Select glideflow/kimi-k3, choose a small task, and confirm that the session identifies the model if your client version exposes that information.

Do not make a production repository your first test. A good sequence is:

Ask the model to inspect the repository and name the relevant test command without editing.
Ask it to explain one small, known failing test.
On a clean branch, request the smallest fix and the single relevant test command.
Review the diff and test output yourself.

Once the first route is working, replace only the model part of the command. This is the point of the integration: the endpoint and key stay the same while Codex runs a different model.

codex -m "glideflow/claude-opus-4-8" "Explain the failing test, then propose the smallest fix."
codex -m "glideflow/claude-sonnet-5"  "Explain the failing test, then propose the smallest fix."
codex -m "glideflow/grok-4.5"         "Explain the failing test, then propose the smallest fix."
codex -m "glideflow/kimi-k2.7-code"   "Explain the failing test, then propose the smallest fix."
codex -m "glideflow/qwen3.7-max"      "Explain the failing test, then propose the smallest fix."
codex -m "glideflow/glm-5.2"          "Explain the failing test, then propose the smallest fix."

Changing one variable at a time is much more useful than changing the model, prompt, branch, and permissions together. It lets you learn whether a difference comes from the selected route or from the experiment itself.

Building a per-task routing habit

This is the part that outlasts any particular model. Once switching is cheap, the useful question stops being "which model is best" and becomes "which model is worth its price for this task." Those are different questions, and only the second one has a stable answer.

A rough shape that many teams converge on:

Expensive, careful models for expensive, careful work. A subtle bug in unfamiliar code, an architectural decision, a refactor that touches many files. Here a wrong answer costs you an hour of review, so paying more per token is the cheap option.
Mid-tier models for the bulk of the day. Bounded edits with a named test, small features, mechanical refactors. Most agent work is this, and it is where routing well actually saves money.
Fast, cheap models for volume and throwaway work. Renames, docstrings, test scaffolding, "what does this file do." Latency matters more than depth.
Long-context models when the input is the problem. A large repository sweep or a document-heavy task, where the constraint is how much the model can hold rather than how well it reasons.

The exact available menu changes. Copy IDs from Glideflow's model catalog or from the models OpenCodex discovers for your key. The routes below are hypotheses to test on your repository, not universal rankings — and the point of the table is the left column's shape, not the specific names.

Route	Task class it is a candidate for	What to record
`claude-opus-4-8`	Subtle bug in unfamiliar code, architectural decisions	Whether the diff needed rework, and review time saved
`claude-sonnet-5`	Everyday bounded edits with a focused test	Instruction following and diff scope
`grok-4.5`	Multi-step investigation and tool-heavy loops	Tool-call correctness and retries
`kimi-k3`	One bounded bug investigation or a small feature plan	Test result, tool turns, manual cleanup
`kimi-k2.7-code`	Repository-level edit with a focused test	Instruction following and diff scope
`qwen3.7-max`	Planning and task decomposition	Plan quality and review burden
`glm-5.2`	Larger repository or document-heavy task	Long-context behavior and output budget

Keep a minimal evaluation note for every run: commit SHA, model ID, exact prompt, tool permissions, input and output tokens, wall-clock time, test result, and manual changes required. An agent task can be output-heavy, so token costs should be compared as separate input and output numbers rather than a single blended figure.

Prices and availability change, especially for newly added models. For current USD token rates, use the live model catalog and your dashboard before setting a budget. Do not rely on a copied price table from an old blog post or terminal history.

Verify the API before debugging Codex

If the model picker is empty or a Codex session fails immediately, check the API path before changing several proxy settings. This direct request tests the same key and model against Glideflow's OpenAI-compatible endpoint:

curl https://api.glideflowai.com/v1/chat/completions \
  -H "Authorization: Bearer $GLIDEFLOW_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [{"role": "user", "content": "Reply with OK."}],
    "max_tokens": 512
  }'

Do not paste the expanded command output into a public issue if it could reveal an authorization header, request content, repository details, or key. If the direct request works but Codex does not, inspect the OpenCodex provider name, /v1 base URL, selected model ID, and the environment inherited by the ocx start process.

The same direct check can be made with the official OpenAI SDKs. Python:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["GLIDEFLOW_API_KEY"],
    base_url="https://api.glideflowai.com/v1",
)

response = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "Reply with 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: "kimi-k3",
  messages: [{ role: "user", content: "Reply with OK." }],
  max_tokens: 512,
});

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

These checks validate credentials, endpoint, and one model ID. To test another route, change only the model value—for example, from kimi-k3 to kimi-k2.7-code—and repeat the same check. They do not prove that a model will complete a long agent loop reliably. The real test remains a bounded repository task with a reviewed diff and a passing test.

Troubleshooting the common failure modes

`401` or an invalid-key response

Confirm that GLIDEFLOW_API_KEY is exported in the same environment that starts ocx. Do not use echo $GLIDEFLOW_API_KEY in shared terminal recordings or logs. Instead, re-export the key from your secret source, restart the proxy, and retry the small direct request.

The model is missing from the picker

Run ocx sync, then inspect the exact model ID in the Glideflow catalog. If you configured selectedModels, ensure it includes the exact, case- and punctuation-sensitive ID. Remove a stale allowlist entry rather than guessing a display name.

A route returns an availability error

An availability error can mean the ID is wrong, the model is not enabled for the key's group, or routing is temporarily unavailable. First verify the ID with /v1/models or the catalog, then retry a small request later. Do not silently substitute a different model and record the experiment as if it used the original route.

The response has little or no visible text

Use a reasonable output budget for the first request. Reasoning-oriented models may consume a very small allowance before producing visible text. Start at 512 output tokens for a connectivity check, then size the limit according to the actual task.

A tool loop behaves differently from native Codex

OpenCodex translates protocols; it cannot make every upstream model behave like a native Codex model. Reduce the task to one tool call, capture the sanitized proxy log, and compare it with the same task on another route. Keep normal approval, sandbox, branch, review, and test controls in place.

OpenCodex currently documents a specific multi-agent limitation: on the V2 surface, a native parent that spawns a routed child can lose the child task body because it arrives encrypted. For reliable cross-provider sub-agent experiments, use the V1 surface or avoid that topology until the limitation changes. OpenCodex issue #92

Keep the setup safe and inexpensive

The proxy is a local convenience layer, not a reason to relax engineering controls. A solid default is:

Use one limited-scope Glideflow key for OpenCodex, separate from application production keys.
Keep the proxy on loopback only.
Start with a disposable branch and explicit file scope.
Ask the agent to inspect and plan before allowing edits.
Run one named test, review the patch, and only then expand the task.
Record the model ID and date beside any benchmark result, since model menus and behavior evolve.

Never expose the local OpenCodex dashboard or proxy port to the public internet. Never add a provider key to a shared prompt, a repository instruction file, or a browser-side application. If a key is accidentally exposed, revoke it in the Glideflow dashboard and create a replacement before investigating anything else.

Where to go next

After you have one repeatable run, trim the picker to the three or four routes your own tests support. A short list you understand beats a long one you are guessing at.

The habit worth keeping is smaller than it sounds: before starting a task, spend one second deciding what kind of task it is, and pick accordingly. A bounded edit on a fast route. A repository investigation on a long-context route. A decision you will have to live with on the strongest route you are willing to pay for. Over a week that is a few hundred small choices, and it is where the savings and the quality both come from — not from finding one model that wins everywhere, because that model does not exist for long.

Model rankings will keep churning. A workflow where swapping the model is one flag does not.

For more connection patterns, see the Glideflow quickstart and OpenAI-compatible API examples. To explore exact available IDs and current prices, visit the model catalog. For the local proxy, installation details, and latest compatibility notes, visit the OpenCodex GitHub repository.

If you work in Claude Code rather than Codex, the equivalent setup needs no proxy at all: point Claude Code at any model with one base URL. To decide which routes deserve a place in your picker, read GLM-5.2 vs Kimi K2.7 vs Qwen3.7 for coding agents, and for the cost side, choosing an OpenAI-compatible gateway for coding agents.

Point Claude Code at Any Model: One Base URL

xiaohan lin (Ethan lin) — Wed, 15 Jul 2026 08:02:39 +0000

TL;DR — Run GLM-5.2, Qwen, or Kimi inside Claude Code by changing three environment variables. The easy-to-miss detail: ANTHROPIC_BASE_URL takes the host without /v1. Full setup, verification steps, and troubleshooting below.

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:

Check out a clean branch with a known failing test or a small requested change.
Give Claude Code the same prompt, file scope, and tool permissions.
Set the same maximum number of turns or time budget, if your workflow supports it.
Record whether the tests passed, how many retries occurred, and what you had to fix manually.
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.

Model route	Input	Output	Public reference link
GLM-5.2	$0.90	$2.95	Z.ai pricing
Kimi K2.7 Code	$0.699	$3.00	Alibaba Model Studio pricing
Qwen3.7-Plus	$0.247	$1.20	Alibaba Model Studio pricing

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 the catalog. 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.