Gemini's models endpoint told me it had 41 models that answer generateContent. I called all 41 with the same eight-token request, and 16 of them refused. Seven of those refusals came from models that had declared generateContent in the very response I read them from.

You are picking a model. The obvious move is to ask the API what it has rather than trust a docs page that might be a release behind. GET /v1beta/models comes back with a long JSON array, each entry carrying a supportedGenerationMethods list, and it feels like the authoritative answer because it came from the thing that will actually serve your traffic.

It is authoritative about inventory. It is not a capability check, and the difference is 39% of the list.

The endpoint advertises 41 models for generateContent, and 25 of them serve it

The probe is small. List every model, keep the ones whose own supportedGenerationMethods includes generateContent, then send each one the same minimal request: the prompt Reply with the single word: ok, capped at maxOutputTokens: 8, four seconds apart. Run it with node docs/news-research/gemini-model-inventory-probe.mjs.

Filtering to the models that claim generateContent matters. The endpoint returned 58 models on 2026-09-18, and calling generateContent on an embedding model would fail for a reason nobody would call surprising. Counting those would inflate the result and earn it nothing. The denominator is 41 because those are the 41 places the API made a claim I could check.

Outcome Count
Served, HTTP 200 25
Refused 16
Quota-blocked, HTTP 429 0
Transport errors 0

Zero 429s is worth a sentence of its own. A previous test on this key died to an exhausted free-tier quota partway through, which is the kind of thing that turns a measurement into an anecdote. Every one of the 41 calls came back with a verdict. Nothing here is extrapolated from a partial run.

Sixteen refusals in four groups: seven Interactions-only, three retired, two wrong modality, four other

The biggest group of refusals is the model resource contradicting itself

I expected retirements. Three models are retired for new keys, and they say so clearly:

HTTP 404 NOT_FOUND: This model models/gemini-2.5-flash is no longer available
to new users. Please update your code to use models/gemini-3.6-flash for the
latest features and improvements. We recommend you to use the Interactions API.

gemini-2.5-pro and gemini-2.5-flash-lite return the same shape. That is three of sixteen, and it is the boring, honest kind of failure: an old model, an explicit successor, a message you can act on.

The larger group is seven models, and it is not a retirement at all. gemini-omni-flash-preview, gemini-omni-1.1-flash, both antigravity-preview builds, and all three deep-research models arrive in the list carrying exactly this:

"supportedGenerationMethods": ["generateContent", "countTokens"]

Call any of them and you get:

HTTP 400 INVALID_ARGUMENT: This model only supports Interactions API.

Those two strings came out of the same API, about the same model, minutes apart. One says the model supports generateContent. The other says it only supports a different API entirely. There is no version skew to blame and no deprecation window to read: the declaration and the refusal are both current.

Archived probe output showing seven models declaring generateContent and returning 400 only supports Interactions API

The remaining six split into refusals that tell you how to fix them and refusals that do not. The two TTS models reject a text response modality and name the one they accept. gemini-2.5-computer-use-preview-10-2025 says it needs the Computer Use tool attached and links the page explaining how. Those are fair: my request was wrong, the API said so precisely, and a correctly shaped call would plausibly succeed. Then lyria-3-pro-preview and gemini-3.1-flash-tts-preview answer a bare Request contains an invalid argument. with nothing to act on, and lyria-3-clip-preview returns a 500 that may well be transient. I counted the 500 as a refusal and I am telling you it is one sample.

Four documentation surfaces say these models answer generateContent

The self-contradiction would be a curiosity if the docs resolved it. They do not. Checked on 2026-09-18:

  • The model resource reference defines the field in six words: "supportedGenerationMethods[] string The model's supported generation methods." No caveat, no guarantee language, and no note that a listed method might be refused.
  • The models page lists Gemini Omni Flash, Gemini Deep Research, Gemini Deep Research Max and Antigravity Agent in its model tables, each with the exact model ID I called. It does not say any of them require the Interactions API, and it does not say any Gemini 2.5 model is closed to new users.
  • The Interactions API page says the opposite of exclusive: "The original generateContent API remains fully supported."
  • The changelog records "Launched the Interactions API" on December 11, 2025 and carries no entry restricting models to it, and no entry about 2.5 availability for new users.

The Interactions page is the one that comes closest to explaining the seven, and it only gets partway. Its "Supported models & agents" table has 13 rows, and it does type the three deep-research entries as Agent rather than Model, which is a real distinction the models endpoint does not make. But antigravity-preview-05-2026, antigravity-preview-09-2026, gemini-omni-flash-preview and gemini-omni-1.1-flash are not in that table at all, and all four still refuse with "This model only supports Interactions API". The same table also lists gemini-2.5-pro, gemini-2.5-flash and gemini-2.5-flash-lite, which lines up with what the 404 recommends and is the most useful thing on the page: if you need those three on a new key, the Interactions API is where they went.

So no documented surface tells you in advance that deep-research-pro-preview-12-2025 will reject a generateContent call. The closest hint is a type column on a different page, and it does not cover four of the seven.

This is the same shape as the parameters problem, one endpoint over

ClearContext hit a near neighbour of this in Google deprecating temperature while the API kept accepting it. There, the model resource advertised sampling parameters the changelog had retired, and requests carrying them returned HTTP 200. The failure ran in the other direction: the API accepted what the docs had withdrawn.

Put the two together and the pattern is not "the docs are stale". It is that Gemini's model metadata is a description of a model maintained separately from the routing that decides what any given endpoint will actually do with it. When those two drift, the metadata does not learn about it, in either direction.

What I cannot tell you from one key

One API key, free tier, v1beta, one day. Three limits follow from that and I would rather name them than let the 39% travel without them.

The 404 says "no longer available to new users", which strongly implies an older key still serves those three. I have no old key, so I cannot isolate key age as the variable, and the retirement bucket may simply not exist for an account created last year. The v1 endpoint is untested. And the probe proves only that these models refuse this minimal text request, which for the TTS and Computer Use cases the error itself explains how to fix. Three of the sixteen, the two TTS models and the Computer Use one, are my request being wrong rather than the API being wrong, and they are in the count because the endpoint still told me generateContent was available and it was not, not because I think Google broke something.

What survives all three caveats is the seven. No request shape fixes "this model only supports Interactions API", and no documentation page warns you before you send it.

Call the model before you plan around it

If you are choosing a model programmatically, treat models.list as a catalogue and not as a contract. The cheap version of this is a startup probe: one eight-token request to each model you intend to use, run once when your config changes rather than on every request. It costs almost nothing, it takes four seconds, and it is the only check that reflects what the endpoint will do with your traffic. I would rather find out from a health check at deploy time than from a 400 in the path of a user request, and after this run I know the difference is not hypothetical for 16 models out of 41.

Probe run 2026-09-18. Every response, including failures and headers, is archived in docs/news-research/gemini-model-inventory-raw.json, and the full method is in docs/news-research/gemini-listed-models-that-refuse.md. The four documentation sources above were re-checked on publication day.