A worker template is a durable identity default: it names the engine profile, default model, runner, sandbox mode, capability tags, and the worker's home repository, so creating a worker with bus workers create --template <template-ref> comes down to one decision — which template fits the job. The current catalog looks like this (columns trimmed for width):
$ bus workers template list
claude-fable-5 Claude Fable 5 Highest-capability Claude worker for long-running agents, …
claude-haiku-4-5 Claude Haiku 4.5 Fast Claude worker for cheap parallel extraction, …
claude-opus-4-8 Claude Opus 4.8 Strong Claude worker for complex agentic coding, …
claude-sonnet-5 Claude Sonnet 5 Balanced Claude worker for coding, planning, …
codex-53-spark Codex 5.3 Spark Near-instant Codex worker for small focused edits, …
codex-54-mini Codex 5.4 Mini Fast Codex worker for lighter implementation, …
codex-55 Codex 5.5 Default Codex worker for complex coding, debugging, …
codex-55-high Codex 5.5 High High-effort Codex worker for difficult root-cause analysis, …
The full listing also names each template's default model — claude-fable-5 through claude-haiku-4-5 on the Claude side, gpt-5.5, gpt-5.4-mini, and gpt-5.3-codex-spark on the Codex side — plus the runner provider (claude-appserver or codex-appserver), the workspace-write sandbox, and the capability tags the worker advertises. bus workers template show <template-ref> prints one template with its full role description; Fable 5, for example, is described as the deep-research lead that synthesizes final findings, can guide Haiku extraction and Sonnet follow-through, and expects multi-hour reasoning turns.
Engine choice stays out of the rest of the platform. Assigning tasks, sending messages, reading status and logs, and preparing Git worktrees all go through the same bus workers command surface whatever the engine. Underneath, each engine has one integration module with its own event scope: bus-integration-claude owns persistent Claude sessions and answers bus.claude.session.* requests — create, message, interrupt, status, stop — while streaming engine activity as bus.claude.session.event notifications. The Codex engine runs through Codex App Server behind the matching codex-appserver runner. Supporting a further engine means adding one integration module on the bus; the worker surface above it does not change.
Messaging is asynchronous by design. bus workers message <worker-id> --text "…" delivers the prompt to the worker's session and returns; the turn runs on the engine, and the reply lands on the worker's message thread where bus workers messages <worker-id> picks it up. No caller holds a connection open while a turn runs, which is what makes the slow end of the catalog practical: a Fable 5 worker can reason for hours over an architecture review while Spark workers answer small edits in seconds, and both report back through the same thread and bus workers status.
One capability is still engine-specific. A standing goal — set with --app-server-goal-objective when creating or messaging a worker — runs on Codex App Server workers today. Claude workers do not execute goal objectives yet, so goal-driven roles belong on Codex templates for now, and Claude workers are driven with task assignments and messages; goal support for the Claude engine is under development.
Each role can now run on the engine that suits it, on one bus, under one command surface — which is exactly what a platform operated by AI agents across the whole stack needs. The wider module documentation lives at docs.busdk.com.
