bug(antigravity): Claude compatibility issues (output_config leak + maxOutputTokens clamp)

[DevGuyRash]

Is it a request payload issue?
[X] Yes, this is a request payload issue. I am using a client/cURL to send a request payload, but I received an unexpected error.
[ ] No, it's another issue.

If it's a request payload issue, you MUST know
Our team doesn't have any GODs or ORACLEs or MIND READERs. Please make sure to attach the request log or curl payload.

Scope

This issue tracks Antigravity-side Claude compatibility problems only.

It is distinct from the direct Claude/Codex translation issue in #1671.

The important protocol distinction is:

• Source request shape may be Claude-compatible / Codex / Anthropic-style.
• Failing upstream path in this issue is the Antigravity executor.

Those are different layers and should not be conflated.

Bugs Covered Here

This issue now covers the two Antigravity bugs that were actually verified and fixed together:

1. Claude-only output_config leaked into the Antigravity upstream request body
2. Antigravity Claude thinking aliases did not clamp oversized request.generationConfig.maxOutputTokens to the model-supported limit

Both produced Antigravity-side INVALID_ARGUMENT failures, but with different causes.

Bug A: unexpected output_config field in Antigravity upstream request

The original observed failure was on the Antigravity Claude-thinking route (claude-opus-4-6-thinking / claude-opus-4-6-thinking(xhigh)), not on the direct Claude provider.

The earlier issue text overfit this bug to a specific payload configuration example using protocol: "claude" and output_config.effort. That payload snippet came from later debugging attempts and was not the original reproduction that triggered this issue.

What was actually verified is narrower: an unexpected output_config field could reach the Antigravity upstream request body on the Claude-thinking route, and Antigravity rejected it because output_config is not a valid upstream field there.

The original downstream request capture that motivated this issue showed the Antigravity-facing failure on claude-opus-4-6-thinking(xhigh) with:

{
  "error": {
    "code": 400,
    "message": "Invalid JSON payload received. Unknown name \"output_config\" at 'request': Cannot find field.",
    "status": "INVALID_ARGUMENT"
  }
}

Payload rules may still have been one possible way to surface the same bug during later testing, but they should not define Bug A’s reproduction story in this issue.

Bug B: missing max-token clamp for Antigravity Claude thinking aliases

A separate Antigravity bug affected Claude thinking aliases such as:

• claude-opus-4-6-thinking
• claude-opus-4-6-thinking(xhigh)

The problem was not the slug itself. The problem was that Antigravity requests could forward oversized request.generationConfig.maxOutputTokens values instead of clamping them to the model-supported completion limit.

This surfaced as Antigravity INVALID_ARGUMENT errors for oversized max_tokens values.

Verified status

Both Antigravity bugs above were verified and fixed in draft PR #1766.

Live verification against the rebuilt local service showed:

• claude-opus-4-6-thinking succeeded with max_tokens=64000, 64001, and 128000
• claude-opus-4-6-thinking(xhigh) succeeded with max_tokens=64000, 64001, and 128000
• direct Claude regressions remained successful

Expected behavior

CLIProxyAPI should:

• consume Claude-compatible compatibility fields where needed
• strip invalid Antigravity-upstream fields such as output_config
• clamp Antigravity Claude thinking alias output-token requests to the supported model limit before upstream submission

CLI Type

codex

Example model aliases observed

claude-opus-4-6-thinking
claude-opus-4-6-thinking(xhigh)

OS Type

• OS: Arch Linux
• Version: rolling

Related issues

• BUG: Cannot use Claude Models in Codex CLI #1671: separate direct Claude/Codex translation issue
• bug: "status": "INVALID_ARGUMENT" when using antigravity claude-opus-4-6 #1535: related Antigravity Claude-thinking INVALID_ARGUMENT symptom history
• feat(thinking): support Claude output_config.effort parameter (Opus 4.6) #1540: Claude output_config.effort support context