DEV Community: Owen

Check your first coding-client connection before adding another

Owen — Tue, 22 Sep 2026 01:43:25 +0000

A coding assistant can answer successfully while still using an older provider configuration. When you connect several clients, verify one connection at a time so you can tell which settings produced each request.

This is a documentation-based workflow from the Ofox team, using Ofox Desktop as the setup example. It is not a report of a live API test or a guarantee that every client and model combination works.

Prepare one small test

Check the current installer requirements and the documentation for the client you actually use. Keep the CLI and desktop versions of a tool separate when their instructions differ. Note the existing provider settings and locate the configuration backup before applying changes.

Start with an empty test folder. Connect your account in Desktop, select one installed client and a model suitable for it, then apply the configuration. Keep that model unchanged while checking the connection. Changing the client, model and provider together makes a failure harder to isolate.

Match both sides of the request

Open a fresh session in the coding client and ask for a short fixed response, such as OFOX_CONNECTION_CHECK, without reading files or using tools. This is a proposed test, not a captured result.

Record the approximate time and selected model. In the same Ofox account's request history, find the corresponding entry and compare its time, model, status and client-specific key information where available. Check the recorded charge too; a desktop installation is not evidence of free model usage.

A response without an identifiable matching record leaves the connection unverified. A record without a usable response leaves the test incomplete. Check the active client configuration, the dashboard account and the relevant error before submitting more requests.

Keep the scope of success clear

A short text response checks basic connectivity. It does not validate repository access, file edits, tool calling or a complete coding workflow. After the first check, use a small, non-sensitive coding task with an explicit acceptance condition. Review the resulting changes and run the checks relevant to that task.

For each client, keep its version, selected model, test time, matching request and result in a separate record. Only then add the next client. When requesting help, share a redacted error and these identifiers rather than API keys, private prompts or repository content.

The practical benefit of this sequence is a narrower investigation: you can distinguish setup, request routing and task execution instead of treating a successful login as proof that all three worked.

AI assisted the preparation and review of this adaptation. The full Ofox Desktop setup guide provides the installation context and client-specific documentation:

https://ofox.ai/blog/ofox-desktop-multi-tool-setup-guide/?utm_source=devto&utm_medium=organic_social&utm_campaign=desktop_20260922&utm_content=first_request

Codex keeps testing but never finishes: what to change

Owen — Thu, 17 Sep 2026 04:34:29 +0000

If Codex keeps testing without finishing, interrupt the loop, inspect the latest diff and failure, then resume with a specific acceptance criterion. Keep the tests that verify the requested change. Repeatedly running an unchanged command without new evidence is different from fixing a newly discovered defect.

This is a workflow diagnosis, not a claim that one model or every Codex installation has a defect. A slow run can also be waiting on a process, network request, permission or an unusually large test suite.

Find out what is actually repeating

Before changing the model, look at the last command and its result. Did the test fail? Did the agent change relevant code before running it again? Is the process still producing output? Is the same environmental failure being mistaken for a code bug?

Observation	Next check
Same failing test and unchanged code	Ask for the specific new hypothesis before another run
New failure after a real change	Investigate the regression; another test run may be justified
No output from a running command	Inspect process status and external dependencies
Agent keeps widening the test plan	Restate the requested deliverable and scope
Task interrupted by a usage limit	Check the actual limit window before diagnosing the code

Do not discard the working tree to escape a loop. Preserve a checkpoint and inspect changes first. The Codex reset guide covers account limits; a test loop and a weekly quota are separate problems.

Give the task a finish line

An acceptance criterion should describe an observable result. "Make the app robust" invites an open-ended project. "Prevent an empty search from throwing, and verify the empty and nonempty paths" is something a reviewer can assess.

Try this instruction, adapted to your repository:

Fix the empty-search failure in the existing component.
Keep unrelated refactors outside this task.
Before editing, name the smallest relevant acceptance check.
After a meaningful change, run that check and the required project checks.
Repeat a check only after a change or a new failure explains why.
If the same failure persists without a new hypothesis, stop and report it.
Finish with the changed behavior, checks run and any remaining uncertainty.

This is an editorial example, not a measured guarantee of lower usage. Keep repository-required security and regression checks. The goal is to connect validation to a change, not to instruct the agent to skip all tests.

Review the instructions the task inherits

Look for overlapping instructions in the task, project guidance and skills. One instruction may require a bounded fix while another implicitly expands the assignment into a broad audit. Clarify which checks are required for the actual change and which are future work.

If a command is blocked by an environment problem, report that separately from a failing acceptance test. Do not ask the agent to bypass permissions, disable protections or manufacture a passing result to finish sooner.

For an interruption while receiving an answer, consult the stream disconnection guide. Replaying a whole task can duplicate work; inspect the checkpoint and existing files before restarting.

Compare cost per completed task

A large token counter does not by itself tell you whether the task was expensive or productive. Cache reads, uncached input and output can have different API rates, and a ChatGPT subscription limit is not an API invoice. OpenAI's Codex pricing guidance is the reference for plan usage; use your own account's displayed limits.

For API work, the official caching guide explains why input categories must be separated.

OpenAI API documentation, captured September 16, 2026. This table explains API token categories; it is not a Codex subscription quota conversion table.

Record elapsed time, acceptance result, manual repair and any billed retries. If comparing models, begin from the same repository snapshot and give each the same task and permissions. Use the Astra versus Sol comparison for provider-specific cost distinctions. Do not infer which model wins from a single unusually good run.

Frequently Asked Questions

Should I tell Codex never to write tests?

No. Specify the required verification and stop conditions. Removing all tests can hide the very defect you asked the agent to fix.

Will starting a new task reset my weekly allowance?

A new conversation is not a quota reset. Check the account's usage dashboard and preserve the current task's checkpoint before moving work.

Should I switch models immediately?

First identify whether the blocker is a failing command, unclear scope or repeated reasoning without progress. A model comparison is useful only when the task and acceptance check stay comparable.

Originally published on ofox.ai/blog.

Codex stream disconnected before completion: Diagnose the Cause

Owen — Wed, 16 Sep 2026 11:40:27 +0000

stream disconnected before completion tells you that a Codex response did not finish as expected. It does not identify one universal cause. Read the rest of the error, check whether the transport was SSE or WebSocket, and distinguish an explicit quota or context error from a connection that closed before the completion event arrived.

Before retrying, inspect any files the agent changed and any actions its tools performed. A disconnected response does not mean that earlier commands were rolled back. This guide is for Codex users and developers operating compatible Responses endpoints. It is based on official documentation and source inspection on September 14, 2026. We have not reproduced your specific incident.

Classify the suffix, not just the headline

The current Codex SSE parser distinguishes an unfinished stream from more specific recorded errors. Its generic closed-before-completed fallback is not evidence that the user's internet connection was necessarily responsible.

Observation	What it establishes	First investigation
Closed before `response.completed`	Normal completion was not observed	Transport, server and intermediary logs
`response.failed` with a code	Provider reported a specific failure	The actual code and error message
`response.incomplete`	An explicit incomplete event arrived	`incomplete_details.reason`
SSE idle timeout	No SSE event arrived within the configured idle window	Upstream delays and intermediary timeouts
WebSocket closed by server	A WebSocket close was observed	Route support and close details

A readable partial answer is not proof that the response completed. In the streaming documentation, text events and response lifecycle events serve different purposes. response.output_text.done ends a text portion; it should not be treated as a substitute for the overall response completion signal.

Preserve work before repeating the task

Review the current diff, terminal output and any external action that was started. A tool can finish while the final model response fails to reach the interface. For actions with side effects, check the destination or execution record before asking the agent to repeat them.

Do not assume that an automatic retry gives exactly-once execution or that a failed-looking request is free. Those guarantees depend on the operation and provider. When continuing a coding task, describe what has already been verified and what remains uncertain so that the next attempt does not blindly rerun every step.

For a controlled diagnostic, use a new session and a short read-only task. Keep the model and route unchanged at first. If that succeeds while the original session fails, history length, compaction or a tool sequence becomes worth inspecting. It does not by itself prove a particular client bug.

Handle explicit errors on their own terms

The official API error guide separates authentication, access, rate limits and server failures. Check the response body rather than treating every failed stream as a retryable network issue.

A missing model or wrong route belongs in the model-not-found guide. A subscription allowance is different from API billing balance and from a rate limit measured over time. For account-window questions, see the Codex limit guide. Do not solve a named quota error by repeatedly increasing a network timeout.

Likewise, context_length_exceeded points to a different constraint from an idle connection. Reduce or manage the relevant context using supported client features and preserve important task state. A new empty conversation may diagnose the difference, but it is not a substitute for understanding which history the original request contained.

Inspect the actual network path

