Skip to content

Ecosystem Adoption and Derivatives

简体中文

This maintainer-observed inventory links public evidence of projects using, integrating, studying, or reimplementing LoopX. Start with workflows and integrations for concrete use; proposals and deferred adoption records work that has not become an adopted runtime.

Evidence boundary: inclusion is a factual record, not an endorsement or a production-deployment claim. A merged PR proves that code or documentation landed; a published release, bounded pilot, and open proposal prove different things. Validation results in linked reports are their authors' reports, not independent reproductions by this inventory.

ADOPTERS.md is the separate, voluntary directory where projects and users describe their own use. Its empty registration table does not mean there is no observed use: the evidence below does not depend on an owner submitting a directory entry.

1. Workflows and Integrations

  • GoTry (Danceiny) — uses LoopX goals, Codex task bindings and heartbeats for multiple development lanes. Issue #18 records setup; PR #187, merged, records delivery validation. Status: reported development-workflow use; this does not establish a LoopX dependency in the travel application's runtime.
  • mimofan (XiaomingX) — organizes UI/engine repairs through LoopX Todos. PR #738 explicitly names that workflow and is merged. Status: development-workflow evidence.
  • Meta-RLR (hk20013106) — PR #17, merged, adds a CLI/JSON maintenance boundary. LoopX owns maintenance goal/todo/evidence/monitor/replan state while research_loop owns scientific state. Status: maintenance integration merged; later auto-wake PR #26 is closed unmerged.
  • LoopX Console (xielixing) — a third-party BitFun MiniApp uses the local LoopX CLI, quota should-run and host Agent execution for GitHub issue repair. Source and installation and releases are public. Status: independently published; OpenBitFun upstream inclusion is a separate proposal below.
  • zyra (BingruL) — its packaging configuration includes an embedded LoopX runtime and CLI entry points. Status: source and packaging integration observed; deployment and sustained runtime use were not verified.
  • Hufu (Blicae8917) — PR #70, merged, adds an opt-in LoopX v0.5.2 RunOnce Consumer. The deployment provider supplies the real transport and Host invocation; issue #76 remains open for status projection. Status: bounded integration merged, companion work remains.
  • benjamin-plugins (Yidada) — PR #1, merged, adds a Codex plugin calling the official LoopX kernel. The author reports a source-checkout CLI contract smoke; PyPI installation was not verified and background scheduling remains host-owned. Status: plugin merged.
  • Adaptive-Agent-Orchestration-Protocol (YuemingHub) — PR #41, merged, registers LoopX as an optional execution-continuity provider. Issue #42's pilot report reports a bounded Linux CLI recovery/gate test; later readback does not establish ongoing adoption. Status: protocol integration and non-production pilot, not default production adoption.

2. Mechanism Borrowing

These projects explicitly credit LoopX ideas. Native implementations and accepted design documents are distinct from depending on the LoopX runtime.

  • surogates (invergent-ai) — comparison and adoption plan selects durable grants, objective budgets and evaluator memory, while retaining its own storage and runtime. PR #188, #190 and #191 are merged. Status: code-level borrowing; live PR status supersedes the plan's older table.
  • future-os (futuregene) — PR #253 and #255, merged, implement selected multi-agent and goal-frontier mechanisms in Rust with explicit LoopX references. Status: native reimplementation.
  • gptme-contrib — PR #1373, merged, credits LoopX research for public/private evidence sanitization. Status: code-level borrowing.
  • KiroCrew — PR #3229, merged, adopts durable typed gates and debit-after-writeback in its perpetual-agent RFC. It deliberately retains different wake and work-selection mechanisms. Status: design adoption, documentation only.
  • multica (LRM-Teams) — PR #2174, merged, records five LoopX-inspired collaboration principles. Status: documentation only, with no LoopX runtime change.

