Native Opus 5.5 tasks fail with 400 for fallback-credit-2026-07-01; fresh CLI controls pass

[nekdima]

Describe the bug

An interactive Claude Opus 5.5 request was reported to fail with HTTP 400 because the service rejected the anthropic-beta value fallback-credit-2026-07-01.

Native task calls in the current running troubleshooting session reproduced the exact error 5/5 times when explicitly requesting claude-opus-5.5. This included a minimal response-only prompt, both max and high effort, and two agent types. A matched Sonnet 5.5 native-task control succeeded.

Important distinction: the failure is repeatedly reproducible in this running session's native task path, but all 26 fresh CLI probe invocations passed, including a contemporaneous Opus request with existing config and credentials. A fresh, standalone failing shell reproduction has not been obtained. This is not a claim that every Claude request is broken or that a root cause or fix has been established.

Sanitized error:

Execution failed: 400 Unexpected value(s) `fallback-credit-2026-07-01` for the `anthropic-beta` header. Please consult our documentation at platform.claude.com/docs or try again without the header. (Request ID: <REDACTED>)

Affected version

GitHub Copilot CLI 1.0.90-7.

• OS: macOS 27.0.1
• Architecture: arm64
• Date observed: 2026-09-30; initial report approximately 20:37 UTC.
• Controlled CLI probes ran approximately 20:52-21:05 UTC.
• The latest public release reported by the repository API during troubleshooting was v1.0.89. That version was not tested; this report does not establish a version regression.

Steps to reproduce the behavior

The original reported failing path was an interactive Copilot CLI session using Claude Opus 5.5, followed by a chat request. During troubleshooting, the native task tool repeatedly failed when requesting Opus in the current running troubleshooting session. The original report is distinguished from these directly observed task failures.

This minimal native tool invocation was actually exercised and returned the exact 400. So far this has reproduced only in the already-affected running session. A fresh CLI session whose GPT parent requested a native Opus 5.5 max task returned OK (effective child model not independently verified).

{
  "description": "Test lower-effort native Opus",
  "agent_type": "rubber-duck",
  "model": "claude-opus-5.5",
  "reasoning_effort": "high",
  "name": "native-header-high",
  "prompt": "Line 1 of your reply: `model: <your model ID>`.\nThis is a diagnostic inference request, not a review. Do not invoke tools, read files, access network, edit anything, or delegate. Reply `OK` on line 2 and stop."
}

Changing only model to claude-sonnet-5.5 in the response-only native control returned:

model: claude-sonnet-5.5
OK

Changing only agent_type from rubber-duck to general-purpose with Opus/high and the same prompt still produced the exact error. Names/descriptions were adjusted only as diagnostic labels.

The original session content and original task prompts are intentionally withheld. Only the harmless synthetic diagnostic prompt is included above.

The following sanitized standalone command was actually exercised as a negative control. It returned OK, not the reported error:

# An authenticated token was supplied through the environment, never argv.
# COPILOT_HOME pointed to an otherwise empty diagnostic configuration directory.
COPILOT_HOME="<empty-config-directory>" \
copilot --no-auto-update \
  --model claude-opus-5.5 --reasoning-effort high \
  --no-custom-instructions --disable-builtin-mcps --available-tools \
  --allow-all-tools --deny-tool shell --deny-tool write --deny-tool url \
  --no-remote --no-remote-export --no-color \
  --log-dir "<private-log-directory>" --log-level debug \
  -p 'Reply exactly OK.' --silent

Observed control result:

OK
exit code: 0
exact target-header error: absent

The diagnostic config disabled hooks and automatic IDE connection. No original conversation, repository files, attachments, or resumed session were included. For existing-config comparisons, configured MCP servers were disabled for the run. Authentication comparisons used an environment-only token versus existing CLI credentials. No installed binary upgrade or source modification was performed.

Troubleshooting results

A classifier distinguished the exact target-header error from success, authentication errors, rate/quota errors, other beta-header errors, other HTTP errors, and timeouts. Nine synthetic classifier fixtures passed, including a target-error fixture with ANSI codes and a line break. Those fixture passes validate classification only; they are not a reproduced service failure.

Controlled condition	Probe invocations	Observed result
Empty config, Opus 5.5, high, default context	5	All returned OK
Empty config, Opus 5.5, max, default context	3	All returned OK
Empty config, Opus 5.5, max, long_context	2	Both returned OK
Existing config, Opus 5.5, max, environment-token authentication	1	Returned OK
Existing config, Opus 5.5, max, existing credential path	2	Both returned OK
Existing config, Opus 5.5, high, existing credential path, in parallel with the native general-purpose/high failure	1	Returned OK
Empty config, Sonnet 5.5, high	3	All returned OK
Empty config, GPT-6.1 Sol, high	3	All returned OK
Empty config, Opus 5.5, experimental explicitly off/on	1 each	Both returned OK
Empty config, Opus 5.5, streaming off	1	Returned OK
Empty config, Opus 5.5, synthetic padding of 8,192/65,536 characters	1 each	Both returned OK
Empty config, GPT parent requesting a native Opus 5.5 task	1	Returned OK; child identified as Claude but its exact effective model ID was not independently verified

The 26 successful CLI probe invocations are separate from the originally reported interactive failure and the native failures observed during troubleshooting.

Native tool in the affected running session	Attempts	Observed result
Opus 5.5, rubber-duck, max	3	All returned the exact target-header 400; one used the minimal response-only prompt
Opus 5.5, rubber-duck, high, response-only prompt	1	Exact target-header 400
Opus 5.5, general-purpose, high, same response-only prompt	1	Exact target-header 400
Sonnet 5.5, rubber-duck, max	2	Both review retries completed and reported the requested model ID
Sonnet 5.5, rubber-duck, high, matched response-only prompt	1	Reported the requested model ID and OK

Reducing effort and changing agent type did not clear the native Opus failure. The matched native Sonnet control and fresh CLI Opus control succeeded. These observations establish a useful request-path boundary, not the origin of the beta header. Different session context and runtime state remain relevant uncontrolled differences.

A boolean-only scan found no occurrence of the target beta literal in the private logs of the successful standalone probes. This is inconclusive about header generation: absence from logs does not establish absence from a wire request.

An initial harness setup attempt rejected an invalid permission-rule spelling before inference. It was corrected using documented rules and excluded from the 26 inference probe invocations.

Expected behavior

Enabled Claude requests should complete normally. If a beta feature is unsupported on a route, the CLI/service should avoid sending an unsupported beta identifier or recover safely rather than fail an ordinary request with HTTP 400.

Additional context

An exact-literal search across open and closed issues in this repository returned no matches at filing preparation time. GitHub Status reported Copilot and Copilot AI Model Providers as operational, with no active incidents; that does not exclude an unreported or narrower service issue.

No causal hypotheses are presented as findings. A stale live-process/session value remains an unconfirmed possibility; the affected process was not restarted during the investigation. There is no verified local fix or source-level regression test: the failing native production path is reproducible in the affected session, but not in the standalone harness.

Please investigate validation/routing for this beta identifier and advise which targeted, non-sensitive diagnostics would distinguish its origin. Request correlation details can be provided through a private support channel if needed.

For privacy, this report includes no raw logs, credentials, account or organization details, billing figures, workspace paths, original conversation/task content, MCP configuration, or attachments.

[eduardosantos1989]

for me its the same with sonnet-5.5 but only in CLI...