Worker profiles

Zdev resolves worker models and effort settings from repository preferences, user preferences, and built-in defaults. This reference explains the roles and overrides. The model comparison records evidence checked on 2026-08-20; it is not a permanent ranking.

Roles

Zdev exposes five worker roles. implementer and verifier are the standard defaults. Routine and advanced implementers provide explicit implementation tiers, and the planner prepares advanced work.

• routine-implementer handles authored routine tasks: tightly specified, low-risk mechanical work. It may edit only the selected task’s exact implementation paths and collect narrow read-only evidence. It never performs final verification, coordinates lifecycle, stages, commits, or makes product decisions. Routine is never inferred or selected by default.
• implementer handles normal implementation and uses the standard profile.
• verifier independently reads the brief, task, baseline, diff, and relevant source; runs required checks; and returns PASS, REWORK, or BLOCKER. It needs careful requirement accounting, defect finding, and evidence handling. Its main risks are confirmation bias, trusting the implementer’s summary, and accepting tests as a substitute for inspecting the change.
• advanced-implementer handles authored advanced implementation and explicit advanced rework.
• planner performs read-only advanced-task planning. When omitted, it uses the selected profile’s advanced-implementer row.

The coordinator is not another worker profile. It owns task selection, user decisions, branch safety, dispatch, rework, completion, and commits. A verifier must remain a fresh, read-only worker even when both roles use the same model.

Observed evidence

These observations help choose initial defaults. They do not establish that a model will have the same quality in another harness or repository.

DeepSWE v1 uses 113 original, long-horizon tasks across 91 repositories and five languages. Its publication snapshot put GPT-5.5 at xhigh effort ahead of the other reported configurations, with every model using mini-swe-agent. Its trajectory analysis found family-specific instruction-following evidence: GPT-5.5 had the lowest rate of missed stated behaviors and GPT-5.4 was close behind, while the tested Claude configurations more often missed a parallel requirement. The self-testing evidence crossed model families instead. GPT-5.4 and Claude Opus 4.7 wrote and ran new repository tests in more than 80% of DeepSWE runs, while GPT-5.5 did so in 67%. These are observations about the tested versions, prompts, and harness, not timeless family traits. DeepSWE v1 methodology, publication snapshot, and trajectory analysis and the accompanying paper (accessed 2026-08-20).

DeepSWE v1.1 keeps those tasks but changes execution and grading. The agent now works in a natural Git environment with no future history, commits its change, and only that patch is applied and graded in a fresh verifier container. The revision also adds structured test reports, fixes dependency drift, and removes flaky tests. Its leaderboard, updated 2026-08-20, reports Claude Opus 5 at max effort at 74% and GPT-5.6 Sol at max effort at 73%. Those close scores are still results for specific configurations under DeepSWE’s harness and isolated grader, not a harness-independent ordering for zdev. DeepSWE v1.1 methodology and current results (accessed 2026-08-20).

FrontierCode measures whether maintainers would merge a change. Its criteria cover correctness, test quality, scope discipline, style, and repository standards, using tests, rubrics, and other verifiers. Version 1.1 keeps the Main and Extended sets and reports each model at its best tested reasoning effort. The exported results retain the model’s harness, so the scores are explicitly model-and-harness observations. Current published results place Opus 5 and GPT-5.6 Sol among the strong configurations, but do not isolate the model from Claude Code, Codex, or Devin scaffolding. FrontierCode leaderboard and methodology, FrontierCode 1.1 revision, and Epoch’s methodology record (accessed 2026-08-20).

Artificial Analysis Intelligence Index v4.1.1 combines agentic work, coding, science, reasoning, and knowledge evaluations; it is not a software-maintainer review score. Its current leaderboard places Claude Opus 5 and GPT-5.6 Sol in the top group, and its GPT-5.6 report says Sol led its Coding Agent Index in the Codex harness. These results support considering both models, but the aggregate rank cannot select a zdev worker independently of role and harness. Intelligence Index methodology, v4.1.1 release, and GPT-5.6 report (accessed 2026-08-20).