Record the endpoint hostname, proxy configuration, client version and transport. SSE and WebSocket are separate paths; a proxy that handles ordinary HTTPS requests may still have different connection lifetime or WebSocket behavior. Compare logs from the client, gateway and upstream when you control them.

Use an organization-approved standard network path as a comparison if one is available. Do not disable TLS verification or security controls to make a test pass. A certificate error deserves certificate-chain diagnosis, not an insecure bypass.

Check whether failures happen after a consistent period without events, only on a particular route, or only during tool-heavy turns. Those patterns suggest what to test next. They are not sufficient evidence to blame the model provider, the proxy or the client without additional observations.

Understand idle timeout and retry settings

The current Codex configuration reference distinguishes custom-provider stream_idle_timeout_ms, stream_max_retries and request_max_retries. The documented defaults are 300,000 milliseconds, five stream retries and four request retries respectively. These defaults describe the documented settings as of the review date. The stream settings are documented for SSE; do not assume they control every WebSocket failure.

An idle timeout measures inactivity in the relevant stream, not the maximum duration of the entire task. Raising it cannot prevent a server or intermediary from closing a connection for another reason. Change it only when the evidence points to that timeout and your upstream supports the longer wait.

Use the existing config.toml guide to locate the effective configuration. A setting in an unused profile will not change the running session. Avoid copying an unverified switch that claims to disable WebSocket support across every Codex version.

Build a useful incident record

Keep the start and failure times, operating system, client version, transport, endpoint hostname, full error suffix and request or response ID. Add whether a fresh session succeeds, whether tools had already executed, and the shortest harmless task that reproduces the issue.

Remove secrets, cookies, authentication files and private repository contents before sharing logs. Historical issues can provide comparison cases, but check their dates and status. For example, Codex issue 4302 is a closed historical report; it is not evidence that the same old defect remains unfixed today.

Frequently asked questions

Does this error always mean my network failed?

No. The prefix covers an unfinished response path. The full suffix, lifecycle event and provider error are needed to separate connection failures from explicit request failures.

Can I safely ask Codex to repeat everything?

Check what already happened first. File changes and external tool actions may have completed before the stream failed, and repeating them can duplicate work or side effects.

Should I keep increasing the timeout?

Only if the relevant idle timeout is the observed cause. A larger client timeout does not repair invalid credentials, unavailable models, exhausted allowances or upstream connection policies.

What does stream disconnected before completion mean?

A Codex response failed to finish as expected. The full error distinguishes an explicit failure from a connection that closed early.

Is response.output_text.done enough to confirm completion?

No. It ends a text portion, not necessarily the complete response lifecycle.

Does a failed stream undo executed tools?

No rollback should be assumed. Inspect the operation state before retrying.

Originally published on ofox.ai/blog.

Claude 400: Fix tool_use Without a Matching tool_result

Owen — Tue, 15 Sep 2026 04:33:49 +0000

A Claude error stating that tool_use has no matching tool_result typically indicates a structural conversation problem rather than a prompt issue. In the native Messages API, the assistant calls a client tool and the following user message should return the result with the matching ID. Verify this relationship before retrying.

This guide addresses this specific error category in custom integrations and clients such as OpenCode. Not every OpenCode HTTP 400 error stems from this cause. The guidelines follow Claude's tool-call handling documentation, verified September 14, 2026. Examples presented are synthetic message fragments, not traces from live API testing.

Find the unmatched ID first

Locate the referenced tool-use ID in the previous assistant message by reading the complete error message. Then inspect the following user message. Its tool_result.tool_use_id must reference that exact ID; the tool name cannot substitute for the identifier.

In the native Claude protocol, a tool result is a content block within a user message. There is no native role: "tool" in this message structure. If your adapter supports another provider's format, translate roles and fields rather than forwarding them unchanged.

Check	Valid relationship	Common failure
Identifier	`tool_use.id` equals `tool_result.tool_use_id`	New or truncated ID
Message order	Assistant call followed by user results	Another message inserted between them
Multiple calls	Every client call gets its result	Only the first result is retained
User content order	Tool-result blocks before ordinary text	A text block precedes the results

A minimal valid message fragment

This JSON shows only the relevant messages. A full request also requires the selected model, tool definition, token limit and remaining conversation. The demonstration result is invented for the example and must not replace executing a real tool.

[
  {
    "role": "assistant",
    "content": [
      {"type": "tool_use", "id": "toolu_demo", "name": "lookup", "input": {"key": "demo"}}
    ]
  },
  {
    "role": "user",
    "content": [
      {"type": "tool_result", "tool_use_id": "toolu_demo", "content": "demo result"}
    ]
  }
]

Do not recreate the assistant message from text displayed in a chat window. Save the complete structured content returned by the API. Other blocks may need to remain in the conversation, including thinking data when the model and workflow require it. Signature validation is a separate issue covered in the Claude thinking-signature guide.

Parallel calls must return a complete set of results

When one assistant message requests two client tools, collect both results and include them in the immediately following user message. Do not send one result, insert another assistant turn, then attempt to return the second result to the original call. Place any permitted explanatory user text after the result blocks.

The official troubleshooting guide describes mixed server-tool workflows. If the same round has an unfinished server tool, the user message should contain only the client tool results, and the request should preserve the tools array. Do not generalize a minimal client-only example to every server-tool workflow.

Handle real tool failures without inventing success

A failed lookup or command can still have a correctly paired tool result. Return the same ID with is_error: true and an accurate error description when documented in the client-tool pattern. The protocol relationship and the underlying operation's success are separate checks.

If the client was interrupted, first determine whether the tool actually executed. A timeout in the interface does not prove that a file write, deployment or external request failed. Inspect the operation's state before repeating anything with side effects. Do not manufacture a successful result to satisfy validation, and do not automatically execute a consequential tool twice.

For development, reproduce the sequence with a harmless lookup in a disposable session. A read-only example reveals the pairing failure without risking another write or transaction. Capture the client version and the message immediately before and after the interruption.

Recover a damaged session carefully

Preserve a local copy of the relevant history before attempting repairs. If the original result is available, restore the correctly paired message using the client's supported recovery mechanism. If the history cannot be repaired safely, create a new session with a concise summary of verified work and pending actions, while retaining the old session for reference.

Deleting arbitrary tool blocks can change what the model believes happened. Deleting all conversation files is therefore not a default fix. When filing an issue, provide a small redacted sequence with roles, content types and matching IDs. Remove API keys, private tool arguments and sensitive results.

A client upgrade may be worth checking against its release notes, but this article does not identify one version that fixes every case. Historical issues establish that a failure occurred in a particular configuration; they do not prove the same bug remains in the latest release.

Why retrying alone does not solve it

The API validates the conversation structure before continuing the model turn. Sending the same unmatched sequence again leaves the structural problem unchanged. This conclusion follows from protocol rules, not a measured claim about every client's retry implementation.

An HTTP 429 or overloaded service calls for different investigation. Check the actual status and error body before applying this guide. For other access errors, use the model-not-found diagnostic; it addresses a different protocol and should not be confused with Claude tool-message pairing.

Frequently asked questions

Can a tool return an error and still satisfy the pairing requirement?

Yes. A truthful error result can match the original tool-use ID. Successful execution is not required to represent the failure correctly in the next message.

Should I use role tool with the native Claude API?

No. Native client tool results are user-message content blocks. An OpenAI-compatible adapter may expose another shape, so follow the protocol of the endpoint actually receiving the request.

Is starting a new session a complete fix?

It can isolate damaged history, but it does not repair an adapter that keeps dropping results. Check the serializer or client path that created the broken sequence before relying on the new session.

Why does retrying the same tool_result error fail?

The same unmatched message sequence remains invalid; repair the pairing and order first.

Where does a native Claude tool result go?

In a user content block with tool_use_id matching the preceding assistant tool_use ID.

Can I return a tool execution error?

Yes. Return a truthful error result for the original ID rather than inventing successful output.

Originally published on ofox.ai/blog.

Claude Invalid Signature in Thinking Block: What to Check

Owen — Tue, 15 Sep 2026 02:43:41 +0000

When Claude reports an invalid signature in a thinking block, inspect the structured conversation you sent back. Preserve the original thinking block and its signature rather than reconstructing it from displayed text. If the error explicitly mentions a different conversation, also inspect changes to the preceding system prompt, tools and messages.

These are different failure modes. A signature string can be present and unchanged while a conversation-bound block is no longer valid for an edited prefix. This guide follows the current thinking troubleshooting documentation, checked September 14, 2026. It is a protocol diagnostic, not a claim that all models enforce identical binding rules.

Read the error before changing the history

Keep the full error type and message, request ID, model identifier and client version. Determine whether the first request failed or whether the failure began only after a tool call, a session restore or a history edit. That boundary helps locate the code path that lost or changed state.

