Someone on X shared Claude’s official Loop Engineering intro post, summarizing that the article splits loops into four types. A natural follow-up question: oh-my-pi (omp), the open-source Claude Code competitor — which of those does it actually implement?
This post is not about the concept itself (the tweet and the official article already cover that). It does exactly one thing: take the locally installed omp 16.3.11 and verify each type, with evidence.
Aligning on the four types first
| # | Type | In one line |
|---|---|---|
| 1 | Single-turn Loop | The basic working method: gather context → act → check → repeat, until the task is done or a human is needed |
| 2 | Goal-oriented Loop | Given a large goal, the system iterates until it is reached (autonomous / headless mode) |
| 3 | Time-based Loop | Tasks triggered on a schedule — Claude Code’s /loop (cron-like) |
| 4 | Active Loop | Event-driven, e.g. a new Issue/PR automatically has the AI review/record it |
The answer up front: 2 of 4
| # | Type | In omp? | Key evidence |
|---|---|---|---|
| 1 | Single-turn Loop | ✅ | This is the baseline of any coding agent; omp’s core agent loop is exactly this |
| 2 | Goal-oriented Loop | ✅ | Built-in /goal command + goal mode; a full goals/ submodule ships in the package |
| 3 | Time-based Loop | ❌ | No native scheduler; it’s an open feature request |
| 4 | Active Loop | ❌ | It’s a terminal agent; no webhook / event-driven auto-trigger capability |
Evidence for each, below.
Type 1: Single-turn Loop — implemented
Nothing to argue about here. Single-turn loop is the baseline working method of every agentic coding agent: each input triggers a round of “gather context → call tools → inspect results → decide next step”, looping until the task is done or a human is needed.
omp’s own README describes its agent loop (retry loops, auto-compaction of long tool chains, etc.). This is the foundation — without it, the other three types don’t exist.
Type 2: Goal-oriented Loop — implemented (the strongest evidence)
This is a first-class feature omp explicitly has: a built-in /goal command and goal mode.
From the locally installed [email protected] package, the corresponding modules are right there:
| |
So goal mode is not a third-party plugin — it ships with omp: a dedicated runtime, persistent state, a goal tool, treated as its own run mode inside interactive mode. The corresponding official PR is literally feat: built-in /goal command for persistent autonomous goals.
The essence of this type is “iterate multiple times until a goal is met”, and omp’s /goal fits exactly: after you set a goal, it keeps driving the agent loop toward it until done (with goal-mode-specific auto-compaction along the way, so long loops don’t blow the context window).
Type 3: Time-based Loop — NOT implemented (open feature request)
This type corresponds to Claude Code’s /loop: triggering tasks on a schedule, e.g. “run this prompt every 10 minutes”.
omp has no native scheduler. This isn’t a guess — it’s an explicit feature request the community is pushing:
[FR] First-class recurring/scheduled task ("run X every N minutes") — cron-like, prior art Copilot CLI
The request itself admits:
“There is no native scheduler. The only way to get periodic, hands-free reporting today is a self-re-arming background-job chain: each cycle is sleep…”
In other words, today the only way to get scheduled looping is a workaround: a self-re-arming sleep loop you run in the background. No first-class support.
Note: there’s an omp issue mentioning
/loop(about modifying its prompt mid-loop) — that refers to the goal-mode continuation loop, not a scheduled timer. Don’t conflate them.
Type 4: Active Loop — NOT implemented
This type is event-driven: you set up an event (new Issue, new PR, webhook callback…), and when it fires it auto-triggers an agent loop, with no human in the loop.
omp is a terminal coding agent — by positioning it is not an event-driven automation server. No webhook receiver, no GitHub App auto-listening.
- The closest feature is
robomp(code review), but it’s a subagent invoked on demand inside a session, not “new PR automatically triggers it”. - The Pi ecosystem (upstream Pi, not omp) has a GitHub Action on the Marketplace for PR review, but that’s an Action wrapper, not an omp-built Active Loop.
I went through every issue-tracker hit for webhook / event-driven / auto-trigger — all false positives (autocomplete triggers, token hyperlinks, CPU overhead, etc.). None describe an event-driven auto loop.
One open item worth watching
There’s a broader issue in the repo: Add loop engineering runtime. From the name, omp seems to want to build types 3 and 4 into a fuller Loop Engineering subsystem. But it hasn’t landed yet — what’s shipped today is Type 1 + Type 2.
In one sentence
Of Claude Loop Engineering’s four loop types, oh-my-pi implements two: the baseline single-turn loop (Type 1) and the goal-oriented /goal mode (Type 2). The time-based loop (Type 3) and the event-driven active loop (Type 4) are not there yet — the former tracks to open feature request #2763, the latter still lives under the broader #3534.
Put differently: omp polishes the “a human sits at the terminal, hands it a goal, and it runs to completion” path very well, but the “no one watching, auto-running on time or on events” paths aren’t filled in yet.