Runtimes

spec.runtime picks the coding-agent CLI the operator runs in the pod and the image it pulls. Each pairs a model with a platform-managed provider, so no per-agent key is needed.

Runtime Configuration

Which provider entry a runtime resolves its credentials from, as implemented today:

Switching runtimes

One ready-to-apply manifest per runtime. Only runtime, model, and provider change between them — the rest of the Agent shape is identical. These mirror examples/agents/ in the source tree, so what you copy here is what ships:

ClaudeCodeanthropicCodexopenaiGeminigeminiPiany providerOpenCodezhipu

●claudecode.yaml· yaml

copy

1apiVersion: autonomic.sh/v1alpha1
2kind: Agent
3metadata:
4  name: claudecode-agent
5spec:
6  runtime: ClaudeCode
7  mode: supervised
8  phase: Active
9  goal:
10    inline: |
11      Implement issues labelled good-first-issue in the billing service.
12      Add a test for every behaviour change and open a draft PR.
13  model:
14    name: claude-opus-4-8
15    provider: anthropic
16  provider:
17    type: anthropic
18    authMode: apiKey
19  bootstrap:
20    skills:
21      - write-tests

Pinning images

Each runtime tracks a published image tag. By default an agent pod pulls the version the operator ships with, which moves as runtimes are updated. Under Settings a tenant can pin a specific tag per runtime — the pin is delivered to connected operators on handshake and pushed live when you save, so pods created afterwards use it.