Genie 4 API: access and integration checklist

Use Google’s launch post for the announced access route and the developer documentation for callable interfaces. One should not be substituted for the other. This page was checked on 30 October 2026; it does not provide an unverified Genie 4 model ID, sample response, or rate card.

A working Gemini API key is proof of access to that API account. It is not proof that every research model announced by Google is callable from it.

Before implementing, require an official model identifier, endpoint contract, authorization requirements, limits, and pricing. If those are missing, write a discovery task rather than an integration estimate.

The extra “m” matters. Gemini 4 Argon is documented separately as a reasoning model. Its model code and token pricing cannot be used as Genie 4 world-generation specifications.

The screenshot below shows the official Argon model page and its text-output entry. It is included to help verify model names, not to suggest that calling Argon produces an interactive Genie world.

Our suggested checklist makes unknowns explicit. Save the answers with links to the official documentation and the date you checked them.

• Access: is this account or organization approved for the exact model?
• Contract: are the input types, output format, and session lifecycle documented?
• Interaction: how are user actions, camera movement, and edits sent?
• Delivery: what transport, latency behavior, and disconnect handling are specified?
• Economics: how are usage, quotas, limits, and billing measured?
• Data: what storage, deletion, retention, and output-use rules apply?
• Operations: what retry, timeout, availability, and versioning guarantees exist?

An unanswered item should remain “unknown.” Borrowing a number from a different model can make a prototype appear more certain than it is.

Build a clearly labeled local prototype of your own application: the prompt form, loading and disconnect states, keyboard-accessible controls, and a place for session history. Use your own placeholder data and label it as a simulation of your interface.

Keep the model adapter separate from the UI. This is our implementation advice, not an assertion about Google’s eventual API. It lets you replace a placeholder with a documented provider contract later without pretending the backend already works.

Define an acceptance test around a user task: “create a scene, apply one edit, recover from a disconnect.” Leave transport details undecided until official documentation resolves them.

For exploratory work, a small time-boxed spike may be enough. For a customer promise, first verify access, cost, deliverable format, and acceptable failure behavior. If a project requires editable meshes or a game-engine export, ask for explicit evidence of that output; an interactive video demonstration is not a substitute.

Use the demo evaluation checklist to define the behavior you need to test. Do not expose API keys in client code or screenshots when a documented integration becomes available.