// the find
huangruiteng/loopx
Lightweight loop engineering state kernel for long-running AI agent teams. Agent-loop agnostic across Codex, Claude Code, and other coding agents, with durable goals, quota-aware auto-wake, executable todos, evidence logs, and verifiable handoffs.
LoopX is a local-first state kernel for managing long-running AI agent work across multiple sessions and runtimes (Codex, Claude Code, Cursor, etc.). It handles goal persistence, todo ownership/leasing, quota-aware scheduling, human gate management, and evidence logging so multi-day agent tasks don't lose context between runs. It's aimed at developers running agents on real engineering tasks who've hit the wall of agents losing state between sessions.
- Zero external runtime dependencies - pure Python stdlib, local file-based state means no cloud signup, no API keys for the control plane itself, and no vendor lock-in for state management.
- The quota/scheduler primitive is genuinely useful: `loopx quota should-run` gives a yes/no plus a scheduler hint, so you can bolt this onto any cron or automation without reimplementing rate limiting and back-off logic.
- Agent-agnostic design is real, not aspirational - the core tick (quota check, claim, update, refresh, spend) works as shell commands, so any agent runtime that can exec a subprocess can integrate without SDK dependency.
- Incident archive in docs/archive/incidents/ with dated post-mortems is unusually honest for a v0.4 project - shows the team is actually running this on real work and documenting failures publicly.
- The state substrate is local files (`.loopx/`, `ACTIVE_GOAL_STATE.md`) with no built-in sync or conflict resolution, which means multi-machine or multi-agent-process scenarios require external coordination that the docs hand-wave over.
- Nearly all the 'evidence' cases are self-reported by the author or anonymous users - the '200+ hour loops' claim is elapsed wall-clock time across bounded turns, not continuous operation, and the distinction is buried in caveats most people will miss.
- The CLI surface is enormous (30+ subcommands across quota, todo, goal, heartbeat, etc.) with no clear minimal path - `loopx doctor` and `loopx status` are fine but the learning curve to actually govern a real loop correctly is steep and the getting-started guide doesn't flatten it enough.
- Python 3.11+ requirement with no PyPI package yet (install is curl-to-bash from GitHub Pages) is a friction point for adoption in environments with managed Python versions or security policies around curl-pipe installs.