Symptom	First inspection
Failure after a tool result	Whether complete assistant content was preserved
Failure after streaming	Whether signature deltas were collected before block completion
Failure after a summary or edited prompt	Whether the error identifies conversation binding
Failure only through an adapter	The serialized request at each protocol boundary

Do not paste private conversation histories or opaque signatures into a public issue. A redacted description of block types and the transformation is usually a better starting point. Retain an unmodified local diagnostic copy if needed to compare your own request paths.

Preserve the complete assistant content

A native thinking block contains a thinking value and an opaque signature. A redacted_thinking block uses data and must not be treated as ordinary visible prose. Empty visible thinking text alone does not establish that the block is corrupt.

The official thinking tool-workflow guide explains how these blocks participate in continued tool turns. Preserve their original values and order together with the rest of the assistant response. Do not summarize a thinking block, replace the signature, or rebuild the message from the UI's text-only transcript.

The following Python fragment illustrates preservation after a response has already been obtained. It is not a complete request or a live API test. Adapt the serialization step to your installed SDK, keeping the full returned content instead of just text fields.

assistant_content = [block.model_dump(exclude_none=True) for block in response.content]
messages.append({"role": "assistant", "content": assistant_content})
# Append the real tool_result message next, following the native tool protocol.

Do not insert a made-up signature into sample requests. A string that looks plausible is not evidence of a valid provider-issued block. If the original content is lost, diagnose why it was lost instead of attempting to manufacture the missing state.

Streaming requires more than text deltas

A streaming integration must assemble the supported content-block events. The Messages API reference documents signature_delta, which arrives before the corresponding content_block_stop. A collector that saves only text_delta or visible thinking text will not preserve the same structured response as a full SDK response object.

Check whether an early disconnect, cancellation or UI redraw caused the client to mark a partially assembled block as complete. Keep the block index and event order when debugging. Do not forward an unfinished block merely because the screen contains a readable partial answer.

Using the official SDK's supported stream handling can reduce custom assembly work, but it does not protect history that your own application subsequently flattens or filters. Compare the in-memory response with the next serialized request. The transformation between those two objects is often the most useful place to inspect.

Conversation binding is a separate check

The current documentation describes conversation-bound signatures for Claude Fable 5.1, enforced for accounts created on or after August 31, 2026, and requests that set the documented binding control. This is a model-specific rule. For an error that specifically identifies a different conversation, changes before the thinking block can matter even when the block itself is untouched. Examples include changing the system instructions, changing tools, or rewriting earlier messages.

Use append-only history when following that workflow, or the documented server-side compaction and context-editing mechanisms. Do not apply a blanket local history rewrite and assume that preserved signatures will make it valid. Model-specific recovery controls also exist in the official documentation, but they are not generic settings to paste into every Claude request.

This article deliberately does not recommend enabling a special recovery beta as the first step. First verify that the selected model and exact error match its documented scope. A recovery option that drops a block can alter retained state, so it should be evaluated as a deliberate application choice.

Do not assume every cross-model change is invalid

The current troubleshooting page explains that blocks unreadable by another model may be dropped rather than necessarily causing the conversation-binding error. Therefore, "switching models always breaks thinking signatures" is too broad. The same caution applies to claims that all cross-provider routes are inherently incompatible.

Record the source model, target route and exact error, then consult the relevant compatibility documentation. If your client converts between native Claude messages and another API format, verify that it preserves the required metadata instead of guessing a universal field mapping.

Tool-result pairing is another independent validation layer. If the message names an unmatched tool ID, follow the missing tool_result guide rather than changing signatures. Gemini has its own thought-signature fields; they are not interchangeable with Claude's native signature field.

Frequently asked questions

Can I fix the signature by editing its value?

No. Treat it as opaque provider-issued state. Restore the original complete block if available, and investigate any transformation that changed or discarded it.

Why does the second request fail when the first worked?

The continuation may have lost structured thinking data or altered a conversation-bound prefix. Compare the full first response with the actual follow-up request instead of only the visible transcript.

Does a new session prove the bug is fixed?

No. A new session can isolate damaged history, but an adapter that strips required fields may break again on the next tool round. Verify the preservation path before closing the issue.

Should I edit a Claude thinking signature?

No. Preserve the original block and opaque signature.

Can an unchanged block fail after editing history?

For documented conversation-bound signatures, a changed prefix can cause a binding error.

Are Claude and Gemini signature fields interchangeable?

No. Each protocol has its own field placement and continuation rules.

Originally published on ofox.ai/blog.

Connect Codex to DeepSeek V4.1 Flash: setup and checks

Owen — Mon, 14 Sep 2026 04:32:00 +0000

To use DeepSeek V4.1 Flash in Codex, select deepseek-flash, configure DeepSeek as a Responses API provider and install its complete model catalog. DeepSeek publishes both a setup script and a manual configuration in its official Codex integration guide.

Checked September 10, 2026. This tutorial describes the direct DeepSeek service; we have not executed paid inference or confirmed a successful Codex coding session. See the release overview for the model announcement and the API setup guide for direct API requests.

Use the official setup with an existing Codex installation

Start with Codex installed and launched at least once. DeepSeek's script expects the ~/.codex directory to exist. Check your installed version with codex --version; the current official catalog declares 0.144.0 as its minimum client version, not as a requirement to install that exact release.

On macOS or Linux, download the official script so you can inspect it before running it:

curl -fsSL https://cdn.deepseek.com/api-docs/codex-deepseek-setup-en.sh \
  -o /tmp/codex-deepseek-setup-en.sh
less /tmp/codex-deepseek-setup-en.sh
bash /tmp/codex-deepseek-setup-en.sh

Choose menu option 1 for deepseek-flash and supply a key from the DeepSeek Platform. The documented script backs up config.toml under ~/.codex/backup-deepseek/, writes the model catalog and adjusts the necessary provider settings. Review its reported changes before starting work. The official guide also provides a PowerShell script for Windows.

If you installed the earlier DeepSeek configuration, rerunning the current script updates its old Flash entries. Option 2 selects V4 Pro, which has a scheduled September 14 migration; choose Flash explicitly for a new V4.1 setup.

Manual setup needs the complete catalog

The catalog is more than a list of model names. It declares context, reasoning levels, input modalities and tool behavior. Open the manual section of the official guide and copy its full models.json content into ~/.codex/models.json. Do not replace it with a small invented JSON snippet.

Then merge the guide's provider configuration into ~/.codex/config.toml, preserving your unrelated settings. These are the important values to verify; this table is not a replacement configuration file:

Field	Documented value
`model`	`deepseek-flash`
`model_provider`	`deepseek`
`model_catalog_json`	`~/.codex/models.json`
`model_reasoning_effort`	`high`
Provider `base_url`	`https://api.deepseek.com/`
Provider `wire_api`	`responses`

The full example also sets API authentication, disables built-in web search and places the key in experimental_bearer_token. Treat that configuration and its backups as credentials; omit them from shared repository commits. A Chat Completions endpoint or a models-only JSON file does not reproduce this documented setup.

Verify the selected model and a real task

Run codex from a small test project. DeepSeek's guide identifies model: deepseek-flash in the CLI startup banner as the configuration check. Inspect any configuration error before sending a task; JSON syntax, catalog location and provider selection are separate failure points.

Then use a bounded coding task with a known outcome: ask for an explanation of one file, followed by a small change and its relevant test. Review the diff and test result. If image input matters, include a representative screenshot. Successful model selection alone does not establish tool or image compatibility in your environment.

Budget that test using the current Flash pricing. For the Anthropic-protocol route, use the separate Claude Code tutorial.

Considering Ofox? First check the model catalog, exact model ID and Responses support. This direct-provider configuration does not establish an Ofox route, price or availability.

Frequently Asked Questions

Which API protocol does Codex use with DeepSeek V4.1 Flash?

DeepSeek's Codex integration uses the Responses API with wire_api set to responses. The official provider base URL is https://api.deepseek.com/ and the model ID is deepseek-flash.

Is changing the Codex model name enough?

No. DeepSeek's documented setup also configures the provider and authentication and installs a complete models.json catalog. Use the official script or the full manual configuration rather than an abbreviated catalog.

Does this guide confirm a successful paid Codex session?

No. It checks the documented configuration as of September 10, 2026. You still need to validate authentication, model selection and a representative coding task in your own environment.

Originally published on ofox.ai/blog.

Use DeepSeek V4.1 Flash in Claude Code: setup guide

Owen — Sun, 13 Sep 2026 11:34:07 +0000

Claude Code can connect to DeepSeek V4.1 Flash through https://api.deepseek.com/anthropic. DeepSeek’s documented setup uses deepseek-flash[1m] for the main, Opus and Sonnet selections, and deepseek-flash for Haiku and subagents. Those distinctions appear in the official Claude Code integration guide.

This guide was checked on September 10, 2026, against the direct DeepSeek documentation. We have not run paid inference or verified a successful Claude Code task. The release overview and API setup guide explain the model and its direct API access.

