Skip to content
CC Switch WikiUnofficial Community Wiki

Format conversion error: No choices in response - CC Switch / Claude Code

Quick fix

ClinePass wraps the response in a data envelope, breaking parsing. Upgrade CC Switch to a version with the fix, or use a local proxy to unwrap response.data.

Symptom

Section titled “Symptom”
Error output
Gateway returned HTTP 422
格式转换错误: No choices in response
probedModel: claude-sonnet-4-6
English translation

Gateway returned HTTP 422 Format conversion error: No choices in response probedModel: claude-sonnet-4-6

Cause

Section titled “Cause”

ClinePass (api.cline.bot) wraps the actual result of non-streaming OpenAI Chat Completions responses in a top-level data field: choices is at response.data.choices instead of the standard response.choices. When CC Switch's local router converts non-streaming response formats, it only reads the top-level choices, and when it can't find them it throws 422 "Format conversion error: No choices in response".

For the same endpoint, streaming (SSE) response chunks have choices at the top level with no envelope, so stream=true works perfectly; a direct upstream request with stream:false reproduces the {"data":{"choices":[...]},"success":true} envelope 100% of the time. The issue is not limited to Claude Desktop's model mapping path: the Claude Code local router's claude channel and the Codex Responses-to-Chat conversion path (with slightly different error text: No choices in chat response, indicating a separate parsing point) both hit it, and it is model-independent (reproduced with cline-pass/kimi-k3 and cline-pass/deepseek-v4.1-flash). Also, this failure is not written to proxy_request_logs; it can only be found in cc-switch.log.

Fix

Section titled “Fix”

  1. Upgrade to a CC Switch version that includes fix PR #5671 (that PR unwraps response.data before converting a non-streaming openai_chat response when the top level has no choices but response.data.choices exists). This issue is still open; before upgrading, confirm the version you use has merged the PR. The reporter confirmed both 3.18.0 and 3.20.4 are affected.

  2. Temporary workaround: put a small local proxy (for example Node.js) between CC Switch and ClinePass that unwraps response.data from upstream responses before forwarding them to CC Switch. The reporter confirmed this eliminates the parsing error; the downside is the extra process, port, and startup configuration.

  3. If the client supports it, prefer streaming (stream: true) requests: streaming SSE chunks have choices at the top level with no data envelope, so they do not trigger this error.

Affected Versions

Section titled “Affected Versions”
ToolClaude Code（含 Claude Desktop 模型映射、Codex 本地路由）
Version3.18.0 - 3.20.4（均为受影响版本，issue 尚未关闭）
PlatformsWindowsmacOS

Source Issues

Section titled “Source Issues”

This page is distilled from 1 real issues

FAQ

Section titled “FAQ”
A direct request to the upstream API returns 200, so why does CC Switch still error?
Because the upstream wraps the Chat Completions result in a top-level data field (response.data.choices). The CC Switch non-streaming conversion path only looks for response.choices, and returns 422 "No choices in response" when it can't find them. The API key, model, and subscription themselves are all fine.
Why does the same ClinePass configuration work in GitHub Copilot / VS Code?
The reporter speculates that GitHub Copilot / VS Code use streaming requests by default, and streaming SSE chunks have choices at the top level with no data envelope, so they don't trigger this problem.
Why don't streaming (stream: true) requests error?
Because in streaming responses the SSE chunks have choices at the top level; the data envelope only appears in non-streaming (stream: false) responses, and only the non-streaming conversion path runs into it.
Why can't I see these 422 failures in CC Switch's usage/request logs?
A user confirmed the failure is not written to proxy_request_logs (0 records with status_code=422), because the conversion returns before accounting happens; it can only be found in the ERROR logs in cc-switch.log (for example "转换响应失败" from proxy::handlers).
Section titled “Related problems”
However, this session isn't eligibleUpdate to a version with the #7893 fix; it writes `CLAUDE_CODE_AUTO_MODE_SERVER` to settings.json when switching proxies.1 issues mergedsession isn't eligibleFor a non-Anthropic upstream or format conversion, set CLAUDE_CODE_AUTO_MODE_SERVER=0 in the provider env.2 issues mergedThe `content[].thinking` in thinking modeSome variants remain unresolved: upgrade to a version with the thinking history normalization fix; for Codex routed through DeepSeek, use a version with the…13 issues merged

This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.