3. Proposals and Deferred Adoption

  • OpenBitFun (GCWing) — built-in console PR #2836 is open and replaces closed, unmerged #2382. The maintainer prioritizes beta stability before evaluating the larger feature. Status: upstream integration proposed, separate from the published third-party LoopX Console.
  • codexia — upstream PR #71 was closed unmerged after the author explained it targeted the wrong repository; downstream PR #1 remains open. Status: downstream proposal; the author explicitly reports that the CLI contract has not been checked against a live installation.
  • spoon-core — issue #285 proposes optional read-only LoopX control context before a model call. Status: open proposal.
  • GENesis-AGI — issue #2123 proposes evaluating LoopX before building a durable goal backend. Status: open evaluation request.
  • Orca — issue #12628 requests LoopX-like goal-driven iteration. Status: open user request, not maintainer acceptance or implementation evidence.
  • OpenAgentEmail — discussion #180 explores optional control-plane compatibility. The September 12 follow-up suggests a small reversible provider trial rather than critical-path adoption. That comment identifies itself as AI-authored. Status: discussion/pilot proposal.
  • Quesen — discussion #3735 led to a prepared-Effect risk-admission packet. It explicitly proposes shadow mode and preserves human authority. Status: integration packet, not a code proposal.
  • 8x8-user-edition — PR #63, merged, defers runtime adoption because of overlap with existing authority and state systems, while selecting protocol ideas. Status: runtime adoption deferred.
  • Mindthus — compare-and-absorb issue #132 is closed. Status: recorded evaluation; issue closure alone does not establish runtime adoption.
  • GovernLoop — Phase 0 capability-mapping PR #23 is closed unmerged. Status: historical evaluation proposal.
  • hartevo-desktop — issue #55 proposes a Mission Control kernel informed by Prime Agent and LoopX. Status: open design issue.
  • polyphemus — issue #89 studies LoopX primitives. Status: open research request.

4. Learning, Coverage and Collaboration

  • ai-agent-book / Understanding AI Agents (bojieli) — PR #614, merged, introduces LoopX as a concrete Loop Engineering framework. Chapter 10 cites a fixed version and preserves its experimental evidence boundary. Status: teaching material, not reader adoption statistics.
  • NAVER fe-news — the September 2026 newsletter explains LoopX and its installation path in Korean. Status: editorial coverage, not a NAVER deployment claim.
  • OpenViking / NoKV — OpenViking's README lists LoopX; NoKV's README names an active open-source collaboration. Status: public project relationships; these listings alone do not establish a runtime dependency.
  • loopx-book / loopx-book-labs (cocolord) — a bilingual, protocol-first developer book and runnable labs cover onboarding, issue-to-PR work and standalone extensions. Status: educational resources.

5. Derivatives

  • loopx-HPC (Sande33p) — PR #1 is merged in an independent fork, adding optional scientific campaigns, PBS/Slurm and MLflow integration. Status: downstream code merged; the author explicitly leaves live HPC acceptance pending.
  • foreman (needware) — PR #1 proposes a native TypeScript migration of the LoopX kernel pinned to an upstream commit. Status: open proposal, not a merged runtime migration.

Evidence Limits

  • A project's own development workflow, a packaged integration, protocol borrowing and public coverage are different relationships; do not add them together as a production-adopter count.
  • Stars, unchanged forks, automated Trending/digest posts and unrelated same-name projects are not adoption evidence.
  • Creator dogfooding and user-attributed showcases retain their own source boundaries in the Showcase catalog. For example, the MFS refactor case distinguishes publicly merged PRs from user-reported LoopX attribution.

Maintenance

  • Refresh both language versions through a pull request, checking source content, current PR merge state, replacement links and later comments. Record the date rather than treating an old label as current evidence.
  • Discovery queries include gh search code "huangruiteng/loopx", gh search issues loopx, gh search prs loopx and gh search repos loopx; review only public evidence and remove duplicate or unrelated matches.
  • Keep observed entries here; projects may voluntarily confirm their own use in ADOPTERS.md. Do not create self-attested entries on their behalf from this inventory.
  • Last reviewed: 2026-09-19. Public-source research: September 18; linked PR/issue statuses refreshed September 19.