Configure an existing Claude Code installation

First check that claude --version works. If Claude Code is absent, install it using the current Claude Code installation instructions before applying provider settings. Obtain a DeepSeek API key from the DeepSeek Platform.

For macOS or Linux, use these settings in the terminal from which you will launch Claude Code. Replace the token placeholder locally. Quoting the model names keeps the [1m] suffix from being interpreted as a shell filename pattern:

export ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic"
export ANTHROPIC_AUTH_TOKEN="REPLACE_WITH_DEEPSEEK_API_KEY"
export ANTHROPIC_MODEL="deepseek-flash[1m]"
export ANTHROPIC_DEFAULT_OPUS_MODEL="deepseek-flash[1m]"
export ANTHROPIC_DEFAULT_SONNET_MODEL="deepseek-flash[1m]"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="deepseek-flash"
export CLAUDE_CODE_SUBAGENT_MODEL="deepseek-flash"
export CLAUDE_CODE_EFFORT_LEVEL="max"
export CLAUDE_CODE_AUTO_COMPACT_WINDOW="786432"

These are the values in DeepSeek’s published integration, including the effort and compaction settings. The [1m] form is a client integration setting; the direct API model name remains deepseek-flash. Do not append the suffix to every API request by assumption.

Windows users can use the equivalent $env:NAME="value" assignments listed in the official guide. Keep credentials out of project files and shared terminal transcripts. Start with session-level settings so your existing provider setup remains easy to restore.

Check every model selection, not just the main one

The Opus, Sonnet, Haiku and subagent variables matter because a workflow can select more than its main model. Keeping an old default can leave some requests on a different route.

DeepSeek also documents automatic mappings for incoming Claude model names: claude-opus names map to V4 Pro, while claude-haiku and claude-sonnet names map to Flash. Its guide says the Opus mapping retains Pro billing until September 14, 2026, at 12:00 Beijing time (UTC+8). After that, Pro requests move to Flash and Flash billing. See the Pro migration guide for the scheduled change.

That is why the explicit Flash settings above are preferable when your goal is to evaluate V4.1 Flash now. A familiar Claude label does not prove which DeepSeek model or rate served the request.

Validate a small workflow and its cost

Enter a test project and run claude from the configured terminal. Ask it to explain one file before requesting a bounded edit. Check the resulting diff, tool behavior and test outcome; if your normal workflow delegates work, verify that path too.

Inspect the provider’s usage and billing records for the task. Our example is a setup procedure, not evidence of tested speed, savings or equivalent coding quality. The Flash pricing guide separates input cache hits, misses, output and peak/off-peak pricing.

If authentication fails, check the key and endpoint together. A request-format problem needs the response’s error details; repeatedly changing model names will not repair an incorrect protocol. Codex uses a different setup through the Responses API.

For a gateway such as Ofox, verify its actual model ID, Anthropic support and account price before replacing these direct-provider settings. The Ofox catalog is a place to begin that check; this article does not confirm that V4.1 Flash is available through Ofox or that signing up enables it.

Frequently Asked Questions

What model name should I set in Claude Code for DeepSeek V4.1 Flash?

DeepSeek's official integration sets ANTHROPIC_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL and ANTHROPIC_DEFAULT_SONNET_MODEL to deepseek-flash[1m]. It uses deepseek-flash without the suffix for Haiku and subagents.

Which base URL does the direct DeepSeek integration use?

Set ANTHROPIC_BASE_URL to https://api.deepseek.com/anthropic and authenticate with a DeepSeek API key in ANTHROPIC_AUTH_TOKEN. Do not substitute the Codex Responses configuration.

Does selecting a Claude Opus alias guarantee Flash billing?

No. DeepSeek documents claude-opus names as mapping to V4 Pro, with Pro billing until September 14, 2026, at 12:00 Beijing time. Use the explicit Flash settings and check provider usage records.

Originally published on ofox.ai/blog.

DeepSeek V4.1 Flash API: pricing, providers and setup

Owen — Sun, 13 Sep 2026 04:32:30 +0000

To call DeepSeek V4.1 Flash directly, use deepseek-flash at https://api.deepseek.com. Before buying credit, choose the provider and protocol, estimate the task cost, then configure a key issued by that same provider. This guide follows that full path, from a purchase decision to the first request.

Checked against DeepSeek's official documentation on September 11, 2026. The code is documentation-checked and syntax-checked; it is not a paid end-to-end test. Running the examples can consume credit.

1. Choose where to obtain API access

The official release log confirms direct API access. A third-party entry needs its own verification: DeepSeek's legacy-name routing does not establish a gateway's model mapping.

Destination	What this check establishes	What to confirm before funding
Direct DeepSeek API	Official documentation identifies `deepseek-flash` as V4.1 Flash	Your account access, current rates and required operation
Ofox	The retrieved public catalog showed older DeepSeek entries; this check did not establish a V4.1 serving route	Actual model version and ID, protocol, account price and payment terms
Another gateway	Not certified by this guide	Its own current catalog, protocol documentation and billing terms

The Ofox result is a limit of verification, not proof of unavailability. A provider may update routing independently of display labels; a blog announcement alone does not prove a purchasable route exists. Confirm the operation you need: text chat, Codex Responses, Claude Code tools and image input are separate compatibility checks.

For Ofox, inspect the catalog and authentication documentation. If a confirmed route meets your requirements, create an account and prepare an API key. A gateway account does not fund your direct DeepSeek account.

2. Calculate the cost before buying credit

These are direct DeepSeek USD prices per one million tokens, checked on the official pricing page. They are not an Ofox quote.

Token category	Off-peak USD / 1M tokens	Peak USD / 1M tokens
Input with a cache hit	$0.003	$0.006
Input with a cache miss	$0.15	$0.30
Output	$0.60	$1.20

Peak periods are Monday–Friday, 01:00–04:00 and 06:00–10:00 UTC. Other times are off-peak. These periods are 09:00–12:00 and 14:00–18:00 in Beijing, or 10:00–13:00 and 15:00–19:00 in Tokyo and Seoul. Use timezone-aware conversion where clocks change seasonally. For a request crossing a price boundary, check the actual billing rule instead of inventing a split-charge formula.

A repeated prompt does not prove the whole input was billed as cached. Check the returned usage and billing record. For mixed input, estimate:

Cost = cached_input_tokens / 1_000_000 × cached_input_rate
     + uncached_input_tokens / 1_000_000 × uncached_input_rate
     + billed_output_tokens / 1_000_000 × output_rate

For example, 100 requests with 10,000 uncached input tokens and 2,000 billed output tokens each total 1 million input and 0.2 million output tokens:

Off-peak: (1 × $0.15) + (0.2 × $0.60) = $0.27
Peak:     (1 × $0.30) + (0.2 × $1.20) = $0.54

That budget fits 18 complete 100-request batches into $5 outside peak hours, or 9 at peak rates, excluding provider-specific fees. It does not guarantee 1,800 useful tasks: agents can make multiple calls, retry, accumulate history and consume more output than a final visible answer suggests.

When comparing sellers, replace the official rates with the destination's quote. Check its minimum payment, purchase fees, time bands and refund conditions. Budget one complete representative task before increasing the balance.

3. Match the account, key and model

Obtain a key from the provider you will call. A direct key from the DeepSeek Platform belongs with the DeepSeek endpoint; an Ofox key belongs with the documented Ofox route. Store the direct credential locally as DEEPSEEK_API_KEY; do not commit or print it.

Use the exact model ID. The official deepseek-flash name now selects V4.1 Flash. Older Flash names are compatibility aliases, while an expires-on-0910 beta configuration belongs to an earlier rollout stage. Existing Pro users should also read the migration guidance.

4. Make one small Python or curl request

Following the official quickstart, install the compatible Python client in your project environment with python -m pip install openai, then use:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)
response = client.chat.completions.create(
    model="deepseek-flash",
    messages=[{"role": "user", "content": "Reply with one short greeting."}],
    max_tokens=128,
    extra_body={"thinking": {"type": "disabled"}},
)
print(response.choices[0].message.content)
print(response.usage)

This starts without thinking or tools so the diagnostic task is small. After the basic call works, add required capabilities one at a time and check their documented parameters.

The equivalent curl request is:

curl --fail-with-body https://api.deepseek.com/chat/completions \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{"model":"deepseek-flash","messages":[{"role":"user","content":"Reply with one short greeting."}],"max_tokens":128,"thinking":{"type":"disabled"}}'

Keep a sanitized error body if the call fails. Do not share a verbose trace containing the authorization header. For JavaScript, the OpenAI SDK option is baseURL; the model and JSON fields stay the same. Follow your installed SDK's interface rather than mechanically copying Python argument names.

5. Configure the protocol your client needs

