WoterClip v0.3.0: Claude Code subagents run every persona

Last updated: July 21, 2026

TL;DR

WoterClip v0.3.0 dispatches each persona's work to a fresh Claude Code subagent running the model that persona's config declares. The Orchestrator triages on Haiku while the Backend implements on Opus, and every heartbeat report now carries a **Model:** line naming the model that actually did the work. Before this release, the model field was documentation. Now it's behavior.

The model field used to be a suggestion

Every WoterClip persona names its model in config.yaml:

runtime:
  model: opus        # Deep implementation needs strong reasoning
  thinking_effort: high
  max_turns: 300

Until v0.3.0, nothing read that field at runtime. A Claude Code session runs on one model, so whatever model launched the heartbeat did everything. If you ran /heartbeat from a Sonnet session, your Opus-configured backend wrote code on Sonnet – and your Haiku-configured orchestrator triaged on Sonnet too, at Sonnet prices, for label routing. The docs were honest about it ("informational; cannot switch mid-session"), but honest documentation of a no-op is still a no-op.

v0.3.0 closes the gap with the Claude Code primitive built for exactly this: the subagent.

How Claude Code subagents enforce the model

Claude Code subagents accept a per-dispatch model override, and WoterClip v0.3.0 uses exactly that. The heartbeat's Do Work step composes a dispatch prompt – the persona's SOUL.md and TOOLS.md verbatim, the issue context, an effort directive and turn budget – and launches a general-purpose subagent with the persona's runtime.model as the dispatch parameter.

The default team now runs the way its table always read:

The economics follow the shape of the work. Triage runs on every beat, so it belongs on the cheapest model. Implementation is where a strong model earns its price, and it only fires when a labeled issue reaches the front of the queue.

In capability order, the family runs Haiku, Sonnet, Opus – and above them all, Fable 5, Anthropic's most capable model. WoterClip documents the first three as runtime.model values, but the field passes straight through to the dispatch call: on a harness with Fable 5 available, model: fable dispatches like any other tier, and anywhere it's rejected, the disclosed fallback picks up the work.

Each dispatch is a fresh, memoryless subagent. No context bleeds between issues in a multi-issue run, and the subagent inherits the loop's filesystem, git credentials, and gh CLI auth – so its commits and PRs land exactly the way inline work always did.

Every report names the model that did the work

Each heartbeat report comment now includes a Model line:

**Model:** opus

When dispatch isn't available – the harness has no subagent primitive, or it rejects the model override – the line discloses the degradation instead of hiding it:

**Model:** sonnet (fallback — configured: opus)

That one line is an audit trail. Scan an issue's comment thread and you know which model produced each round of work – which matters when you're deciding whether a botched implementation was a persona problem or a model problem.

Only the work moved into the subagent

The dispatch boundary is deliberately narrow: Step 8 of the 11-step heartbeat loop – the work itself – moves into the subagent, and the loop keeps everything else. Inbox scan, issue locking, label transitions, the report comment, the heartbeat counter, and the lockfile all stay with the loop. One writer for orchestration state.

Instead of writing state, the subagent returns a structured outcome: one of five statuses (completed, in progress, blocked, triaged, decomposed) plus a work summary, commit SHAs, PR URLs, and any sub-issues created. The loop maps the status to label transitions and posts the report.

The payoff is crash-safety. A subagent that dies mid-issue can't strand an agent-working label or half-post a report, because it never had write access to either. The new decomposed status also fixes a queue subtlety: a parent issue broken into sub-issues now drops below its children in pick order, so later heartbeats work the children instead of re-picking the shell parent every beat.

Old personas learn the contract at dispatch time

Persona files written before v0.3.0 still say things like "post the heartbeat comment with commit SHAs" – and imported or hand-customized personas may say anything at all. Rather than migrate every scaffolded repo, the loop opens every dispatch prompt with a fixed preamble that supersedes the persona files for loop-owned state: never post Heartbeat-format comments, never touch agent or status labels, never create or delete the lockfile. Return the information in the structured outcome instead.

That pattern travels beyond WoterClip. When you compose a prompt from instruction files you don't control – stale scaffolds, user customizations, third-party imports – inject your contract ahead of them and state that it wins. Enforcement at dispatch time covers every file vintage; migrating files only covers the ones you knew about.

