Gemini CLI v0.63 plan execution in CI: gate paid Sume calls first

When a CLI agent can execute a plan on its own with nobody watching, the safeguards have to live in the tool arguments and the credential. Gemini CLI's preview v0.63.0 adds autonomous plan execution in non-interactive mode, so a CI job that renders marketing assets should combine a read-only first pass with dry_run and max_spend_usd on the paid step.

The release page lists stable v0.62.0, preview v0.63.0 and a nightly v0.64.0 dated 2026-10-03.

Three levels of the Gemini CLI release channels

Because plan execution is in the preview channel, treat it as a build you test, not one you hand a production key.

Use scope as the first gate

Sume's hosted MCP separates visibility by credential. An OAuth session with mcp:read sees only read-only tools. Mutating and paid tools such as generate_image are hidden until the session has mcp:write, and a call to one returns insufficient_scope. An API key sees the full set.

For a CI job, that suggests two stages. Plan with a read-only credential, review the plan, and only then run a stage that holds a write-capable credential.

Use arguments as the second gate

Paid and write tools require an idempotency_key. The optional fields do the safety work.

• dry_run=true previews admission and cost without submitting a job.
• max_spend_usd is enforced only when you provide it, so provide it.
• generation_admission_preview reports balance and queue behaviour before a burst.
• A stable key per planned step means a retried step returns the original job instead of billing twice.

A plan-step contract

Give the agent a plan format where each paid step carries its own cap and key. A step might read: tool generate_image, key launch-hero-001, dry_run true, max_spend_usd 2. The first run previews. A second run, approved by a person or a policy, repeats the step with dry_run false.

The docs say ordinary single creates do not need admission theater, but expensive bursts do. A plan that fans out many calls is a burst.

After the plan runs

Plan execution ends when the agent stops, not when the render finishes. Jobs are durable, so have the pipeline record job ids and read results later.

• Use jobs_wait with batches of up to 20 ids; each call holds at most 55 seconds.
• On wait_slice_expired, repeat the wait with the same ids rather than resubmitting.
• Read jobs_result for completed jobs and keep the media.sume.com URLs.
• Fail the CI step if a job is failed or canceled, and log the request id.