1. Three updates, three engineering layers
Google lists Computer Use GA across Interactions and GenerateContent on October 30, the gemini-api CLI beta on October 27, and a request-storage default change on October 26. These affect the action interface, invocation surface and data lifecycle respectively. They are Gemini API updates; they do not establish simultaneous Gemini app or Vertex AI changes. Official release notes.
Our interpretation: choose where work runs, who executes side effects and how interrupted tasks recover before comparing model capability. Otherwise an impressive demonstration can hide an incomplete execution contract.
2. Separate proposed actions from verified outcomes
Computer Use follows a screenshot, action call, client execution and updated-screen loop. A safety_decision requesting confirmation must be handled before the corresponding acknowledgement is returned. Execution and confirmation documentation.
We recommend recording a task ID, action ID, before-and-after state and an acceptance condition. For “save a draft,” verify the draft record or expected page state. A successful click is only an intermediate event. An action explanation helps debugging but does not prove the intended change occurred. Check the current destination after each navigation as well.
3. Use a CLI as an explicit pipeline step
gemini-api is a stateless API client, distinct from interactive @google/gemini-cli. Its documentation describes schema inspection, offline dry runs and explicit interaction IDs, and recommends pinning beta versions. CLI guide.
Persist input references, output paths and job identifiers outside the terminal session. A restarted scheduler can then resume from known state instead of parsing old prose. Treat offline validation, authentication, quota and actual execution as separate checks. Passing a dry run only establishes that the request passed that offline check.
4. Local statelessness does not settle remote storage
For paid-tier projects created from October 26, Generate Content requests default to storage; older projects retain their setting. Request-level store overrides the project default. Interactions storage also affects server-side history. Logs and datasets.
Maintain separate configuration entries for local job records, remote request logs, uploaded files and business audit data. If requests are not stored, decide how the application will supply subsequent context. Use synthetic data to check that your SDK accepts the setting and that the actual request carries it. A local executable's label cannot establish the retention behavior of an entire pipeline.
5. Open weights change deployment control
Mistral released improved Large 4 weights on October 29. Its modified MIT license requires a separate commercial license for Model-as-a-Service businesses. Release announcement. The model card lists 1.05T total parameters, 52B active and 1M context, while retaining a Public Preview label. Model card.
Deployment control solves a different problem from a UI action interface. Self-hosting still needs application permissions, adapters and acceptance checks. Measure weight memory, context-cache demand, concurrency and operational cost rather than estimating hardware from active parameters alone. Vendor leaderboard claims cannot replace a workload evaluation.
6. Choose by the control surface
| Requirement | Candidate route | Acceptance evidence |
|---|---|---|
| Work across web interfaces | Computer Use plus client executor | Destination, confirmation and resulting state |
| Delegate from scripts or CI | Pinned gemini-api version | Exit status, artifacts and resumable jobs |
| Integrate a persistent service | SDK plus application state | Timeouts, storage policy and telemetry |
| Control inference deployment | Open weights and serving infrastructure | License, capacity, rollback and total cost |
This is our decision framework, not a vendor guarantee. Existing business APIs can become direct tools; reserve screen execution for steps that require an interface. This makes failure boundaries and verification costs easier to explain.
7. Accept the system using matched tasks
Select tasks with independently checkable outcomes. Fix inputs, model versions and budgets, and retain the existing implementation as a control. Include changed layouts, network interruptions, declined confirmations and background-job recovery. Test the case where an action succeeds but its response is lost: inspect real state before retrying a side effect.
Record complete-task success, incorrect side effects, human interventions, latency distributions and total cost per accepted task. A single demonstration or token price cannot answer those questions. Expand traffic only after controlled acceptance, with a recovery path for unfinished work. This article specifies that method; it does not report a completed experiment or claim production improvements.