Google AI Studio
YouTube ... Quora ...Google search ...Google News ...Bing News
- Google Gemini Notebook ... Google AI Studio ... Google Antigravity
- Google AI Studio homepage
- Conversational AI ... ChatGPT | OpenAI ... Gemini | Google ... Claude | Anthropic ... Bing | Microsoft ... Siri | Apple ... Meta AI/Manus | Meta ... Perplexity ... Grok | SpaceXSI ... Ernie | Baidu ... DeepSeek ... Qwen | Alibaba
- End-to-End Speech ... Synthesize Speech ... Speech Recognition ... Music
- Video/Image ... Vision ... Enhancement ... Fake ... Reconstruction ... Colorize ... Occlusions ... Predict image ... Image/Video Transfer Learning ... Art ... Photography
Google AI Studio is a browser-based developer playground where you can prototype and build AI applications using the Gemini family of multimodal models. Think of it as a workshop. You don't need a computer science degree to start building, but it gives you direct access to raw model parameters that standard chatbots hide.
Google AI Studio combines model experimentation with application development. Its Playground helps users test prompts and model settings, while Build Mode generates and modifies an application's code. The distinction matters: a successful model response demonstrates one interaction, whereas a working application also needs reliable interfaces, data handling, permissions, error recovery, and deployment.
Google AI Studio connects experimentation with implementation: explore what a model can do, build an application around that capability, and test whether the complete system behaves reliably.
The Three Main Workspaces
- Playground: Experiment with prompts, supported media inputs, system instructions, and model settings. Use Get code to obtain an API example for a tested interaction.
- Build Mode: Describe an application, review the generated implementation, and refine it through conversation or direct code changes. See Google AI Studio Build Mode for the detailed workflow.
- Stream / realtime experiences: Explore live interactions using supported audio, camera, and screen inputs. These experiences can support demonstrations, tutoring, and visual troubleshooting, but the model may misunderstand what it sees or hears.
- Google AI Studio quickstart | Google Explains prompt experimentation, Run settings, available tools, and the transition to API code.
- Gemini Live API overview | Google Documents low-latency, interactive multimodal sessions.
Essential Controls
- System instructions: Define the intended behavior, scope, tone, and response requirements. Instructions influence model behavior but do not replace application permissions or security controls.
- Temperature: Changes sampling behavior where the selected model supports it. Lower values do not guarantee identical answers, factual accuracy, or valid application data; follow the selected model's parameter guidance.
- Structured output: Request a supported JSON Schema when the application needs machine-readable results. Validate both the structure and the meaning of the returned values.
- Safety settings: Configure supported filtering categories and thresholds. Filtering does not replace application-specific moderation, access control, or testing.
- Model and tool selection: Choose capabilities appropriate to the task. Input formats, context limits, output types, tool combinations, availability, and pricing vary by model.
- Structured outputs | Google Describes schema-constrained responses and validation with supported SDKs.
Google AI Studio Build Mode
Google AI Studio Build Mode is the application's prompt-driven software development workspace. Users describe an intended experience, inspect a running preview, and ask the coding agent to implement changes across the project. It belongs to the broader category of no-code and low-code development, although the resulting application contains conventional source code that someone must maintain.
Build Mode is useful for exploring an idea before its requirements are fully settled. A teacher might prototype a visual quiz, a small business might build an inventory interface, and a developer might test an unfamiliar AI interaction. These are proposed use cases, not evidence that a generated application automatically meets production requirements.
What Build Mode creates
The current web application workflow uses React by default for the interface and supports a Node.js server runtime. Users can begin with a description, remix a gallery application, or import a project from GitHub. Native Android generation is a separate path using Kotlin and Jetpack Compose.
| Layer | Responsibility | Example |
|---|---|---|
| User interface | Presents information and collects input | An upload form, game board, dashboard, or conversation panel |
| Server logic | Validates requests and performs privileged operations | Calling an AI service without exposing its credentials |
| Persistent data | Retains information between sessions | User profiles, saved projects, or leaderboard entries |
| AI capability | Performs a selected generative or analytical task | Explaining an image, extracting fields, or generating an illustration |
| Deployment | Makes the application available outside the development preview | A hosted web service or an Android testing build |
The coding agent and the AI inside the finished application serve different purposes. The coding agent helps create software; a runtime model answers users or generates content after that software starts running. For example, a scheduling application can be built with AI assistance yet use ordinary code for conflict detection, while calling Gemini only to summarize meeting notes.
- Build apps in Google AI Studio | Google Documents project creation, previews, editing, sharing, and export.
From description to working prototype
A useful initial prompt describes the intended user, the main task, the required inputs, and the expected result. Include concrete acceptance criteria, such as what should happen when an upload is invalid or a user has no saved records. This is an application of prompt engineering to software development, where clear requirements help both the coding agent and the human reviewer.
- Define the smallest useful experience. Specify one complete user journey before requesting many secondary features.
- Identify the data. State whether the first version uses sample records, user uploads, an external service, or persistent storage.
- Define the AI's role. Explain which tasks require a model and which should use ordinary calculations or rules.
- Generate and inspect. Run the preview and check whether the application actually completes the intended task.
- Refine one behavior at a time. Describe the observed problem, the expected behavior, and a reproducible example.
- Test failure paths. Try missing inputs, unavailable services, invalid model output, and repeated submissions.
- Save a reviewed version. Keep a recoverable copy before changing architecture, permissions, or deployment settings.
A concise starting specification might read: “Build a receipt review app that extracts merchant, date, currency, and total, then lets the user correct those fields before saving.” The next request could add duplicate detection, followed by a separate request for export. This staged approach makes failures easier to locate because each change has a clear purpose and an observable result.
Editing, previews, and source control
Build Mode supports conversational changes, visual annotation of interface elements, and direct editing in its Code view. GitHub integration supports importing projects and synchronizing changes in both directions; ZIP export provides another route to local development. These options connect browser-based prototyping with source control and more extensive engineering workflows.
A useful review practice is to inspect what changed after each substantial request. An instruction to “improve login” might alter interface text, authentication behavior, database access, and error handling at the same time. Separating these concerns into smaller changes makes regressions easier to detect and allows a working version to be restored.
Server logic, libraries, and external services
The server runtime allows an application to perform operations that should not run in a user's browser. It can use npm packages, connect to external APIs, and keep credentials in server-side configuration. Google's March 2026 announcement also describes support for multiplayer experiences and an agent capable of coordinating changes across multiple files.
For an external service, specify the required request, response format, authentication method, and failure behavior. Ask the agent to handle timeouts and unavailable services without exposing credentials or raw internal errors. Treat unfamiliar packages and generated integration code as dependencies to review, especially when they process uploads or execute privileged operations.
- Introducing the new full-stack vibe coding experience in Google AI Studio | Ammaar Reshi and Kat Kampf, Google, March 18, 2026 Introduces the expanded coding agent, server capabilities, external packages, and connected application workflows.
Firebase, identity, and persistent data
The Firebase integration can recognize when an application needs storage or user identity and offer to configure the supporting services. With the builder's approval, it can provision Firestore and Firebase Authentication and connect them to the application. This is useful when a prototype needs to retain information after a browser refresh or distinguish one user's records from another's.
Authentication establishes who a user is; authorization determines what that user may read or change. A saved-project application should enforce ownership rules rather than merely check that someone has signed in. This is a practical data governance issue: access decisions must be enforced by the data service and server, not just by hiding buttons in the interface.
- From prompt to production: Build full-stack apps faster with Google AI Studio and Firebase | Kara Yu and Sam Phillips, Firebase, March 19, 2026 Explains the integrated provisioning workflow for storage and authentication.
- Basic Security Rules | Firebase Explains identity-based and ownership-based access rules.
Google Workspace integrations
Build Mode's full-stack documentation describes integrations with Google Workspace services, including Sheets, Docs, Drive, Gmail, Calendar, and other supported applications. Builders can request an integration in conversation or select it in the integrations panel, while the platform supplies the API wiring and a Google sign-in flow. End users authorize access to their own data; connecting a service does not grant unrestricted access to everyone's account.
An expense-review app could extract receipt fields and write approved entries to Google Sheets. A document assistant could draft a report from selected records and save it to Google Docs. For actions such as sending messages, modifying shared files, or creating calendar events, the application's design should clearly distinguish a proposed change from a completed action.
- Develop full-stack apps in Google AI Studio | Google Documents the server runtime, package support, secrets, and Google Workspace integrations.
Credentials and security boundaries
Current web projects place the Gemini API key in the server environment rather than client-side source. The Build documentation states that older applications created before May 14, 2026 are migrated to the recommended integration when their Gemini features are next modified. Exported applications still need appropriate secret configuration in their destination environment.
Keeping a key secret does not prevent someone from abusing an unprotected server endpoint. A public application also needs appropriate authentication, request validation, usage limits, and checks on which operations a user may perform. For agentic applications, treat retrieved documents and user-supplied content as untrusted inputs, especially when a prompt injection could influence a tool call.
Native Android development
The Android workflow generates native Kotlin applications with Jetpack Compose and supports browser-based testing before handoff to other tools. Google's May 2026 announcement describes device installation, Google Play internal testing integration, and export to Android Studio through downloaded code or GitHub. This provides an entry point to Android development, while specialized testing and release preparation remain important later stages.
A mobile prototype should be evaluated for permissions, offline behavior, interruptions, screen sizes, and accessibility. A camera-based assistant, for example, needs a clear response when camera permission is denied or an image cannot be analyzed. Native application support should not be interpreted as evidence that every web integration or backend feature works identically on Android.
- Build native Android apps in Google AI Studio | Emma-Louise Leavey and Mike Taylor-Cai, Android Developers, May 19, 2026 Explains native generation, testing, distribution, and development handoff.
Sharing, deployment, and costs
Sharing a development experience and publishing a hosted application are different activities. The current deployment documentation describes Cloud Run publishing and an eligible-account Starter Tier that supports up to two deployed applications without configuring a billing account. Standard deployment uses a Google Cloud project with billing enabled, and published applications can use an available custom subdomain under ai.studio.
Starter Tier eligibility is restricted, including exclusions for Workspace accounts and accounts with an active or previous paid Google Cloud billing account. Hosting allowances should not be treated as a promise that every model call, database operation, or connected service is free. Before publishing, check the actual account's eligibility, model prices, service quotas, and expected traffic.
API limits apply at the project level and depend on the selected model and usage tier. A useful operating plan includes per-user limits, bounded uploads, maximum output sizes, and a graceful response when a quota is exhausted. For an image-heavy game, caching reusable scenes and making expensive analysis optional can reduce both latency and cost.
- Deploying from Google AI Studio | Google Describes publishing, Starter Tier eligibility, standard deployment, and custom URLs.
- Rate limits | Google AI Studio Explains project-level limits and usage-dependent constraints.
When a prototype is ready for wider use
A successful preview demonstrates that an application can run under the conditions tested. It does not establish that the application protects other users' records, handles heavy traffic, or produces dependable AI responses. Verification and validation should therefore cover both conventional software behavior and the model-dependent parts of the experience.
| Area | Practical check |
|---|---|
| Functionality | Complete the main user journey and verify the result independently |
| Data access | Confirm that one user cannot read or change another user's private records |
| AI behavior | Test representative inputs, ambiguous cases, refusals, and incorrect outputs |
| Reliability | Handle service errors, retries, duplicate requests, and interrupted sessions |
| Accessibility | Test keyboard use, labels, contrast, focus order, and small screens |
| Operations | Review logs, usage limits, recovery procedures, and ownership of deployed resources |
For document understanding, test whether extracted values match the original document, not merely whether the JSON parses. For a knowledge assistant, evaluate answer support and source attribution using a representative collection of questions. For a game, test scoring and information boundaries independently of the model's narration.
Recent Developments
The March 2026 full-stack update expanded Build Mode beyond primarily client-side demonstrations, and the May 2026 Android announcement added another application target. Current documentation also describes two-way GitHub synchronization, managed Workspace connections, and expanded publishing options. Because these capabilities evolve independently, a tutorial's publication date and the current documentation should both be checked before copying its setup instructions.
Build Mode also sits alongside Google Antigravity, a development environment for more extensive coding workflows. Exporting or synchronizing a project allows teams to continue with their preferred editor, source-control process, and testing tools. The practical boundary is the work required by the application, rather than a fixed rule that every project must remain in the browser or move elsewhere.
Technical Architecture and Capabilities
Multimodal Models and Media Generation
AI Studio provides access to foundation models and tools with different combinations of text, image, audio, and video capabilities. Model families and product interfaces should not be treated as interchangeable: a model that understands an image is not necessarily the model used to generate one. Similarly, a large context window helps supply information but does not guarantee that every relevant detail will influence an answer correctly.
- Gemini text and multimodal models: Support reasoning and generation over the input types documented for each model. Pro and Flash names identify model families rather than one permanent context limit or capability set.
- Nano Banana image models: Support image generation and editing. Current documentation includes Nano Banana 2 and Nano Banana Pro, so the name should not be used solely as a synonym for the earlier Gemini 2.5 Flash Image model.
- Veo video models: Provide video-generation capabilities with model-specific duration, resolution, input, and access requirements.
- Lyria music models: Provide music-generation capabilities. Realtime music interaction and generation of complete clips are distinct workflows.
- Speech and Live API capabilities: Support selected speech-generation and interactive audio experiences. Streaming applications also need session management and controls for microphones, cameras, and interruptions.
- Nano Banana image generation | Google Documents supported image models, generation, and editing workflows.
- Video generation in the Gemini API | Google Provides the current entry point for video-generation capabilities.
- Generate music with Lyria | Google Documents music-generation models and controls.
Under the Hood: Models, Tools, and Application Code
A model's neural architecture is separate from the tools available around it. Mixture-of-experts architectures route computation through selected components, but the architecture of every model offered through AI Studio should not be assumed to be identical. For application design, the documented interface, measured performance, and supported tools are usually more useful than an unsupported assumption about internal implementation.
The Gemini API's code-execution tool can generate and run Python when enabled for a supported workflow. This can help with calculations and data transformations, but an executed program can still embody a mistaken assumption or an incorrect algorithm. It is also distinct from the Node.js server running a Build Mode application.
Grounding with Google Search retrieves external information to support responses and citations. URL context supplies content from specified web resources, while map-related capabilities serve a different purpose and should not be conflated with ordinary search grounding. Retrieved content adds evidence to a request; it does not rewrite the model's training or guarantee that the resulting answer is true.
- Code execution | Google Describes the model's Python execution tool and its supported environment.
- Grounding with Google Search | Google Explains search-supported responses and source attribution.
Examples and Use Cases
- Document extraction: Extract a specified set of fields from a document using structured output, then validate values and present uncertain fields for review.
- Personal knowledge tools: Combine selected documents with retrieval-augmented generation and source links when the application needs answers grounded in a larger collection.
- Mobile prototypes: Generate an Android interface, test permissions and screen layouts, and export the project for further development.
- Visual debugging: Share an appropriate screen or image and ask the model to explain a visible problem, then verify the suggested correction.
- Creative applications: Combine image generation, text, and a conventional interface to create storyboards, learning activities, or design experiments.
- Games and teaching tools: Use generated content and AI explanations while keeping rules, scores, and hidden information under application control.
Privacy depends on the service, account configuration, and applicable terms, not simply on whether an interface is described as a developer tool. Google's Gemini API terms distinguish data handling across service circumstances, including paid and unpaid use. Before supplying confidential material, determine which terms apply to the actual workflow and minimize unnecessary personal information.
- Gemini API Additional Terms of Service | Google Defines service conditions and data-use provisions relevant to AI Studio and API workflows.
Design a Game: Peekaboo Protocol in Google AI Studio
Peekaboo Protocol is a proposed party game in which players compete with an AI rival at reasoning about hidden things. Its three rounds explore permanence (where did it go?), completion (what is behind the cover?), and evidence (how little do you need to see?). The design demonstrates how Build Mode can combine conventional game logic with model-assisted image interpretation and explanation; it is an implementation proposal, not a published benchmark or an already tested application.
AI-Based Gaming and Occlusion
Games have used occlusion to reduce rendering work, control access to information, and create uncertainty. These uses address different problems even when they involve the same wall, curtain, or hidden object. They provide useful connections between Gaming, generative AI game development, and experiments in Minecraft-like environments.
Occlusion culling avoids rendering objects that are hidden from the camera. Game engines can use visibility information to skip work on rooms or objects that cannot contribute to the current image. A vision system faces a different challenge when it tries to infer what may exist behind the visible surfaces.
Fog of war makes incomplete information part of the rules. AlphaStar reached Grandmaster level in StarCraft II in 2019 under conditions that included constrained observations and actions. Its achievement demonstrates learning in a complex game with incomplete information, rather than universal competence at reasoning about hidden objects.
In competitive multiplayer games, hidden information is also a security concern. Riot Games' VALORANT Fog of War system restricts information sent to clients to reduce opportunities for wallhacks, while accounting for when an opponent may become visible. The transferable design principle is to keep privileged state on the server instead of sending it to the browser and merely drawing an opaque cover over it.
- AlphaStar: Grandmaster level in StarCraft II using multi-agent reinforcement learning | Google DeepMind, October 30, 2019 Describes the agent's results, observational constraints, and evaluation conditions.
- Demolishing Wallhacks with VALORANT's Fog of War | Paul Chamberlain, Riot Games, April 14, 2020 Explains information withholding as an anti-cheat mechanism.
Agents That Learned to Use Occlusion
OpenAI's 2019 hide-and-seek experiments produced strategies involving shelters, movable objects, ramps, and exploitation of the simulated environment. Agents learned through multi-agent competition with visibility-related rewards and observations that excluded objects outside the relevant view. Their policies also used memory, so the result should not be summarized as a rule that agents could act only on immediately visible information.
- Emergent tool use from multi-agent interaction | OpenAI, September 17, 2019 Describes learned strategies, observation masking, memory, training, and limitations.
Generative Game Engines and the Persistence Problem
Generative game models predict visual sequences in response to actions, raising questions about whether an object remains consistent when it leaves the screen. A conventional game can retain an explicit object record even when nothing renders it, whereas a generated sequence may drift as errors accumulate. This distinction makes visual quality and persistent game state separate evaluation targets.
- GameNGen: The 2024 research system simulated DOOM at more than 20 frames per second on a single TPU. Its results concern a specific learned environment, not arbitrary game generation.
- Oasis: The Minecraft-like generative environment became a useful example of spatial and numerical consistency problems. Looking away and returning can reveal changes that would be unexpected in a conventional game.
- Muse / WHAM: Microsoft's research investigated consistent gameplay sequences and persistence of user modifications as capabilities relevant to creative work.
- Genie 3: Google DeepMind reported interactive worlds with consistency over limited periods, while identifying important constraints on interaction duration and world accuracy.
- Genie 4: The current official page describes a research preview for trusted testers, with broader access planned through selected channels. It still lists drift in visual details and object permanence among its limitations.
These systems provide research context for Peekaboo Protocol, but they are not required dependencies of the proposed game. The implementation below uses an explicit game state and selected Gemini capabilities rather than assuming general access to a world-model API. Future extensions should distinguish a research announcement from a capability actually enabled for the builder's account.
- Diffusion Models Are Real-Time Game Engines | Dani Valevski and colleagues Presents GameNGen and its interactive DOOM simulation.
- Model as a Game: On Numerical and Spatial Consistency for Generative Games | Chen and colleagues, ICCV Workshops, 2025 Examines consistency failures and approaches to explicit logical and spatial state.
- World and Human Action Models towards gameplay ideation | Microsoft Research and collaborators, Nature, 2025 Studies consistency, diversity, and persistence in generated gameplay.
- Genie 3: A new frontier for world models | Google DeepMind, August 5, 2025 Reports interactive world generation and its limitations.
- Genie 4 | Google DeepMind Describes the current research preview, planned availability, and remaining consistency limitations.
Occlusion as a Game Mechanic
Peekaboo, shell games, hide-and-seek, stealth games, hidden-hand card games, and memory games all restrict what a player can observe. Their appeal comes partly from separating visible evidence from beliefs about the hidden state. The proposed game uses this distinction to make AI evaluation understandable through play, without claiming that a few rounds establish general intelligence or human-like perception.
What Google AI Studio Provides
Build Mode supplies the application-development environment for the proposed React interface and server logic. Image-generation and image-understanding capabilities can supply scenes and rival responses, while conventional code controls movement, masking, timing, and scoring. Optional persistent storage can retain results, but the first version can remain a small local-player experience with temporary server-side sessions.
The server should generate the exact image that each participant is permitted to see. Sending an original image to the browser and covering it with a CSS rectangle leaves the original available to inspection. The same principle applies to model requests: filenames, prompts, metadata, previous messages, and answer keys can leak information even when the attached image is correctly masked.
Rounds and Rules
| Round | Research idea | What players do | What the rival does | Scoring |
|---|---|---|---|---|
| 1. Shell Game | Object permanence and tracking | Watch tokens move and predict where a hidden token will reappear | A constant-velocity baseline predicts from visible observations; Gemini optionally narrates the result | Maximum of 0 and 100 minus miss distance expressed as a percentage of board width |
| 2. Behind the Curtain | Amodal completion | Describe an object and its attributes from a partially covered scene | Gemini receives the same covered image and submits a structured answer | A fixed 0–10 rubric compares answers with verified scene metadata; model-assisted judging is labeled and reviewable |
| 3. Peek | Active perception and limited evidence | Reveal tiles in a 6 by 6 grid and guess the object | Gemini receives only the same revealed tiles and records a guess at each step | Correct guesses earn 36 minus tiles used; compare the earliest correct guesses and record ties |
After round 3, an optional evidence map can cover patches of the fully revealed image and compare the resulting answers. This resembles a perturbation-based interpretability experiment, but a model's self-reported confidence is not necessarily a calibrated probability. The display should be labeled an exploratory sensitivity map rather than a direct view of the model's attention or proof of which pixels caused its answer.
Fairness Rules
- Keep hidden state on the server. Store originals, answer keys, and unrevealed motion state separately from client-visible data.
- Use matched observations. Give the rival the same visual evidence available to the relevant player at that step.
- Separate guessing from judging. Start an isolated guessing request without the original image, descriptive filename, generation prompt, or previous judge context.
- Validate structured responses. Use distinct schemas for guesses, scores, and narration; reject invalid ranges and handle refused or failed responses.
- Use reproducible motion. Seed the game simulation, but do not expose its seed or hidden state to the prediction baseline.
- Verify scene labels. Review generated scenes and object locations before using them as ground truth.
- Avoid timing advantages. Define whether players wait for the rival and how late or failed requests affect scoring.
- Bound cost. Limit image generation, tile evaluations, retries, and optional evidence-map requests.
- Review content. Use curated prompts and filtering, while retaining a fallback when generated content is unsuitable.
Build Prompt for AI Studio
The following prompt is a starting specification rather than a guarantee of a correct implementation. It deliberately separates model-assisted tasks from deterministic game rules and server-controlled information. Build the smallest playable version first, then inspect requests, scoring, and access boundaries before adding optional features.
Build a web game called "Peekaboo Protocol" about reasoning from partially hidden evidence. Use a React front end and a Node.js server. Support 1 to 4 local players. Keep all service credentials in server-side secrets. Start with a working game using curated sample images, then add optional image generation. Global rules - The server owns original images, verified labels, masks, answer keys, hidden motion state, and random seeds. - Send the browser and guessing model only the observations allowed at the current step. - Do not leak answers through filenames, URLs, metadata, prompts, or conversation history. - Keep guessing, judging, and narration in separate model requests. - Use task-specific structured-output schemas and validate every response. - A guess contains guess, confidence from 0 to 1, and a short explanation. - A judging result contains score from 0 to 10 and a rubric-based explanation. - Label model confidence as self-reported, not a calibrated probability. - Handle timeouts, refusals, invalid responses, duplicate submissions, and quota errors. - Add bounded retries, session request limits, and a reset action. - Use server-side seeded randomness for reproducible motion. - Store scores in application code. Model narration must not change scores. Round 1: Shell Game - Show 3 colored tokens, 2 opaque walls, and a high-contrast board. - Move tokens with defined velocities and seeded small changes in motion. - When a token becomes fully hidden, pause and collect each player's predicted exit point. - The Rival uses a constant-velocity or alpha-beta tracking baseline based only on previously visible token observations. - The Rival must not receive the random seed or the token's hidden trajectory. - Resume the simulation and reveal the actual exit point. - Score max(0, 100 - 100 * miss_distance / board_width). - Optionally ask Gemini for a brief comment using only the completed round results. Round 2: Behind the Curtain - Begin with curated scenes that have verified object labels, attributes, and bounding boxes. - Optional generated scenes must be reviewed before becoming scored questions. - The server creates a covered image by masking a selected object region. - Send only this image to the browser and to an isolated Gemini guessing request. - Ask participants to identify the hidden object and describe specified attributes. - Lock all answers before revealing the original. - Score using a documented rubric against verified metadata. - If Gemini assists with judging, label this clearly and allow a host correction. Round 3: Peek - Use an image of one verified target object, initially covered by a 6 by 6 grid. - Maintain the revealed-tile set on the server. - On each turn, create one masked image showing exactly those tiles. - Give the human and Rival the same masked image. - Record the Rival's guess without displaying it until the human has committed a guess or chosen to reveal another tile. - Record each participant's earliest correct guess. - Score correct guesses as 36 minus tiles used and record ties explicitly. - Explain that the Rival is guessing from the human-selected evidence, not choosing tiles. Optional evidence map - Offer this only after the round ends. - Cover patches in turn and compare answers and self-reported confidence with a baseline. - Label the visualization "Exploratory sensitivity map". - Explain that it does not reveal attention or prove causal importance. - Cache results and enforce an explicit request budget. Design - Use a clean, high-contrast board-game style. - Give occluders a hatched appearance. - Show predictions in amber and ground truth in green, with text labels as well. - Support phones, keyboard navigation, visible focus, and clear error messages. - Include a "How it works" panel explaining permanence, completion, and partial evidence. - Provide a developer-only inspection view of sanitized model inputs. - Do not expose secrets or hidden answer keys in that inspection view.
Building and Testing It
- Open Build Mode and generate the sample-image version before enabling paid or optional media generation.
- Play a complete game and independently check movement, scoring, turn order, ties, and reset behavior.
- Use visual annotation or precise change requests to improve the board and small-screen layout.
- Inspect browser responses and model payloads to confirm that hidden originals and answer keys are absent.
- Test the guessing and judging requests separately, including whether conversation history leaks an answer.
- Check that a failed model call produces a clear recovery path without awarding incorrect points.
- Evaluate the sensitivity map on several images and retain its uncertainty label.
- Add Firestore and sign-in only if persistent accounts or leaderboards are needed; test record ownership.
- Save a reviewed version in source control and configure request limits before public deployment.
Extensions
- Live commentary: Add spoken explanations through a suitable Live API workflow without giving the commentary model access to hidden information before the reveal.
- Camera mode: Let players submit an image after granting camera permission, with clear controls over capture, upload, retention, and deletion.
- Teaching mode: Connect each round to the discussion of tracking, completion, and perturbation-based analysis, and show examples where a confident answer was wrong.
- Active-perception mode: Let the rival select its own next tile and compare information efficiency under an explicit, equal reveal budget.
- Multiplayer mode: Add authenticated remote sessions with server-authoritative turns and scores.
- World-model round: If an appropriate service is available to the account, compare a scene before and after looking away, recording object changes rather than assuming persistence.
Learning Resources
Additional Viewing
Google AI Studio is Way Underrated (Free Course) is a walkthrough attributed to Paul J Lipsky covering Playground, media generation, the app gallery, and prompt-driven building. It complements the introductory workflow sections, although interface details and model availability should be checked against current documentation.
Google AI Studio In 26 Minutes is retained from the original page as an introductory resource. Use it alongside the current quickstart, especially where older demonstrations differ from today's model settings or development workflow.
Master NEW Google AI Studio in 23 Minutes is Ali H. Salem's 23-minute, 55-second walkthrough of building, media generation, chat, and streaming. Published in October 2025, it provides useful interface context but predates the full-stack and Android updates discussed above.
Google AI Studio Build: upgraded agent, full stack runtime & Firebase support is an official Google for Developers presentation featuring Ammaar Reshi. It directly supports the Build Mode discussion of coordinated code changes, backend services, package installation, and Cloud Run deployment.
Build next-gen AI experiences with Google AI Studio and Google Antigravity is a Google I/O 2026 session featuring Joana Carrasqueira and Anshul Ramachandran. It explains the transition from rapid exploration to more extensive development, including code export, multi-file implementation, and browser testing.