DeepSWE and FrontierCode exercise work close to zdev’s implementation workflow, so they provide useful evidence for these defaults. They do not establish a precise ordering: benchmark tasks, prompts, graders, effort settings, and harnesses differ, and the current releases have not all been compared under one zdev workflow.

Harness controls

• Codex supports a spawned agent’s explicit model and reasoning effort; these override the configured subagent defaults. Its current model guide describes gpt-6.1-sol as the flagship for complex coding and exposes high and higher effort settings. Codex configuration reference and Codex model guide (accessed 2026-08-20).
• Claude Code agent frontmatter accepts model and effort. A model can be an alias, a full ID, or inherit; effort supports low through max when the model supports it. Organization allowlists and provider-specific alias resolution can substitute or inherit another model with a warning. Claude Code subagents and model configuration (accessed 2026-08-20).
• OpenCode agents accept a provider/model-id. With no agent model, a subagent inherits the invoking primary agent. Extra model options, including the documented OpenAI reasoningEffort example, are provider-specific; there is no portable effort field across providers. OpenCode agent configuration (accessed 2026-08-20).
• Pi accepts --model provider/id and --thinking, with levels from off through max. Its model metadata can omit, hide, or clamp unsupported levels. Zdev’s Pi extension exposes the worker profiles and passes each resolved model and thinking level to the isolated child process. Pi CLI model options and Pi model controls (accessed 2026-08-20).
• Oh My Pi agent frontmatter accepts a prioritized model list and thinking-level. A settings override wins over frontmatter, then the parent model is the fallback. Unsupported effort is clamped, or the spawn fails when no supported level remains. Oh My Pi task-agent discovery (accessed 2026-08-20).

Built-in mappings

The normal profile uses GPT-6.1 Sol for OpenAI implementation roles. Routine work uses medium reasoning; standard implementation and Sol verification use high; advanced implementation and planning use xhigh. Task complexity selects the role within that profile. Codex’s explicit simple profile selects GPT-6 Luna for implementation and planning. A routine task alone does not select Luna.

Where a harness can use more than one provider, using a different model family for verification may reduce correlated misses. That is a zdev inference, not a benchmark result.

Harness	Routine implementer	Standard implementer	Standard verifier	Advanced implementer
Codex	gpt-6.1-sol, medium	gpt-6.1-sol, high	gpt-6.1-sol, high	gpt-6.1-sol, xhigh
Claude Code	haiku, low	claude-opus-5, low	claude-opus-5, low	claude-opus-5, high
OpenCode	openai/gpt-6.1-sol, medium	openai/gpt-6.1-sol, high	anthropic/claude-opus-5, effort inherited	openai/gpt-6.1-sol, xhigh
Pi	openai/gpt-6.1-sol, medium	openai/gpt-6.1-sol, high	anthropic/claude-opus-5, low	openai/gpt-6.1-sol, xhigh
Oh My Pi	openai/gpt-6.1-sol:medium	openai/gpt-6.1-sol:high	anthropic/claude-opus-5:low	openai/gpt-6.1-sol:xhigh

The mixed-provider rows assume both providers are configured. A project that uses one provider should override both roles rather than depend on a hidden substitution.

Editable override contract

An optional repository file, .zdev/workers.toml, overrides the built-in defaults for project-scoped integration installation. A global zdev/workers.toml under the absolute configuration home supplies user preferences and the fallback for projects without a local row. The worker file is deliberately separate from .zdev/config.toml, whose schema describes project and branch state rather than harness preferences. The exact global path rules are in Layered zdev configuration.

schema_version = 1

[codex.implementer]
model = "gpt-6.1-sol"
effort = "low"

[codex.verifier]
inherit = true

