Loop Engineering at Three Agents: What yetone's Magpie Workflow Says About Running Claude Opus 5.5 Unattended

The most interesting thing about yetone's setup is not the model. It is the number three. The maintainer of Magpie — a local gateway that lets coding agents run against whatever model you point them at — described his own maintenance workflow on X on 2026-10-13: Claude Code, driven by A​nthropic's Claude Opus 5.5, with three /loop tasks running at once, each one watching a different surface — GitHub issues and pull requests, the Discord community, and feedback arriving on X — and fixing what it finds. Loop engineering, the practice of keeping an agent cycling instead of prompting it turn by turn, was the subject of a lot of talk this year. What makes this example worth reading is that it comes with an org chart.

Claude Opus 5.5 is not new. A​nthropic shipped it on 2026-09-22, three weeks ago, at $4 per million input tokens and $20 per million output tokens. This is not a launch story. It is a story about what the model's defaults imply for anyone trying to copy a three-agent maintenance loop — and about which parts of that loop break in ways the tutorials do not mention.

What is actually in the workflow

The signal is short, so it is worth being precise about what is being claimed and what is not. yetone runs three concurrent /loop tasks in Claude Code on Opus 5.5. One watches the repository — issues and pull requests. One watches Discord. One watches X. The agent fixes what it judges worth fixing, in the loop, without a human dispatching each turn. The pattern he automated is the one most maintainers do badly: triage. Not the coding. The reading, sorting, deduplicating and answering that eats an hour a day.

The phrase loop engineering is load-bearing here. A loop is not an agent doing a task; it is a session that keeps coming back to a task on a schedule it chooses, with the state of the last iteration still in front of it. That distinction is where most homegrown versions fall apart, and it is exactly where the tooling has moved in the past six weeks.

What Claude Code's /loop actually does in October 2026

If you have not read the current documentation, the version you remember is probably wrong, because /loop changed shape while loop engineering was trending.

A bare /loop no longer wants you to specify an interval. Omit it, and Claude picks one dynamically — between one minute and one hour — based on what it observed in the previous iteration. It waits briefly while a build is finishing or a pull request is active, and waits much longer when nothing is pending. The chosen delay and the reason for it are printed at the end of each iteration, so you can see the loop's own reasoning about its cadence. Supply an interval instead — /loop 5m check the deploy — and you get a fixed cron schedule.

Omit the prompt too, and you get a built-in maintenance prompt that works through three things in order, every iteration:

• Continue any unfinished work from the conversation.

• Tend to the current branch's pull request — review comments, failed CI runs, merge conflicts.

• Run cleanup passes such as bug hunts or simplification when nothing else is pending.

You can replace that default with your own instructions by writing a loop.md — at .claude/loop.md for a project, or ~/.claude/loop.md for every project that does not define its own. Edits take effect on the next iteration, so you can refine a running loop's instructions without restarting it. The file is truncated past 25,000 bytes, which is more than enough room for triage rules.

That mechanism is the load-bearing part of a three-loop setup, and it is the part the workflow diagrams usually leave out. A generic built-in maintenance prompt is not a triage policy. If you want a loop that reads GitHub issues the way your project reads GitHub issues — what counts as a duplicate, what gets a label instead of a reply, what never gets a reply — the policy has to live in loop.md, not in the prompt you typed when you started the session.

The limits that decide whether three is a number or a slogan

Three concurrent loops is where the constraints start to bite, and they are worth listing before you copy anyone's setup.

• Concurrency ceiling — a session holds up to 50 scheduled tasks at once, so three loops is nowhere near the limit. The binding constraint is not task count, it is attention: three loops mean three streams of tool calls competing for the same session.

• Expiry — recurring tasks delete themselves seven days after creation, firing once more on the way out. A maintenance loop that quietly stopped on day eight is the single most common failure mode, and it fails silently.

• Restore asymmetries — resume a session with --resume or --continue and cron-scheduled tasks come back, except the recurring ones that expired. A self-paced loop is not restored at all; you have to start it again.

• Busy-session behaviour — a task fires between turns, never mid-response. If a long agentic turn is running when a loop comes due, the fire waits. Missed intervals do not stack up; they collapse into one fire.

• Jitter — recurring tasks deliberately run late, by up to half the gap to the next run and at most 30 minutes, so a fleet of sessions does not converge on the same second. A task every ten minutes starts anywhere from on-time to five minutes late. The five-minute case is the exception: Claude Code shifts it 15 seconds early to keep each run inside the prompt-cache window.

