Set up AI delivery

AI delivery is optional and set up in order. The AI area opens on a readiness checklist whose steps unlock one another; each is computed from live facts and shows Complete, Next step, or Not started. Two steps need your operator: a runner image to register as an environment, and a host to deploy the runner on.

Who can do this

Workspace Owners and Administrators. The AI area is hidden from other roles.

The five steps

1. Create an execution environment. Pin the container image digest and the tools that jobs run inside. Registering a runner requires an environment to schedule against. → Build a runner image, then Create an execution environment
2. Register an isolated runner. Reserve a runner identity for Codex or Claude, hand the one-time token to whoever deploys the runner, and let it check in. → Register a runner
3. Verify provider sign-in. The runner checks its own provider session on its host. Helmhive never asks you to paste a subscription credential into the browser. The step completes when a runner is active, online, and authenticated.
4. Discover available models. Runners publish the models their provider can actually use. The Models page reflects real provider and runner capabilities.
5. Choose reusable profiles. Profiles give jobs a purpose such as implementation or review while keeping the model replaceable. The step completes when an active profile maps to a model a connected runner publishes; the example profiles with Automatic model selection satisfy it as soon as a runner publishes its default model. → Configure profiles

Then bind services

This step is not on the checklist but is required. A service can be planned against only its assigned environment revision. On AI → Environments → Service assignment, pick the service and the revision and choose Save assignment. Without an assignment, planning for that service is disabled.

Verify

Run a Provider connection test from AI → Diagnostics, then a full implementation and review validation from AI → Runs. Both consume provider turns (requests against the runner’s provider subscription) and never touch a repository. See Run diagnostics.

One runner is enough to deliver changes. Independent review prefers a different provider when a second runner exists and otherwise uses the same provider in a fresh context.

Keep the picture straight

• Runner labels route work; they never grant authority.
• Provider credentials live on the runner host. The console shows only whether the login is healthy.
• Governed change work always starts a fresh provider session and receives no curated memory, whatever the selected profile says. See AI delivery model.