[codex.advanced-implementer]
model = "gpt-6.1-sol"
effort = "high"

[opencode.verifier]
model = "anthropic/claude-opus-5"
effort = "inherit"

Each optional table is named <harness>.<role>, using the harness names codex, claude, opencode, pi, omp, and agy and the five roles above. A table must contain either inherit = true, or both a non-empty model and an effort. Effort is one of inherit, low, medium, high, xhigh, or max. inherit as a whole table omits both controls; effort = "inherit" sets the model but omits an effort control.

The file remains at schema version 1 because the role tables are optional. Existing files that contain only implementer and verifier keep their exact whole-profile behavior.

Resolution is per harness and role:

1. A table in .zdev/workers.toml wins.
2. Otherwise a table in the global worker file wins.
3. Otherwise zdev uses the built-in mapping above.
4. If the selected row says inherit, or zdev cannot express a built-in field in that harness, the generated integration omits that field and lets the harness inherit its native value.

Named profiles use strict tables such as [profiles.advanced-max.codex.implementer]. Local named rows override global rows. A missing named role uses effective normal; a missing planner first uses that named profile’s advanced-implementer. The built-in named mappings are Codex advanced and simple, and Claude advanced, as described by zdev config profile list. Other harnesses require user-defined named rows.

Use zdev config profile list, show NAME HARNESS, and resolve HARNESS ROLE to inspect them. set NAME HARNESS ROLE MODEL EFFORT (or inherit) and unset edit one atomic row. set-default NAME and unset-default persist a choice only when explicitly requested; --global selects user scope. Resolve chooses --profile for a role before --run-profile, then the profile configured for the selected harness by optional --area, the saved local or global default, then normal, and reports the concrete value, origin, and fallback in JSON.

Harness-native policy still applies after generation. For example, a Claude Code environment override or an Oh My Pi settings override can supersede agent frontmatter. Zdev reports the settings it supplies, but cannot observe the effective runtime model.

The parser rejects an unsupported schema version, unknown harness, role, key, or effort; an empty model; inherit combined with model or effort; and a model-effort pair the target adapter cannot express. zdev skill install and zdev skill check report the file, table, and value and stop before publishing any integration files. An explicit unsupported value is never silently dropped.

Zdev can validate syntax and adapter capability without contacting a provider. It cannot promise that a model is enabled for an account. If the harness later rejects or substitutes the model, its native error or warning is authoritative; zdev performs no automatic model search. The user can set that row to inherit = true or choose an available model. Missing files and missing tables are not errors: they use the built-in row, then native inheritance where the table above records a gap.

Runtime selection

An installed integration resolves a named profile when an interaction or authorized run starts. It freezes the returned concrete model and effort for each role the run can use, so a later preference edit cannot change workers in the middle of implementation, verification, continuation, recovery, or a parallel batch. Selection uses a one-off role profile first, then a run profile, then the area’s profile for the current harness, then saved local and global defaults, then normal. This calls the existing zdev config profile resolve command; it does not rewrite configuration or reinstall an integration.

The exact request “plan next task with advanced planner” is supported by Codex and Claude Code as a read-only route. It selects and snapshots one ready task explicitly, resolves advanced only for that planner step, returns the validated plan and concrete planner settings, and stops before implementation or lifecycle and Git work. Claude’s native workflow passes the resolved model and effort to the planner call. OpenCode, Pi, and Oh My Pi use the same frozen dispatch specification. Pi passes each concrete selection to its child process; OpenCode and Oh My Pi select a matching installed profile-qualified native agent. Their zdev-plan entrypoints stop after one read-only planner.

Claude’s executable task workflows obtain one admitted dispatch specification at the start of a run. That specification contains the concrete five-role map; planning, implementation, rework, escalation, and independent verification use that frozen map even if a preference file changes later. Coordination helpers retain their fixed inexpensive model. A new workflow run resolves again and does not rewrite worker configuration or installed files.