Client or operation	What to check next
Chat Completions	`/chat/completions` with `messages`
Codex	Responses provider settings and the complete model catalog
Claude Code	Anthropic-compatible base path, main-model aliases and subagents
Image understanding	Supported image content blocks and the chosen route's visual input support

Use the dedicated Codex guide or Claude Code guide for client configuration. A text reply alone does not validate a tool loop, image input or streaming parser. Main-model selection also does not establish which model every helper uses.

6. Diagnose the error before adding credit

If a model is missing, check the destination and exact identifier first. A stale client catalog may not list deepseek-flash, and a gateway may use a different ID. Do not assume all providers return the same unknown-model error.

The official error reference distinguishes 401 authentication, 402 insufficient balance, 400 request format, 422 parameters and 429 rate limits. Adding credit addresses an identified balance problem; it does not fix the other categories. Limit retries and pace transient failures deliberately.

After a successful representative task, record the model, provider, time, token usage and billed amount without secrets. Compare the bill with your budget and check the result's usefulness. Increase funding only after the needed operation and its cost have been verified on the actual route.

Frequently Asked Questions

What model ID calls DeepSeek V4.1 Flash?

Use deepseek-flash on the direct DeepSeek API. A gateway can use its own identifier; verify the route before using or funding it.

How much does the official V4.1 Flash API cost?

The September 10 direct API rates per million tokens outside peak hours are $0.003 for cached input, $0.15 for uncached input and $0.60 for output. Peak prices are twice those rates. Gateway prices must be checked separately.

Where can I buy access?

The official DeepSeek API is documented as available. For a gateway, confirm its actual model version, supported protocol, account price and payment terms before funding it. This check has not established an Ofox V4.1 route.

Can I use a DeepSeek key on Ofox?

Use the credential issued by the provider receiving the request. Provider keys and balances are separate; do not combine a DeepSeek key with an Ofox endpoint.

Will adding credit fix an API error?

It can address a confirmed insufficient-balance error, such as 402 on the direct API. It does not fix authentication, malformed requests, an unsupported model or client configuration.

Originally published on ofox.ai/blog.

Codex GPT-5.5 model not found: diagnose the 404

Owen — Sat, 12 Sep 2026 11:34:10 +0000

If Codex reports that gpt-5.5 does not exist or you do not have access to it, check the combination of model ID, provider and authentication before changing your subscription. A valid ChatGPT login does not establish access through an API key, and a valid provider key does not establish that the provider accepts the model ID in your configuration.

This guide is for a Codex CLI session showing an error such as:

unexpected status 404 Not Found: The model `gpt-5.5` does not exist or you do not have access to it.

The wording identifies the requested model, not the cause. It is not evidence that GPT-5.5 was retired. The steps below are based on the official Codex configuration and authentication documentation checked on September 8, 2026; they do not claim that GPT-5.5 is available to every account or provider.

Start with the route, not a reinstall

Run these inspection commands in the same terminal where Codex fails:

codex --version
codex login status
codex --help

Record the version and authentication method. Also record the directory you launched from, any --model, --profile or -c arguments, and whether an IDE launched the session. Do not share API keys, access tokens or the contents of auth.json.

codex login status describes authentication; it is not a complete report of the endpoint selected by a custom provider. Read it alongside the provider configuration.

Your intended connection	What to check first	What not to infer
ChatGPT sign-in	Correct account/workspace and a model offered for that session	A ChatGPT subscription guarantees the same model through the API
OpenAI API key	Intended API account/project, model availability and OpenAI endpoint	A successful ChatGPT session proves this API key has access
Third-party provider	Provider URL, its model ID and the environment variable supplying its key	An OpenAI model ID or OpenAI key automatically works on that provider

OpenAI documents the distinction between ChatGPT subscription access and API-key usage-based access. Keep those routes separate throughout the diagnosis.

Find the setting Codex actually reads

A common troubleshooting mistake is editing the user configuration while the launch command still selects another model. Inspect the relevant configuration files locally and record only the fields you need:

model
model_provider
openai_base_url
model_providers.<provider>.base_url
model_providers.<provider>.env_key
model_providers.<provider>.requires_openai_auth

According to the current configuration basics, precedence runs from highest to lowest:

CLI flags and --config overrides.
Trusted project configuration, with the file closest to the working directory winning.
The profile file selected with --profile.
User configuration at ~/.codex/config.toml.
System configuration, then built-in defaults.

There is an important restriction: current advanced configuration documentation says project configuration ignores provider-related keys such as model_provider, model_providers and openai_base_url, with a startup warning. Keep provider definitions in user-level configuration. A project can still override other allowed settings, including the model, so inspecting only one file can miss a mismatch.

The current docs describe profile files as ~/.codex/profile-name.config.toml. Older tutorials may use a different profile layout. Check your installed version before copying either format.

Repair the connection you intended to use

If you intended ChatGPT sign-in

Confirm the account and workspace, then select a model actually available in that session. Remove an obsolete model override from the launch command or the configuration layer that supplied it. If the model is not offered, check account availability rather than assuming that manually entering gpt-5.5 grants access.

Only reauthenticate when the active account is wrong or authentication has failed. Reinstalling Codex or deleting credentials is not a necessary first step for a model lookup error.

If you intended an OpenAI API key

Confirm that the request uses the intended OpenAI endpoint and API account/project. Compare the requested ID with that account's current model availability. Check openai_base_url for an old proxy override before concluding that OpenAI rejected the request.

API access and billing are separate from included ChatGPT plan credits. If another model works with the same key, that is useful evidence about the route, but it does not prove access to GPT-5.5.

If you intended a third-party provider

Treat the URL, model identifier and key as one matched set. A provider may use a namespaced model ID; use its documented value rather than adding or removing a prefix by guesswork.

This is a configuration template, not a working endpoint or an assertion of GPT-5.5 availability. Replace both placeholders with values from your provider. Put these entries in user-level configuration, merging with existing sections rather than duplicating them:

model = "REPLACE_WITH_PROVIDER_MODEL_ID"
model_provider = "diagnostic_provider"

[model_providers.diagnostic_provider]
name = "My provider"
base_url = "https://api.example.com/v1"
env_key = "PROVIDER_API_KEY"
requires_openai_auth = false
wire_api = "responses"

The selected provider must support the Responses API; the current Codex configuration reference lists responses as the only supported wire_api value. A provider offering only Chat Completions cannot use this template. Set PROVIDER_API_KEY through your usual local secret-management method; do not paste the secret into a shared TOML file.

requires_openai_auth defaults to false; it is explicit here to keep this template on the provider-key route. If an existing provider definition sets it to true, Codex uses OpenAI authentication and ignores env_key. Check this setting when a provider key appears to have no effect.

Before editing, save a copy of the affected configuration. Keep unrelated settings. After editing, start a new session from the same directory and run a small request that does not ask Codex to edit files. API usage may be billed. Restore the saved configuration if the change breaks a previously working route.

For a broader setup walkthrough, see custom model providers in Codex. If you use Ofox, check the current model catalog for the exact ID and supported connection before configuring it.

Use the next response to narrow the cause

Result after the change	Next step
Same model-specific 404	Recheck effective model ID, host and account access; avoid repeated identical retries
HTML 404 or a generic route-not-found response	Check URL/path construction and proxy routing before blaming model permissions
401 authentication error	Check the credential for the selected provider; follow the Codex 401 guide
429 or a usage-limit message	Model lookup is no longer the only issue; inspect the actual quota/rate-limit response
A successful response	Confirm the intended account/provider and request record before resuming the larger job

If you compare a direct API request with Codex, use the same host, key, model and Responses endpoint. A successful Chat Completions request to another host does not isolate a Codex problem. A direct success on the matched route shifts attention toward Codex configuration or request differences; it does not prove which difference caused the error.

A local model metadata ... not found warning is also distinct from an HTTP 404. Capture the final server response rather than assuming those messages have the same cause. For non-Codex SDKs and Azure cases, use the general OpenAI model-not-found guide.

What to include if you still need support

Send a redacted report containing the Codex version, operating system, authentication type, selected model/provider, endpoint host and path, working-directory context, relevant startup warnings and the exact final error. Include the request ID if the provider supplies one. Exclude secrets and private prompts.

That report lets support distinguish account availability from a stale override or provider mismatch. It is a better next step than changing the account, model and endpoint all at once and losing the original evidence.

Sources

Frequently Asked Questions

Does a GPT-5.5 404 mean the model was removed?

No. The error alone does not distinguish an unavailable model from the wrong provider, model ID or account access. Check the request route and that account's current model availability.

Does a ChatGPT subscription pay for API requests?

Codex authentication with an API key uses API billing rather than included ChatGPT plan credits. Check which authentication route your session actually uses.

Should I delete auth.json to fix this?

Start with codex login status and your selected provider. Deleting credentials does not fix a wrong model ID or endpoint and can interrupt a working login.