Fallback is disclosed, never silent

If the dispatch is refused at invocation time, the work runs inline on the session model and the report names both models. The issue never blocks for that reason alone – fallback is a disclosed degradation, not a failure.

A failure after execution may have begun is treated differently: that maps to a blocked outcome, because re-running the work inline could duplicate commits, PRs, or sub-issues. The discriminator is whether the subagent could already have changed something. When that's indeterminate, WoterClip treats it as blocked and names the ambiguity in the failure detail.

Upgrading to v0.3.0

No config migration. Every runtime.* field keeps its shape – the fields you already set finally do what they say. Update WoterClip from /plugin in Claude Code (or install fresh: add the wotai-dev/woterclip marketplace, then install). Already-scaffolded repos need nothing; the dispatch preamble covers persona files generated by older versions.

New to WoterClip? It's a free, MIT-licensed Claude Code plugin that turns GitHub issues into an agent queue: label an issue, run /heartbeat, and the matching persona works it and reports back. The setup walkthrough is in the product-team post, and the v0.2.0 post covers the GitHub Issues backend. The full v0.3.0 release notes are on GitHub. The release itself was built with Claude Code running Fable 5 – the commit trail carries the co-author lines.

Frequently asked questions

What is WoterClip?

WoterClip is a free, MIT-licensed Claude Code plugin for agent orchestration. GitHub issues carry persona labels, a scheduled /heartbeat picks the highest-priority issue, the matching persona does the work, and a structured comment reports back. No server, no database – markdown, YAML, and the gh CLI.

What changed in WoterClip v0.3.0?

Persona model configs are now enforced. The heartbeat dispatches each persona's work to a Claude Code subagent running the model named in runtime.model, and every report comment carries a Model line naming the model that did the work. Previously, one session model did everything.

What does runtime.model do now?

It sets the model the persona's subagent actually runs on: haiku, sonnet, or opus. The heartbeat passes it as the dispatch parameter when launching the persona's subagent. Before v0.3.0 the field was informational only.

Do I need to migrate my config for v0.3.0?

No. Every runtime field keeps its shape, and the default personas keep their models. Update the plugin and the next heartbeat dispatches on configured models. Personas scaffolded by older versions are covered at runtime by the dispatch preamble.

What happens if my environment can't run subagents?

The work runs inline on the session model, and the report comment names both the configured and the actual model. Fallback is a disclosed degradation, never a silent one, and an issue is never blocked just because dispatch was unavailable.

How do I know which model did the work on an issue?

Read the heartbeat report comment: every one carries a Model line. The value comes from the loop's own dispatch parameter (or the session model on fallback), not the subagent's self-report, so it's authoritative.

Why does the loop post the report instead of the persona?

Single-writer state. The loop owns labels, report comments, the heartbeat counter, and the lockfile; the subagent returns a structured outcome. A subagent crash can't strand an agent-working label or half-post a report, because it never had write access to them.

Which models can a WoterClip persona use?

Documented tiers: haiku, sonnet, and opus. In capability order the family runs Haiku, Sonnet, Opus, then Fable 5 at the top. The field passes through to the dispatch call, so a Fable-capable harness can run a persona on it; rejected models fall back with disclosure. Defaults: Orchestrator on Haiku, Backend on Opus.

Does a persona subagent share context between issues?

No. Every dispatch is a fresh, memoryless subagent instance. In a multi-issue heartbeat run, nothing bleeds between issues – each persona sees only the issue context the loop composed for it.

Is WoterClip free?

Yes. WoterClip is MIT-licensed and free on GitHub. The engine ships with four personas (Orchestrator, CEO, Backend, Frontend); the Product Execution persona pack is a separate pay-what-you-want add-on.

WoterClip lives at https://wotai.co/products/woterclip and on GitHub. If you build with Claude Code and want workflow breakdowns like this one as they ship, subscribe to the newsletter or join 760+ builders in the Skool community.

P.S. The next release tackles the follow-ups this one scoped out: teaching /persona-create and /persona-import to generate outcome-contract personas from the start, and aligning the standalone orchestrator agent with the same single-writer rule.