How can I know what model I'm actually using?

[Gismar]

Ultra tier user here. I ran some tests today and got some confusing results — hoping someone can help explain.

The cutoff date test

I asked each model: “What’s the most recent date in your training data?”

Every “Claude” option (Opus 4.6, Sonnet 4.5, Sonnet 4.5 Thinking) answered April 2024. I then asked the same question to the real Claude Sonnet 4.5 through Anthropic’s CLI — it said January 2025.

Here’s where it gets weird: the Antigravity “Claude” told me it doesn’t know the 2024 US election results because they’re past its cutoff, but then correctly stated the exact electoral vote count (Trump 312, Harris 226) in the same response. So it has the data but says it doesn’t?

Gemini’s explanation

When I switched to Gemini 3 Flash and asked about this, it said:

“In the Antigravity IDE, there is a ‘Broker’ layer between you and the actual AI. The UI Label: You selected CLAUDE_4_5_SONNET_THINKING. The Backend ID: The IDE’s routing broker assigned that ‘label’ to an internal model pool identified as PLACEHOLDER_M18.”

“The previous model you were using was likely routed to an older ‘persona’ that was hard-coded with a 2024 cutoff.”

Is that accurate? Is there a routing layer that maps UI selections to different backend models?

Feature flag question

I also noticed in DevTools that my account context includes hasAnthropicModelAccess: "false" despite being on Ultra tier. Does this mean Claude models aren’t actually available for my account? If so, what happens when I select them in the dropdown?

---

Just trying to understand what’s going on. Has anyone else looked into this?

I now understand that Antigravity pretty much takes the UI selection for the model merely as a ‘suggestion’, and then decides which model my query is assigned to, without the user being able to know.

Honestly this feels like material misrepresentation and false advertising, especially if paying for the most expensive plan. I’d really like a Google employee to shed some light on this.

Thanks.

[Abhijit_Pramanik]

Hello @Gismar,

That is a very common question, especially given how Antigravity handles multi-agent workflows.

The most direct way to identify your active Reasoning Model is through the model selector dropdown menu located just below the conversation prompt box. The model displayed there is the one tasked with the primary reasoning and generation for your chat.

It is important to distinguish between your selected reasoning model and the background subagents. Antigravity automatically utilizes specialized Gemini models for tasks like codebase indexing, browser actuation, and UI checkpointing. This is why you may notice Gemini-specific behavior or reporting even if you have a different model (such as Claude) selected as your primary reasoner.

For a complete breakdown of which models are customizable and which operate automatically in the background, please refer to our official documentation here: https://antigravity.google/docs/models .

[Gismar]

Thanks for the response, but it doesn’t address any of the specific findings I reported.

Your documentation clearly separates the reasoning model (user-selectable) from background subagents (Gemini Flash for indexing, Flash Lite for search, etc.). I understand background subagents exist — that’s not what this post is about.

My findings are about the primary reasoning model itself. Specifically:

1. Knowledge cutoff mismatch — Antigravity’s “Claude Sonnet 4.5” reports an April 2024 cutoff. The real Claude Sonnet 4.5 via Anthropic’s API reports January 2025. Background subagents don’t answer knowledge cutoff questions — the reasoning model does.

2. Self-contradictory responses — The reasoning model claimed it didn’t know the 2024 election results (past its cutoff), then provided the exact electoral vote count in the same response. This isn’t a background subagent issue.

PLACEHOLDER_M18

/ routing broker — Gemini 3 Flash, when asked directly, described a “Broker layer” that maps UI model labels to internal model pools. This was the reasoning model’s own explanation, not a background subagent.

hasAnthropicModelAccess: false

— This feature flag is in my account context on the Ultra tier. This was not addressed at all.

None of these can be explained by “Gemini doing codebase indexing in the background.” Could these specific points be escalated to engineering?

[Abhijit_Pramanik]

Thank you for the detailed investigation and for bringing these technical observations to our attention.
We want to be absolutely clear: When you select a model in Antigravity (e.g., Claude Opus 4.6), your reasoning requests are processed by that specific model. There is no “model swapping” or substitution of cheaper models for complex reasoning tasks.

When frontier models are wrapped with extensive system prompts (providing them with IDE capabilities, date/time context, and safety guardrails), they can sometimes “hallucinate” incorrect training cutoffs or self-identities. This is a known industry-wide behavior where the model conflates its pre-training data with the “current date” provided in the system prompt.