Originally published on ofox.ai/blog.

Codex Errors: 15 Symptoms Mapped to a Tested Fix (2026)

Owen — Sat, 12 Sep 2026 04:34:14 +0000

TL;DR: Most Codex errors are misfiled. The message names the symptom, not the cause, so people spend an afternoon rotating an API key when the real problem is a Windows Store install path or a missing bubblewrap package. This page is the index: 15 failures we have reproduced, each mapped to the thing that is actually broken and to the page with the tested fix. Start with your version, then find your string.

Last updated 2026-08-31. Version numbers and issue states on this page were read from npm, GitHub and OpenAI’s own docs on that date.

For configuration rather than an error, go directly to config.toml paths and examples or custom providers and profiles. For an API model 404, use the model ID, access and endpoint checks. Match the actual error text before changing credentials or reinstalling.

What should you check before any Codex fix?

Three of the biggest error families in this list are regressions with a known fixed build. If you are on the broken build, the fix is the upgrade and nothing else on this page applies.

codex --version                    # CLI
npm view @openai/codex version     # latest published: 0.151.0

The editor extension carries its own version, and it is the one that matters for the “couldn’t load its resources” family: the break landed in 26.803.41515 and the fix landed in 26.810.41047. AGENTS.md loading in symlinked workspaces was fixed in CLI v0.138. Upgrade first, reproduce second.

Which Codex are you running?

Five surfaces ship under the same name and they fail in different places. Getting this wrong is the most common reason a fix does not work.

Surface	What it is	Where its errors come from
CLI	`@openai/codex`, a Rust binary with an npm wrapper	PATH, `~/.codex/config.toml`, the sandbox, auth
Editor extension	the Codex panel in VS Code and forks	resource loading, the app-server handshake, the native host
Chrome extension	browser control, installed from the ChatGPT desktop app	native host version, permissions, browser support
ChatGPT mobile	Codex inside the phone app	nothing local; it is a remote session
Desktop app	the ChatGPT desktop client that hosts the above	model picker, `model_catalog_json`

If your error mentions resources, a native host, or an app-server, you are in extension territory even if you also use the CLI. If it mentions config.toml, a sandbox, or a provider, you are in CLI territory.

Which Codex error do you have?

Every string below is quoted as it appears. Find yours, then follow the link for the reproduction and the fix.

Why will Codex not install or start?

Error message	What is actually wrong	Fix
`zsh: command not found: codex`	npm installed it somewhere not on your PATH, usually because of NVM, Volta, or a custom `npm prefix -g`	codex: command not found
`failed to start codex app-server (os error 3)`	Windows cannot resolve the path it was handed, most often a Microsoft Store install under `WindowsApps\`	failed to start codex app-server on Windows
`manifest entry is missing required path nodePath/resourcesPath`	the launcher read an install manifest whose recorded paths no longer exist	same page, fix 6
`unable to locate the codex cli binary`	the extension is looking for a CLI that was never installed, or was installed under a different user	failed to start codex app-server on Windows
`Codex could not start the extension. Codex couldn't load its resources.`	the `26.803.41515` regression, which breaks five different ways behind one message	couldn’t load its resources
`codex chrome native host is out of date`	the browser extension and the desktop app are on mismatched builds	couldn’t load its resources

Windows deserves its own note, because a lot of advice still says WSL2 is mandatory. It is not. The project README gives Windows its own one-liner:

Run the following on Windows to install Codex CLI: powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

That installer needs no Node at all. WSL2 is a choice rather than a requirement, but the two paths get different sandboxes. Native versus WSL2 has the trade-off; the install guide has all the routes including the standalone installer that needs no Node at all.

Why can Codex not authenticate?

Error message	What is actually wrong	Fix
`Missing bearer or basic authentication in header`	no key was sent at all, usually an env var that never made it into the shell Codex runs in	Codex CLI 401: 9 tested causes
`Incorrect API key provided`	a key was sent and rejected, which is a different problem with a different fix	Codex CLI 401: 9 tested causes
requests hang and then time out on connect	a PAC or WPAD corporate proxy that Codex does not discover, or a missing CA certificate	Codex behind a corporate proxy

Nine failures return something a user reads as a 401, and only some of them are literally 401. Read the message body, not the status code.

Why has Codex run out of quota?

Error message	What is actually wrong	Fix
`You've hit your usage limit`	a subscription window closed; the reset is a server-side `resetsAt` timestamp, not a clock rule	Codex reset: when your limit clears
`429 Too Many Requests` on a metered key	rate limiting or a spend cap on the API side, which is a separate system from the subscription window	cap your spend with a drop-in API

This is the single biggest source of Codex searches we see, and most of the advice online is wrong about it. There is no fixed number of days to wait, there are exactly two windows, and an earned reset is a credit you can redeem rather than a date you wait for. A 429 on a metered key is not the same event at all: for what the code means per provider, see LLM API error codes.

Why does Codex refuse to run commands or read your files?

Error message	What is actually wrong	Fix
`command failed; retry without sandbox`	on Linux, `bubblewrap` is missing or cannot open the paths it needs; on any OS, `sandbox_mode` is stricter than the task	command failed; retry without sandbox
AGENTS.md is ignored, no error at all	the workspace path traverses a symlink, on CLI builds before v0.138	AGENTS.md not loading in symlinked workspaces

The sandbox one has a trap worth knowing: Codex prints a bubblewrap warning whose match string does not exist on every distribution, so a broken sandbox can fail silently on some Linux installs. The fix page has the five-distribution test.

Why will your model or provider not appear?

Error message	What is actually wrong	Fix
custom models missing from the Codex Desktop picker	the `model_catalog_json` bug; the picker has nothing to describe when the model is set inline	Codex Desktop not showing custom models
an unknown model silently caps at 258K context	Codex falls back to a default context size for models not in its catalog	Qwen 3.8 Max in Codex CLI

Pointing Codex at a provider other than OpenAI is a supported path, not a hack, but there are three places to do it and they behave differently. The config.toml reference is the full surface. The [model_providers] block is how you keep several providers side by side. The custom endpoint guide is the two-variable version if you only want one. One constraint that catches people: Codex only accepts wire_api = "responses" for custom providers, so a chat-completions-only gateway will not work no matter how the rest is configured.

Which changes need evidence first?

Changing API keys. For a rejected key, verify the selected provider, credential and account. For a missing-header error, inspect whether the client actually sends authentication. A 429 needs rate-limit or quota checks, not automatic key rotation.

Reinstalling. For a command-not-found error, inspect PATH and the installed binary before reinstalling. Installation damage and path configuration are different causes; use the logs to distinguish them.

An open GitHub issue. An issue still marked open does not mean the feature is missing. Codex issue #22638 asks for Chromium browser support and is still open, while the docs list five supported browsers and the feature shipped. Check the product, then the tracker.

How do you set Codex up from scratch?

If nothing is broken yet and you are here to configure rather than repair:

Install it, on any of npm, Homebrew, the standalone installer, or a raw binary.
Write a config.toml and understand the three approval modes and three sandbox levels before you loosen either.
Point it at the model you actually want, whether that is an OpenAI model or something else through an OpenAI-compatible gateway.
Learn the loop: AGENTS.md, plan mode, worktrees, and the seven mistakes that waste the first week.

Coming from somewhere else, the Claude Code migration maps all 12 config surfaces and names the one dead end. Choosing rather than migrating, Claude Code vs Codex vs Cursor vs DeepSeek TUI and OpenCode vs Codex CLI are the head-to-heads.

What about the browser, mobile and desktop surfaces?

The Chrome extension now covers Chrome, Edge, Brave, Opera and Vivaldi and installs from the ChatGPT desktop app. Codex on iPhone and Android is a remote session, so nothing about PATH or sandboxes applies there. Goal Mode and remote computer use is the long-running agentic mode and its own safety model.

References

Frequently Asked Questions

Why does Codex fail with a different error on Windows than on macOS?

Operating systems and installation methods use different paths, permissions and process launchers. On Windows, os error 3 points to a path lookup failure; inspect the actual executable path and application logs. Do not assume every Windows failure has the same cause.

What should I check before working through any Codex fix?

Your version. Run codex --version for the CLI and check the extension version in your editor. Several of the most-reported 2026 errors are regressions with a known fixed build: the 'couldn't load its resources' family was introduced in 26.803.41515 and fixed in 26.810.41047, and AGENTS.md in symlinked workspaces was fixed in CLI v0.138. Upgrading is the whole fix in those cases.

Is a Codex 401 always an authentication problem?

No. Nine distinct failures return something that looks like a 401, and they split into three groups that need different fixes: no key was sent at all ('Missing bearer or basic authentication in header'), a key was sent and rejected ('Incorrect API key provided'), and a key that is correct but carries a trailing newline from a shell export. The status code is the same; the message body is what tells them apart.