• Machine-on requirement — loops fire only while Claude Code is running and idle. Closing the laptop stops them. There is no catch-up for the hours you were away.

That last one is the reason this workflow is a maintainer's setup rather than a platform team's. Three loops on one machine, in one session, is a way to keep a busy open-source project moving while you do something else; it is not a service.

Why this workflow is specific to Claude Opus 5.5, and not just "an agent"

Run a three-agent loop against a model without a large context window and the loops spend their day re-reading. Each iteration re-ingests the issue thread, the PR diff and the Discord history; if the window is small, that history gets summarised away and the loop's judgement degrades quietly as the session ages. Claude Opus 5.5 carries a 1M-token context window with 128K tokens of output, which is what lets a triage loop hold a real issue backlog plus a conversation plus the last few iterations at once. It is also priced at $4 / $20 per million tokens, and its cache reads at $0.20 per million — a fifth of the input price — which matters more than usual here, because a loop is the single most cache-friendly workload there is. The same system prompt, the same tool definitions, the same repo context, over and over.

The second fit is the thinking default, and it cuts the other way depending on what each loop is doing. Claude Opus 5.5 runs adaptive thinking always on, with effort defaulting to medium — one level below Claude Opus 5's default. Effort does not just change quality; it changes tool-call volume. A loop that triages issues and one that edits code want different settings, and the lowest-effort setting is also its own scheduling problem: on a self-paced loop, the model picks its own next wakeup delay, so a low-effort triage loop and a high-effort fixing loop will pace themselves differently against the same repository. There is no setting that makes them agree. The point is to know which is which, because the pacing difference is the thing you will see first.

If you want to run the loop and the fixer against different vendors' models — triage on something cheap, fixes on Claude Opus 5.5 — that is a routing decision rather than a Claude Code one, and it is the reason a gateway sits in front of the session.

Trying this without betting production on it

The reasonable objection to a three-loop setup is that it puts an autonomous agent in front of your users' issues on the first afternoon. The loop is going to comment. It is going to close things. The honest way to adopt this is to run one loop in dry-run mode for a week against a read-only GitHub token and see whether its triage judgements match the ones you made by hand — and, separately, to route the model itself somewhere you can measure it before you commit.

On OrcaRouter, anthropic/claude-opus-5.5 is served at A​nthropic's list price with no markup added, from a single endpoint that speaks both the OpenAI-compatible and the A​nthropic Messages shapes — so a Claude Code session and a script that talks to the same model do not need two integrations. A​nthropic published its own $4 / $20 pricing on 2026-09-22; if that list price moves, a pass-through gateway moves with it the same day rather than on the next billing cycle, which is the version of this you want when you are sizing a loop that could run for months. Automatic failover across providers covers the case the documentation warns about and nobody tests: the loop does not stop because one upstream returned a 429 at three in the morning. Model fusion and the routing DSL matter less here — a triage loop wants one model, consistently, because consistency is what makes its judgements reviewable.

What to do with the number three

Loop engineering's reputation problem is that most of what got demonstrated this year was one loop running one narrow job in a demo. yetone's setup is interesting because it is three loops over three different inputs — the repository, the chat community, the public timeline — which is the shape of the actual job a maintainer does not have time for. It is also the shape that exposes every constraint above: expiry, jitter, restore, pacing, and the fact that the loops only run while the machine is on.

The transferable part is not the count. It is that each loop got its own surface, its own policy in loop.md, and its own reason to wake up — and that the person running it could tell, from the iteration log, why each loop chose the delay it chose. That is a setup you can actually audit a week later. Which, given that every one of these loops expires on day eight, is roughly how long you have to decide whether to build it again.

Worth saying plainly: this is one practitioner's setup, described by its author on X, not vendor-recommended guidance. A​nthropic's documentation for Claude Opus 5.5 and Claude Code's /loop tells you what the tools do. It does not tell you that three is the right number, and neither does anyone else yet.

When the triage loop and the fixing loop want different models: Run the loop and the fixer through one endpoint serves Claude Opus 5.5 at A​nthropic's list price from a single endpoint that speaks both the OpenAI-compatible and the A​nthropic Messages shapes.

Model choices like this one are also where the failure modes show up: the documented AI incidents and agent failures behind models in this class are collected in the OrcaRouter AI Incident Archive , where each entry carries its own sources, severity, confidence grade and disputed flag.