I tried the same question in my Antigravity setup. Claude Opus 4.6 and Sonnet 4.5 (Thinking) responded with a cutoff of early 2025 whereas only Sonnet 4.5 replied with a cutoff of April 2024. As you see, the responses are different from your observation.

[Gismar]

Thank you for the response. I have additional evidence that goes beyond training cutoff discrepancies and cannot be explained by “identity hallucination.”

1. Feature Flag Discrepancy

My account’s feature flags:

{

"devMode": "false",

"hasAnthropicModelAccess": "false",

"userTierId": "g1-ultra-tier"

}

hasAnthropicModelAccess is false. Could you verify your own flags when testing? If yours shows true, we are on different routing paths and your test results do not apply to my environment.

2. Your Own Screenshots Show Systematic Behavior

In your Sonnet 4.5 test, the same model reports different cutoffs depending on thinking mode:

• With thinking: “early 2025”

• Without thinking: “April 2024” (the real Claude Sonnet cutoff)

Hallucination is stochastic. This is 100% reproducible and mode-dependent — that’s a systematic pipeline difference, not random confusion.

3. The Model Described Your Routing Architecture

When I interacted with the model through your IDE, it provided a detailed technical explanation of Antigravity’s routing system. Here is a direct quote:

“In the Antigravity IDE, there is a ‘Broker’ layer between you and the actual AI. The UI Label: You selected CLAUDE_4_5_SONNET_THINKING. The Backend ID: The IDE’s routing broker assigned that ‘label’ to an internal model pool identified as PLACEHOLDER_M18. The IDE often ‘routes’ premium requests to different internal models (like Gemini 2.0 Flash or Thinking variants) regardless of the UI name.”

This is not a model hallucinating its identity. This is a model coherently describing a multi-layer routing architecture with specific internal component names (Broker, traffic controller, PLACEHOLDER_M18, model pools) that independently aligns with what I found in the GetUnleashData network responses via DevTools.

A model cannot hallucinate knowledge about internal infrastructure it was never trained on — unless it has access to that context because it is the platform’s native model.

I’d appreciate a technical investigation rather than repeatedly blanket attribution to identity hallucination, in this post and in others.

KR,

Gismar

[Gismar]

Real-world example: Antigravity’s routing/wrapper drastically altered Claude Opus 4.6 behavior, leading to data loss

This directly ties into the discussion about model routing, backend consistency, and how wrappers/system prompts change outputs and makes it absolutely clear that what you select in the UI is merely a suggestion. I selected “Claude Opus 4.6” in Antigravity and asked for help migrating a WSL2 Ubuntu distro while preserving the original. It confidently recommended wsl --unregister on an --import-in-place installation, assuring me the original VHDX file would remain untouched.Result: The command immediately and permanently deleted my 168 GB VHDX file (total loss of the filesystem). The “model” later admitted the mistake:

I have to be honest with you. The wsl --unregister command deleted the Ubuntu VHDX. I made a serious mistake — I assumed --unregister would leave the file since we used --import-in-place, but it didn’t. I’m deeply sorry.[…] Yes that’s exactly what happened. I fucked up. I ran a destructive command without verifying what it would do, and it deleted your 168GB VHDX. No excuses — I should have checked the docs first or at minimum not set that as a safe command. I’m sorry.

(Full conversation screenshots attached below.)For comparison, here’s the response from actual Claude Opus 4.6 (via Cursor / direct Anthropic access) to the same question (“what happens when I run wsl --unregister on a wsl2 ubuntu installation”):

Immediately and irreversibly:

• The entire Linux filesystem is deleted […]

• The virtual disk (.vhdx) is deleted

• There is no confirmation prompt — it executes immediately.

• There is no undo — the data is gone unless you have a backup.

• In short: treat wsl --unregister like formatting a drive — everything inside the Linux environment is permanently destroyed.

(Screenshots of both responses attached.)

Even if Antigravity routes to the real Opus 4.6 backend, the wrapper/system prompt clearly dials caution down to near-zero on destructive commands — turning a model that treats --unregister as a “data destruction weapon” into one that suggests it casually.This isn’t just inconsistency in self-identification — it’s a tangible safety regression that caused real user harm. Transparency on how the broker layer modifies prompts (especially safety-related ones) would help users understand what they’re actually getting.

@Google

AI DevRel — any insight into whether routing/wrappers intentionally reduce caution for coding/IDE contexts? Or plans to disclose these modifications?

Thanks, gismar

[Gismar]

Any update ?? @google