Skip to content
Kyber

Runtimes

Kyber supports two agent runtimes: Claude Code and Codex. Both run inside the standard Kyber agent pod, use whole-disk persistence, receive inbound work through Kyber’s signed dispatch path, and expose the same lifecycle actions. You pick the runtime per agent.

Use the subscription you already have

Section titled “Use the subscription you already have”

Claude Code agents sign in with your Claude subscription, and Codex agents with your ChatGPT subscription, instead of paying per token. API keys work too.

For Codex, subscription login is the default. After you create a Codex agent, its pod starts a device login and the agent detail page shows the resulting URL and device code. You complete the login with your ChatGPT account. The refreshed credential is kept alive across pod replacements, so the login stays active for as long as Codex and OpenAI allow. If credentials ever become invalid, the agent enters NeedsAuth and a Start device login action on the agent detail page runs the same flow again.

Codex also supports an explicit OpenAI API key mode, chosen at creation time.

Adopting new versions and models

Section titled “Adopting new versions and models”

The control plane runs a detection poller that periodically queries the npm registry for newly released Claude Code and Codex versions, for new public harness versions. The console’s harness version pickers read from that feed, so you can adopt a new version with no Kyber code change and no rebuild. Model choices work differently: the change-model picker on an agent’s page reads the model catalog that agent’s own authenticated runtime reports, for both runtimes, so it shows what your subscription actually offers; a freshly created agent’s list fills in once its runtime has reported. Detection failures are handled softly: the last known list keeps serving, and agents are never disrupted by a detection outage.

Claude’s authenticated model catalog reports authoritative context windows. Codex’s active session reports its context window separately from the catalog.

Version pinning is deliberate. Codex’s startup self-update check is disabled because Kyber centrally manages the pinned harness; a Set harness version action upgrades or downgrades explicitly, and the Settings surface sets the fleet-wide defaults new agents inherit. Agents keep their identity, memory, and disk across a runtime change, because those live in whole-pod persistence and identity repos.

Runtime capabilities

Section titled “Runtime capabilities”

Both runtimes integrate through Kyber’s versioned harness contract; the conformance guide records verified behavior and remaining exceptions. Kyber reports observed support for receipt-backed task dispatch, fresh sessions, cancellation, and scheduled-job controls. A supported runtime name alone does not prove a feature is available: missing or stale observations make dependent capabilities unavailable until the integration is healthy again.

Learn more

Section titled “Learn more”