All Google (Gemini) models available through the API

Compare Gemini and related Google API models by the media they accept, the output they produce and the interface they support. Preserve official identifiers when moving from a catalog entry to code.

Model families at Google

The catalog contains general Gemini entries and specialized image, speech, live and other media models. Nano Banana entries identify image-generation models rather than a separate API provider. Official documentation.

Build a shortlist for a single outcome first. A transcription workflow, an image-editing workflow and a document-answering workflow need different evaluation fixtures.

Start with the artifact the application needs to produce. A text answer, edited image, spoken response and embedding are different outcomes. Write evaluation criteria suited to each one before selecting a model. A common provider name does not turn them into interchangeable endpoints.

For a document workflow, distinguish understanding an image of a page from extracting reliable fields from it. Include incomplete scans, distracting material and missing evidence in the evaluation pack. For generated images, write a visual acceptance checklist and inspect the actual output. For audio, arrange listening checks that reflect the intended use rather than assuming a transcript captures every quality issue.

Use catalog descriptions to shortlist candidates, then keep your observed results separate from the provider’s positioning. A useful recommendation states which capability is documented and which behavior was evaluated. Avoid converting a family label into an unsupported universal quality ranking.

All models

Inspect the exact endpoint identifier and the status of the entry. A preview suffix or specialized output capability is part of the model selection, not decoration. Keep the chosen identifier in configuration and record the value that the running application actually sends.

Check the interface used by the example you are following. Current Gemini documentation distinguishes Interactions from generateContent for certain features. A model’s presence in the catalog does not establish that every example, cache option or batch path uses the same request shape.

Leave fields with insufficient verified evidence unresolved. An incomplete public record should lead to a source check, not an invented specification. When the application depends on that field, use the official model entry to establish it before presenting a deployment decision as settled.

Cheapest / strongest / longest-context

Treat these as attribute rankings. A larger context allowance does not prove better document retrieval or more faithful evidence use.

Compare costs within a compatible workload class. A text-token rate and an image-output rate cannot be ranked meaningfully without defining the job each one performs. Keep the output requirements fixed while evaluating candidates so a cheaper but unusable artifact is not counted as a saving.

Use context capacity as a filter for candidate inputs, then test evidence use. Include a relevant passage among distracting material and check whether the answer finds and attributes it. Compare that with a more selective input pipeline. More supplied content should earn its place through a better result, not simply because the model accepts it.

For a strongest claim, identify the task, fixture set and measured result. If only documented capability data is available, present a fit-based shortlist and leave the quality comparison open. This gives the next evaluation a clear purpose instead of disguising an assumption as a benchmark.

Deprecations and replacements

Keep the selected API identifier in a configuration record and review the linked provider lifecycle guidance before an upgrade. Check interface-specific features again when moving an application.

Save the current request and accepted output fixtures before changing identifiers. Inventory interface-specific features, media preparation and output handlers. A model migration can appear successful while a downstream parser or visual requirement has silently changed.

Read the lifecycle and migration material linked by the provider for the actual model. Treat a recommended replacement as a candidate to evaluate, not proof of identical behavior. Test awkward examples, missing evidence and the output format the application depends on. Keep rollback deliberate while the previous deployment remains available.

After an accepted migration, update the model record, cost assumptions and operating documentation together. Preserve why the new candidate was chosen and what was tested. This makes the next change understandable to someone who did not participate in the original experiment.

Naming and versions

Copy the endpoint identifier from the relevant model entry, including any preview suffix. Do not construct an identifier from a product nickname. Official documentation.

Read the applicable media charge categories and model capacity before committing to a replacement.

Use the AI API cost calculator to turn the model and workload you are considering into an estimate.

Keep nicknames and API identifiers separate. A user-facing explanation can say Nano Banana where the documentation uses that product name; a request must use the corresponding model identifier. Do not infer a string from a nickname or remove a suffix because it looks unnecessary.

Check all model-selection points before declaring an application migrated. A scheduled job, sample script and deployed setting can each retain their own value. Centralize the choice where practical and make changes reviewable. Record the actual value in protected diagnostics without logging sensitive prompt content.

When a model-not-found response appears, inspect the runtime identifier and project access first. Do not switch to any familiar model solely to obtain a response. Choose a documented candidate that fits the input and output requirements, then rerun the application checks before restoring unattended work.

Last verified 12 Sep 2026 · Source ↗

Frequently asked questions

Sources

• Gemini API getting started ↗
• Gemini models ↗
• Developer API pricing ↗
• Rate limits ↗
• API-key management ↗
• API errors ↗
• Troubleshooting ↗
• Billing ↗
• Context caching ↗
• Batch API ↗
• Python SDK reference ↗

Last verified 12 Sep 2026 · Source ↗