oh-my-pi implements which of Claude's Loop Engineering loops? 2 of 4

Wed, 08 Jul 2026 11:00:00 +0800

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 pi-coding-agent@16.3.11 package, the corresponding modules are right there:

1
2
3
4
5


dist/types/goals/runtime.d.ts
dist/types/goals/state.d.ts
dist/types/goals/tools/goal-tool.d.ts
dist/types/modes/types.d.ts # contains goalMode
dist/types/modes/interactive-mode.d.ts

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.

Loop Engineering on Svtter's Blog