Does hitting the Codex weekly limit mean I have to wait a fixed number of days?

No. The reset is a server-side resetsAt timestamp attached to your account, not a clock rule you can compute, and there are only two windows (primary and secondary). You can read the actual timestamp rather than guessing, and an earned reset credit can be redeemed early.

Which Codex surface am I actually using?

There are five and they fail differently: the CLI (@openai/codex on npm, currently 0.151.0), the editor extension, the Chrome extension driven by the ChatGPT desktop app, Codex inside the ChatGPT mobile app, and the desktop app itself. An error about resources or a native host is an extension problem; an error about config.toml or a sandbox is a CLI problem.

Originally published on ofox.ai/blog.

Connect Codex CLI and Claude Code to Ofox with CC Switch

Owen — Sat, 12 Sep 2026 01:22:26 +0000

CC Switch sets up Codex CLI and Claude Code against Ofox from one place. The two need different base URLs and API formats — mixing them up is the usual failure.

Two clients, two protocols

Codex CLI and Claude Code speak different protocols. CC Switch keeps both entries side by side, which is the main reason to use it — pasting the Claude Code base URL into the Codex tab, or the reverse, is an easy mistake to make by hand.

Feature	Codex CLI	Claude Code
Protocol	OpenAI-compatible	Anthropic native
Ofox base URL	`https://api.ofox.ai/v1`	`https://api.ofox.ai/anthropic`
API format in CC Switch	OpenAI Compatible	Anthropic Messages (Native)
Auth field	not applicable	`ANTHROPIC_AUTH_TOKEN (Default)`
CC Switch tab	Codex	(provider management page)

Neither URL takes a trailing slash, and one Ofox key authenticates both. Note that this table describes the client, not the model — every Claude model in the Ofox catalog, Fable 5.1 included, accepts either protocol.

Installing CC Switch

# macOS
brew install --cask cc-switch

# Debian / Ubuntu — download the .deb from Releases first
sudo dpkg -i <downloaded-file>.deb

# Fedora / RHEL
sudo rpm -i <downloaded-file>.rpm

# AppImage
chmod +x <downloaded-file>.AppImage && ./<downloaded-file>.AppImage

Windows ships an .msi installer, and macOS has a .dmg on the releases page if you would rather not use Homebrew. For the full install walkthrough, see the CC Switch setup guide. Minimum supported versions are macOS 12, Windows 10, and Ubuntu 22.04 / Debian 11 / Fedora 34.

Adding the Codex CLI provider

Switch to the Codex tab at the top, then use the + button in the top-right corner.

Field	Value
Provider Name	`ofoxai-codex`
Website URL	`https://ofox.ai`
API Key	your Ofox key
Request URL	`https://api.ofox.ai/v1`
API Format	OpenAI Compatible
Write to Global Config	checked

Leaving "Write to Global Config" checked applies the provider across all projects rather than just the current one. Add the provider, then activate it from the list.

Adding the Claude Code provider

Same tool, different page and different values.

Field	Value
Provider Name	`ofoxai-claude`
Website URL	`https://ofox.ai`
API Key	your Ofox key
Request URL	`https://api.ofox.ai/anthropic`
API Format / Auth Field	Anthropic Messages (Native) / `ANTHROPIC_AUTH_TOKEN (Default)`
Model Configuration	leave empty
Write to Global Config	checked

Leave Model Configuration empty. It falls through to the default Claude model, which is what you want unless you are deliberately pinning one. CC Switch writes the result to ~/.claude/settings.json.

There are two optional toggles on this page, "Hide AI Signature" and "Teammates Mode". Neither affects routing or billing.

Turning on usage query

CC Switch can poll Ofox for consumption figures and show them in its dashboard. Four things to set: toggle Enable Usage Query on, paste the same Ofox API key, set the request endpoint to https://api.ofox.ai/v1, and pick the Universal Template (通用模板) option, which the Ofox documentation recommends for best compatibility.

Two things to know:

It does not consume API quota — it uses a dedicated statistics API rather than your call budget.
Figures lag the calls that produced them by a few minutes.

Turning it off later does not disturb normal API calls.

On Fable 5.1 specifically

Fable 5.1 landed in the Ofox catalog on 3 September 2026, as anthropic/claude-fable-5.1. Nothing above changes for it: same two base URLs, same two API formats, same key. The model string is the only difference.

The setup is worth doing regardless of which model you land on: it gives you a working two-protocol path where switching models is a string change. Alongside Fable 5.1, the catalog has anthropic/claude-fable-5, anthropic/claude-opus-5 and anthropic/claude-sonnet-5 at Anthropic list prices with no markup, and all four are reachable over either protocol on the same key.

That matters for Fable 5.1 in particular, because its only price change is the cache read — $1 down to $0.25. Whether that is worth anything to you depends entirely on your cache-hit ratio, and the way to find out is to run your real workload through this setup and read the number off your own usage. The API reference has the rate table and the TTL arithmetic.

When something does not connect

Three common failure modes:

A trailing slash on the request URL. The Ofox documentation calls this out for both providers.
The wrong API format for the tab. Codex CLI with "Anthropic Messages (Native)" selected will not work, and neither will the reverse. Check the format field before the key.
A model string the catalog does not have. Note that the Ofox ID for Fable 5.1 is anthropic/claude-fable-5.1 with a dot, not a hyphen — though the alias anthropic/claude-fable-5-1 also resolves. The live catalog is the authority: GET /v1/models returns exactly what you can call.

CC Switch installation targets, provider field values, base URLs and usage-query behaviour verified against the Ofox integration documentation on 3 September 2026. Catalog contents checked against the live /v1/models endpoint the same day.

Frequently Asked Questions

What is CC Switch?

An open-source provider manager with a visual interface. It writes the config files for Claude Code and Codex CLI, so you do not have to edit JSON or environment variables by hand. For Claude Code it writes ~/.claude/settings.json. It runs on macOS 12+, Windows 10+, and Ubuntu 22.04+ / Debian 11+ / Fedora 34+.

Do Codex CLI and Claude Code use the same Ofox base URL?

No — and this is where setups usually go wrong. Codex CLI is an OpenAI-protocol client and takes https://api.ofox.ai/v1 with the API format set to OpenAI Compatible. Claude Code is an Anthropic-protocol client and takes https://api.ofox.ai/anthropic with the format set to Anthropic Messages (Native). Neither URL takes a trailing slash.

Can I run Claude Fable 5.1 through this setup?

Yes, as of 3 September 2026. Fable 5.1 is in the Ofox catalog as anthropic/claude-fable-5.1. Nothing in the setup changes for it — same base URLs, same API formats, same key. Only the model string differs.

Does CC Switch's usage query burn API quota?

No. Per the Ofox integration documentation it uses a dedicated statistics API and does not count against your API call limits. Usage figures typically appear within a few minutes of the calls that produced them.

Can I keep more than one Ofox account in CC Switch?

Yes. You can add multiple Ofox provider entries with different API keys and switch between them from the list.

Originally published on ofox.ai/blog.

ChatGPT DeviceCheck Registration Failed (403, 500, 503): Real Fixes

Owen — Mon, 07 Sep 2026 04:34:54 +0000

ChatGPT DeviceCheck Registration Failed (403, 500, 503): Real Fixes

DeviceCheck errors block ChatGPT login before your password is ever checked, and the official advice about date and time fixes almost none of them. The error means your device could not produce an attestation token proving it is genuine hardware. That is a conversation between your device and Apple or Google — OpenAI is only the party that gets told "no".

Which is why the same account signs in fine on the website. This page covers what each variant means and the fixes that actually resolve reports, ordered by how often they work.

Error family:   DeviceCheckError / "DeviceCheck registration failed"
Also seen as:   Token generation failed · Preauth PlayIntegrity verification failed
                DeviceCheck token generation is unavailable (macOS)
Codes attached: 403, 500, 503 — these are transport codes, not distinct root causes
Blocks:         native app login only. Browser login is unaffected.
Root cause:     device attestation, not your OpenAI account

Sources are OpenAI's own help article, OpenAI Developer Community threads, and openai/codex issue #33463. Read 6 September 2026.

What DeviceCheck Actually Is

Apple's DeviceCheck and Google's Play Integrity let an app ask the OS vendor "is this a real, unmodified device?" OpenAI uses that to stop bulk account creation on emulators and modified phones.

The sequence when it fails:

You tap Log in. The app asks the OS for an attestation token.
The OS tries to produce one, talking to Apple or Google in the process.
Something in that chain fails.
The app never gets a token, so it never sends your credentials, and you see a DeviceCheck error.

Your account is never involved. That is the single most useful thing to understand here, because it rules out password resets, account recovery and support tickets about billing — none of which touch this.

The 403, 500 and 503 in the search results

People search for devicecheck registration failed (403), (500) and (503) because those numbers appear in the error text. They are HTTP statuses from the attestation call, not separate bugs with separate fixes:

403 — the request was rejected. Usually integrity: a modified device, or an edge/WAF layer refusing the client. Several iPhone reports trace 403 to a Cloudflare challenge during login.
500 / 503 — the attestation service failed or was unavailable. Often transient on the provider side.

If you see 503, wait and retry before changing anything. If you see 403 repeatedly, it is more likely one of the device-side causes below.

Fix 1: Clear Your Browser Cache (Most Reported Success)

The ChatGPT app hands login to your system browser, so a poisoned browser cache breaks the app while the website still works.

This is counterintuitive enough that people skip it, and it is the fix that resolves the most reports.

iPhone: clear the cache in both Safari and Chrome, not just your default.

Settings → Safari → Clear History and Website Data
Chrome → ⋯ → Delete Browsing Data

Android: switch your default browser to Chrome and retry. Multiple reports resolve immediately on moving off Brave or a custom browser.

One community report after months of failed attempts: after clearing both Safari and Chrome caches, "it magically started working perfectly." The mechanism is that login runs through the system browser in the background, so the browser's state is the app's state.

Fix 2: Install Pending OS Updates, Then Restart

A pending security update that could not install is a documented cause.

One iPhone report worked through switching Wi-Fi, hotspot, reinstalling, private mode, and logging out and in — none of it helped. The actual cause was an iOS update blocked by low storage. After freeing space, installing, and letting the phone reboot, login worked immediately.

Check Settings → General → Software Update, install anything pending including security responses, and restart before trying again. Outdated security components can cause the edge layer to reject the device during login.

Fix 3: Device Integrity (And Why Retrying Does Not Help)

If your device is rooted or jailbroken, DeviceCheck failing is the system working as designed. OpenAI's help article names this directly: "Modifications like rooting or jailbreaking may cause this error."

The detail that wastes people's time is in the same article: integrity check results can be cached for up to 24 hours. So if you fix the underlying problem and retry immediately, you are testing against a cached failure. Clear the app data before retrying.

On rooted Android with Magisk, the community fix is the Play Integrity Fix module, then reboot. That is a workaround for a check that is deliberately failing, so treat it accordingly.

Fix 4: Clear App and Play Services Data (Android)

Ordered from least to most disruptive:

Settings → Apps → ChatGPT → Storage → Clear cache
Same screen → Clear data (this signs you out)
Settings → Apps → Play Store → Clear data
Settings → Apps → Google Play Services → Clear cache

Then reboot and retry. Doing all four at once works but tells you nothing about the cause; going in order costs a few minutes and identifies it.

Fix 5: macOS "DeviceCheck Token Generation Is Unavailable"

This variant has a different root cause from every fix above, and none of them will resolve it.

The macOS symptom is distinct: authentication succeeds, the app launches and restores your session, and then Chat fails. From the diagnostics in openai/codex issue #33463, the system logs show:

failed to do a bootstrap look-up: xpc_error=[3: No such process]
Could not find service "com.apple.devicecheckd" in domain for system

preauth_cookie_failed=APIClient.DeviceCheckError: Token generation failed
MobileActivation.ErrorDomain Code=-4 "UCRT is unavailable."
devicecheckd: Failed to fetch client certificate.

One reporter confirmed no HTTP 401, no 403 and no TLS failures — the failure is after authentication, during initialisation. The Secure Enclave key generation and attestation steps succeed; what fails is MobileActivation supplying the client certificate DeviceCheck needs.

What resolved it in that thread:

A plain reboot, for two reporters on an older app version.
Updating macOS and restarting. One persistent case survived 26.5 → 26.6 and multiple app updates, then recovered on 26.6.1 with a restart. The logs flipped to Performing UCRT OOB. Successfully performed UCRT OOB. and devicecheckd immediately obtained new attestation certificates.
That same reporter had also changed their Apple Account password and could not tell which action fixed it.

What did not help: creating a new macOS user account (the failure followed), and toggling Find My.

If you are hitting this, update macOS and restart first. It is an Apple-side certificate problem, so reinstalling ChatGPT is not the lever.

What to Do While It Is Broken

Log in through a browser. The web app does not require device attestation, which is exactly why it keeps working when the native app does not. Every community thread on this confirms the website is unaffected.

If you signed up with email and password, do not try Google, Microsoft or Apple sign-in on the app — mixing methods causes its own separate failure. Use the same method you registered with.

If you need API access rather than the consumer app, DeviceCheck is not in the path at all. API keys authenticate with a bearer token and never touch device attestation, so this class of error cannot occur:

curl -X POST https://api.ofox.ai/v1/chat/completions \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-5.6-sol",
    "messages": [{"role": "user", "content": "..."}]
  }'

That is a different product from the ChatGPT app, not a workaround for it — worth knowing only if what you actually needed was programmatic access.

What Does Not Fix It

Collected from threads where people tried these repeatedly without success, so you can skip them:

Reinstalling the app. Frequently tried, rarely the fix, and on macOS it cannot be the fix because the problem is in Apple's certificate chain.
Password resets and account recovery. Your credentials are never sent. The failure is upstream of them.
Switching Wi-Fi to cellular. Occasionally helps if a network is genuinely blocking the attestation endpoint, but it is far down the list.
Retrying immediately after a change. Integrity verdicts cache for up to 24 hours. Clear app data or you are re-reading a stale result.

One more, for completeness: a firewall can cause this. One macOS user resolved it by allowing ChatGPT four specific connections in Little Snitch. If you run a per-app firewall, check it before anything else on this page.

Related Errors

If your problem is authentication rather than attestation, these are different failures with different fixes:

Codex CLI 401 Unauthorized — a real credential rejection, unlike DeviceCheck.
codex: command not found and EACCES — install-path problems, not login.
Codex "failed to start app-server" on Windows — the Windows desktop equivalent of "the app will not start", with a completely separate cause list.

Sources

Official causes and the 24-hour integrity cache note are from OpenAI's help article. The macOS devicecheckd / UCRT diagnostics and the recovery accounts are quoted from openai/codex issue #33463. Remaining fixes are drawn from OpenAI Developer Community threads where a reporter confirmed the fix worked; they are community reports rather than vendor-documented solutions, and none of this is our own reproduction — DeviceCheck failures depend on individual device state and cannot be reliably reproduced on demand.

Frequently Asked Questions

What does DeviceCheck registration failed mean in ChatGPT?

It means the app could not generate a device attestation token, so OpenAI cannot verify the device is genuine and blocks the login before your credentials are ever checked. DeviceCheck is Apple's device-integrity API and Play Integrity is the Android equivalent. The failure is about your device's relationship with Apple or Google, not about your OpenAI account, which is why the same account signs in fine in a browser.

Why does OpenAI tell me to check my date and time?

Because attestation tokens are time-sensitive and a badly skewed clock will break them. That is a real cause but a rare one. In practice most reports come from a stale browser cache, a pending OS update, a modified device that fails integrity checks, or on macOS a broken devicecheckd certificate. Set the clock to automatic, then move on to the causes below rather than retrying.

How do I fix DeviceCheck error on iPhone?

Clear the Safari and Chrome caches first. The ChatGPT app hands login to the system browser, so a poisoned browser cache breaks the app while the website still works. Then install any pending iOS update and restart; several reports trace the failure to a security update that could not install for lack of storage. If it persists, sign in through the browser and use a different sign-in method than the one that is failing.

How do I fix DeviceCheck error on Android?

Switch your default browser and retry — reports resolve on Android by moving from Brave or a custom browser to Chrome, because login is handed to the default browser. Then clear the ChatGPT app cache and data, and clear Play Store and Play Services data. If the device is rooted, Play Integrity will fail by design; that is the cause, not a bug.

What causes DeviceCheck token generation is unavailable on macOS?

A broken Apple attestation chain rather than anything in ChatGPT. In openai/codex issue #33463 the logs show devicecheckd failing to reach com.apple.devicecheckd, then MobileActivation error code -4, UCRT is unavailable, and Failed to fetch client certificate. Authentication itself succeeds with no 401 or 403; the failure happens after login during initialisation. Reporters recovered by updating macOS and restarting, one after refreshing the Apple Account password.

Does a jailbroken or rooted device cause DeviceCheck errors?

Yes, and OpenAI says so directly. Its help article lists device integrity as a cause and notes that rooting or jailbreaking may trigger the error. It also warns that integrity check results can be cached for up to 24 hours, so clear the app data before retrying or you will be testing against a stale verdict.

Can I use ChatGPT while DeviceCheck is broken?

Yes. Log in through a browser — the web app does not require device attestation, which is why it keeps working when the native app does not. If you need API access rather than the consumer app, an OpenAI-compatible gateway such as api.ofox.ai is unaffected because API keys do not go through DeviceCheck at all.

Originally published on ofox.ai/blog.