All Gemini models return an empty stream (HTTP 200, 0 tokens, turn never closes) while Claude and GPT-OSS work on the same account

[Mani212005]

Summary

On @cortexkit/pi-antigravity-auth@2.0.0 with pi 0.83.0, every Gemini model returns an empty assistant message and the turn is never closed. The Claude and GPT-OSS models work perfectly on the same account, same credentials, same install, in the same session.

In pi's interactive TUI this presents as Working... forever with no error, no stderr, and no timeout. In --print mode it exits 0 with completely empty output.

This is not auth, not quota, and not thinking level — evidence below.

It may be related to "Missing Gemini 3.1 Pro Route Table" in #1, but the failure shape is different: that reported a 400, whereas this is a 200 with an empty stream, and it affects Gemini 3.6 Flash as well as 3.1 Pro.

Environment

• @cortexkit/pi-antigravity-auth 2.0.0 (latest published)
• @cortexkit/antigravity-auth-core 2.0.0 (latest published)
• pi 0.83.0
• macOS (Darwin 24.6.0), Node via npm global prefix
• Account: Google AI Pro. Antigravity CLI 1.1.10 works normally on the same account with Gemini 3.6 Flash.
• No proxy env vars set (ALL_PROXY / HTTPS_PROXY / NO_PROXY all unset)

Reproduction

pi -p "say hi" --model google-antigravity/antigravity-gemini-3.1-pro --no-session --no-tools

Exits 0. Prints nothing at all.

pi -p "say hi" --model google-antigravity/antigravity-claude-sonnet-4-6-thinking --no-session --no-tools

Prints Hi! How can I help you today? as expected.

Isolation matrix

Same machine, same account, same install, back to back:

Model	Result
antigravity-gemini-3.1-pro	empty, turn never ends
antigravity-gemini-3.1-pro with --thinking off	empty, turn never ends
antigravity-gemini-3.6-flash	empty, turn never ends
antigravity-claude-sonnet-4-6-thinking	works
antigravity-gpt-oss-120b-medium	works

The split falls exactly along Antigravity's two quota groups: everything in the Gemini group fails, everything in the Claude and GPT group works.

Evidence — the stream opens and is never closed

--mode json on antigravity-gemini-3.1-pro, full output:

{"type":"session","version":3,"id":"019fcac0-652c-7482-8df8-a19ec5fdc75d",...}
{"type":"agent_start"}
{"type":"turn_start"}
{"type":"message_start","message":{"role":"user","content":[{"type":"text","text":"say hi"}],...}}
{"type":"message_end","message":{"role":"user","content":[{"type":"text","text":"say hi"}],...}}
{"type":"message_start","message":{"role":"assistant","content":[],"api":"google-generative-ai","provider":"google-antigravity","model":"antigravity-gemini-3.1-pro","usage":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"totalTokens":0,"cost":{"total":0}},"stopReason":"stop",...}}

The stream ends there. Note:

• The assistant message_start has content: [].
• totalTokens: 0 — no usageMetadata ever arrived.
• There is no message_end, no turn_end, and no agent_end. The turn is never closed, which is what wedges the interactive TUI indefinitely.

Why this is not an HTTP error being swallowed

dist/index.js throws on a non-OK response:

if (!response.ok) {
  throw new Error(
    `Antigravity request failed: HTTP ${response.status} ${await response.text()}`
  );
}

No such error is raised, so the request is returning HTTP 200 with a body that yields no candidates[].content.parts[] and no usageMetadata.

Ruled out

• Quota — Gemini group shows 83% of the weekly limit remaining and the 5-hour limit fully available; Claude/GPT group also full. The group that fails is the one with quota remaining.
• Auth — same credentials serve Claude and GPT-OSS successfully in the same session. Re-authenticating did not change the behaviour.
• Thinking level — --thinking off fails identically.
• Stale package — both packages are at the latest published 2.0.0.
• Proxy interference — no proxy environment variables set.
• pi version / host integration — reproduced with --no-session --no-tools, outside any project, with no other extensions loaded.

Impact

Gemini models are unusable through this extension, and the failure is silent — no error surfaces to the user, the session simply hangs forever. That makes it look like a client hang rather than a provider problem, which is a difficult failure to diagnose.

Happy to run further diagnostics or test a patch.