Repository navigation
feat(protocols): Antigravity direct lane for Chat (no internal Responses hop) - #7080
Merged
Merged
Conversation
Behind protocols.rollout.antigravityDirect (default off), a Chat request whose settled route is one concrete Google Antigravity provider no longer goes through the internal Responses body. The ingress validates and decodes the conversation with chatConversationToIr and hands the Responses core only the request settings (chatSettingsToResponsesBody, built by the same applyChatSettings as the bridge body). The decoded conversation replaces the settings-only parse at the parse seam; the answer uses the direct Chat encoder. The trace reads chat -> ir -> other both ways. The lane is held to the bridge it replaces: the parsed request equals parseRequest(chatCompletionsToResponsesBody(body)) apart from _rawBody and timestamps, refusals match, and the Google wire body is identical. A route that leaves Antigravity after the ingress decided gets the bridge conversation restored before any other reader sees the raw body. Refs #7079
Contributor
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configuration
📒 Files selected for processing: 31
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
|
✅ Deterministic PR hygiene checks passed. |
…under rewrites Address independent review of the first head: - decline when the core would rewrite conversation text on the bridge body (a skills catalog, a generated-image link) or the cache diagnostic recorder is observing; - restore the bridge conversation right after every route assignment, before sanitization, ciphertext stripping and injected guidance can touch the raw body; - judge ambiguous-resend replay on the body the bridge would have sent; - predict the lane only for standalone routes, not combo children; - skip an own __proto__ parameter key as the schema parse does; - rename the eligibility test so its seed domain matches its registration. Refs #7079
…record The cache diagnostic hook is registered whenever its module loads; recording is gated by OPENCODEX_CACHE_DEBUG. Checking registration alone declined every request and made the lane unreachable. The hook now reports its enabled state. Refs #7079
lidge-jun
marked this pull request as ready for review
October 13, 2026 19:34
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
This was referenced Oct 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes the Chat half of #7079.
A Chat Completions request routed to Google Antigravity used to be translated twice in each direction: Chat body → internal Responses body (serialized and replayed as
POST /v1/responses) → IR → Google wire, and back through Responses SSE unlessdirectEncoderswas on. Antigravity'sgoogleadapter has theotherwire, so neither native lane could take it.With the new rollout switch
protocols.rollout.antigravityDirect(default off), an eligible Chat request to one concrete Antigravity route goeschat → ir → otherand backother → ir → chat:chatConversationToIr(src/protocols/codecs/chat-ir.ts) and gives the Responses core only the request settings (chatSettingsToResponsesBody:input: [], noinstructions/tools). The bridge body and the settings-only body come from oneapplyChatSettings, so settings and their validation can't drift. Routing, Antigravity account rotation and failover, effort pins and caps, tier, spend, usage and logging still read the same settings in the same places. At the parse seam,directRequest.decodereplaces the empty conversation.requestLane: "direct"in the trace.web_searchtool (sidecar), image for a text-only model (vision preprocessing), a model the shadow-call intercept could rewrite, text the core rewrites on the bridge body (a<skills_instructions>catalog, a generated-image link), and an observing cache diagnostic recorder. If a route assignment ever leaves Antigravity after the ingress decided, the bridge conversation is restored onto the raw body right there, before sanitization or injected guidance can touch it. Ambiguous-resend replay is judged on the body the bridge would have sent.path.tsgains adirectlane (only towardother).features.tsgives the direct decode hop thechat>responsesdispositions, sounrepresentable: rejectrefuses the same features on both paths. The planner predicts the lane through the same eligibility rule.Responses ↔ Antigravity was already direct (
parseRequest,bridgeToResponsesSSE). Messages → Antigravity stays on the bridge for now. Its settings depend on the conversation (the prompt-cache key hashes system text and tools), and it carriesocxr1reasoning envelopes, so it follows as a stacked PR. The design, the route map and the earlier records this mirrors (#6559, #6562, #6790, #5918, PF-09) are indevlog/_plan/261014_antigravity_direct_protocols/000_plan.md.References studied, not added as dependencies: router-for-me/CLIProxyAPI @
bf934162(pairwise translators; Chat and Claude direct to Antigravity, Responses via Gemini) and Wei-Shaw/sub2api @4d9ac3e4(Anthropic as pivot; Chat goes Chat → Responses → Anthropic → Gemini).No files from #7071 (
feat/argon-model: model list, CLI headers,google.ts,google-antigravity-wire.ts) are touched.Verification
This host runs no local tests by policy, so the new suites first run in hosted CI.
bun x tsc --noEmit: pass. The new and edited test files also typecheck under a scratch config that includes them. The only error there is pre-existing, inscripts/test-temp-lock.ts.bun run structure:check: pass.bun run privacy:scan: pass.tests/responses/protocol-chat-ir-parity.test.tscompares the lane's full parsed request (minus_rawBodyand timestamps) withparseRequest(chatCompletionsToResponsesBody(body))over a corpus covering every branch of the walk. It also checks that refusals match by message, and that routing evidence and feature effects match the bridge.tests/responses/protocol-antigravity-direct-eligibility.test.tscovers each decline reason and the planner's direct path.tests/responses/protocol-antigravity-direct-chat.test.tssends the same Chat request, streaming and not, to a fake Cloud Code Assist upstream on both lanes. It requires an identical wire body (minus the randomrequestId), an identical client answer, and thechat → ir → othertrace, and checks a declined request's reason.tests/config/protocol-settings.test.tsgains the new default.Checklist
Summary by CodeRabbit
New Features
antigravityDirectoption for eligible Chat requests to a single Google Antigravity route. When enabled, requests and responses can use a direct protocol path without an internal Responses body.Documentation
Tests