Configure profiles and models
A profile gives an AI job a purpose and a configuration: instructions, provider model mappings, reasoning effort, tool and output policy, session continuity, memory scope, and routing labels. Every job keeps the exact profile revision it started with.
Example profiles
Section titled “Example profiles”New workspaces receive six editable examples, marked Example: Implement change, Review pull request, Plan change, Investigate incident, Infrastructure change, and Summarize. They are ordinary profiles, not privileged identities, and map to Codex and Claude with no pinned model.
Create a profile
Section titled “Create a profile”Choose Create profile, enter a Name and pick a Purpose (assist, implementation, review, planning, investigation, infrastructure, or summarization), then Create profile. The editor opens with the purpose’s defaults; everything else is edited there. Governed changes use the planning, implementation, and review purposes; assist is the read-only purpose behind connection tests and contextual questions.
Edit a profile
Section titled “Edit a profile”- Description and Instructions. Repository instructions and the runner sandbox remain authoritative over profile instructions.
- Provider routing. One mapping per provider (Codex, Claude, or Hermes when its adapter is installed). Helmhive prefers the first enabled provider; review uses the first different provider when available. Per provider, pick a Primary model (or Automatic, the runner default, which is enough for readiness), a Reasoning effort, and optional Fallback model IDs tried in order.
- Advanced execution policy. Tool policy (Read only, Workspace write, Infrastructure; review profiles are always read-only), Output (Text or Structured), Session (Fresh, Resume, Fork), Memory (None, Workspace, Service), and Required runner labels.
Save revision creates an immutable revision. Changing the purpose resets the configuration to that purpose’s defaults while keeping instructions and provider mappings.
Archive removes a profile from future selection; jobs already pinned to a revision keep it.
Models
Section titled “Models”The Models page lists what authenticated runners actually publish, grouped by provider, with the default model, the runners advertising each one, and the reasoning levels supported. It has no edit controls: a model appears when a runner reports it. Scheduling rejects an explicit model no compatible runner advertises.
What a profile cannot do
Section titled “What a profile cannot do”A profile narrows an immutable job envelope; it never expands it. Required capabilities and labels are added to the envelope’s, not subtracted from it. Governed change planning, implementation, and review override session continuity to fresh and memory to none whatever the profile says.
See AI delivery model.