Antigravity: direct Chat/Messages translators without the internal Responses hop #7079

Area

Proxy and routing

What are you trying to accomplish?

Route Chat Completions and Anthropic Messages clients to Google Antigravity (cloud-code-assist) without translating each request through an internal Responses body first, so Antigravity has a direct translator per client protocol: Chat <-> Google, Messages <-> Google, and Responses <-> Google, the same way the earlier native-path work gave Chat and Messages their own lanes (#6559, #6562, #6790, #5918, and the PF series in devlog/_plan/260924_protocol_first_class/).

What prevents this today?

Antigravity uses the google adapter, whose upstream wire is other, so neither the native Chat lane nor the managed native Messages lane can take it. Every Chat or Messages request to Antigravity is translated twice:

• Request: client body -> chatCompletionsToResponsesBody / anthropicToResponsesTranslation -> serialized internal POST /v1/responses -> parseRequest -> IR -> Google wire (src/server/chat-completions.ts:321, src/server/claude-messages.ts:1040, src/server/responses/request-prepare.ts:385).
• Response: Google events -> Responses SSE -> Chat/Messages converter, unless protocols.rollout.directEncoders is on.

devlog/_plan/260924_protocol_first_class/040_acceptance_and_rollout.md lists this as not migrated: "Chat/Messages request decode still produces a Responses-shaped body before the IR (responses-internal) on every non-native path". The baseline target for these cells is already [inbound, ir, other].

Responses <-> Google is already direct (parseRequest decodes Responses into the IR, bridgeToResponsesSSE encodes events back).

What should OpenCodex do?

Behind a new rollout switch (default off, like every protocols.rollout switch), an eligible concrete Antigravity route should:

• decode the Chat or Messages conversation (system text, messages, tool calls and results, thinking and its signatures, tool declarations) straight from the client body into the IR the Google adapter compiles from;
• keep request settings (model, stream, reasoning, limits, tool choice, tier) flowing through the existing core policies unchanged, so rotation, errors, effort policy, usage and logging keep their current owners;
• encode the response with the existing direct client encoders, so neither direction passes through responses-internal;
• name the reason when it declines (combo/policy route, effort or fast row, vision preprocessing, hosted tools/sidecars), and trace the request path as [chat|messages, ir, other].

A differential test should prove the direct decode equals parseRequest(bridgeBody) over a fixture corpus, so turning the switch on cannot change what Antigravity receives.

Example usage or interface

ocx api policy --rollout antigravityDirect=on
ocx api explain --model agy/gemini-3.8-flash --inbound chat
# request path: chat -> ir -> other   (today: chat -> responses-internal -> ir -> other)

Alternatives or workarounds

Reference designs, studied but not added as dependencies:

• router-for-me/CLIProxyAPI @ bf934162: pairwise translators registered per (client, upstream) in internal/translator/antigravity/{openai/chat-completions,claude,openai/responses}. Chat and Claude build the Antigravity request directly; Responses delegates through its Gemini translator. Its Chat path drops thought signatures.
• Wei-Shaw/sub2api @ 4d9ac3e4: uses Anthropic Messages as the pivot. Messages -> Antigravity is direct; Chat goes Chat -> Responses -> Anthropic -> Gemini.

In OpenCodex the IR already plays the pivot role, and the Google wire compiler already owns signature replay, so the direct decoders target the IR and leave src/adapters/google.ts unchanged.

Additional context

Coordination: #7071 (feat/argon-model) edits the Antigravity model list and CLI headers; this work does not touch those files.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.