Decide whether you need durable agent state
LoopX addresses a specific problem: carrying a goal, its decisions and its evidence into the next agent session. The current README describes a local-first control plane shared across agent runtimes. Your runtime supplies the model and tools; LoopX maintains the state used to decide what can happen next.
That makes it relevant to coding and research jobs with handoffs, changing requirements or approval gates. For a short supervised task, consider whether maintaining that extra state would help enough to justify the setup. We have not measured the attention or time this adds or saves.
The README identifies the current product as LoopX 2.0 and dates its announcement to 20 October 2026. It describes a shared TypeScript control plane and research workbench. Our recorded run is from 2 October, so it cannot establish how that later release installs or behaves.
What our recorded run establishes
In our run on 2 October 2026 at commit 48895f78af3ef4a625a193fc997a96784a91a94e, the npm dependency-install step exited successfully after 8,550 ms. The harness rounds this to 9 seconds. Its dependency inventory records 94 packages and a 38 MB installation footprint. Neither figure establishes how many packages the command added or audited.
The repository scan recorded 5,466 files, approximately 1,423,660 source lines and a 94.8 MB checkout. These scan totals describe repository size; they do not measure runtime complexity or operating overhead.
Build and test steps were skipped with the reason "no script". The detector nevertheless listed test:control-plane, test:postgresql-authority-service, test:control-plane:coverage, test:dashboard:coverage, test:postgresql-authority-store and typecheck:control-plane. It also detected Python tests, a tests directory and 14 CI workflow files. The skipped default path therefore does not establish that LoopX lacks tests. No passing-test total can be attributed to our run.
npm audit recorded zero advisories, with zero in each reported severity category. The supplied record does not establish audit package coverage. That result does not demonstrate application security, host permission safety or the absence of vulnerabilities.
The recorded sandbox configuration was 3 CPUs, 8 GB of memory and image lab-node:22. The image label and detector's Node-major field do not establish an exact runtime version. This matters because the current documented minimum is Node.js 22.22.3.
This was a dependency-install observation. It did not verify a Python package installation, an installed LoopX binary, an agent connection, the dashboard, recovery after a restart or a measured workload. No new execution was performed for this correction.
Judge setup through the supported user path
The current README requires Python 3.11+ and Node.js 22.22.3+, with Node.js 24 LTS recommended. Ordinary users install the Python package from PyPI, install the workflow skills and restart their agent host. The documentation uses loopx doctor for diagnosis and loopx status to show the goal, pending decision and next todo.
From a project directory, loopx connect is documented as the preferred connection path when appropriate. Existing state should be reused. The guided goal path is for a project that needs it. Keep .loopx/ and .local/ out of Git, and keep legacy .codex/goals/ ignored until migration and readback are complete.
Host activation differs. Codex surfaces use $loopx or /skills; Claude Code uses /loopx, with its opt-in adapter and /loop path for continuation. Native Windows requires PowerShell 7. The getting-started guide says an agent needs a control hook, such as shell execution, a goal command or a scheduler, for automatic continuation. Without one, LoopX can preserve state while the operator uses manual commands.
The current README also says basic usage statistics default on after first-use disclosure. It describes a daily random-ID heartbeat and separate ID-free CLI counts, says no content is collected, and documents loopx usage-ping disable or LOOPX_USAGE_PING=0 to disable them. These are project statements, not behavior we inspected.
Check authority and migration before expanding
LoopX documents goals, claims, leases, gates and evidence as the basis for continuation. Its dashboard projects that state rather than becoming a separate authority. The README explicitly leaves dangerous permissions, publishing, production writes and final ownership with a person. Those are documented boundaries; our run did not test their enforcement.
For existing installations, the current README warns that 2.0 retires ordinary writes to unpromoted Markdown Goals. Installation does not silently convert existing state. Read the migration and recovery guidance before continuing 1.x goals.
The supplied v0.5.2 release page remains historical release evidence. Its validation totals are maintainer-reported checks for that release commit, not tests we ran and not proof about LoopX 2.0. Likewise, the supplied issue listing contains reports about leases, state and quota behavior. An issue title identifies a reported problem; it does not establish its cause or whether your installed version is affected.
Keep benchmark claims separate from this review
The README reports a 46-task study of LoopX 1.0.3 Heartbeat, Plain Codex and native Codex Goal using GPT-5.6 Sol. It reports higher mean reward for Heartbeat, while strict solves match Plain Codex at 7/46. The project states that there was one effective trial per task and mode, replacement trials and unequal runtime budgets. It explicitly rules out interpreting the study as an equal-budget efficiency result or an isolated causal estimate of LoopX's effect.
Those are project-reported results, not our benchmark. The README also labels its 200+ hour examples as elapsed loop lifetime, which includes waits and decisions rather than continuous model execution. Neither form of evidence establishes unattended production autonomy.
Choose a trial that answers your operating question
Start with one host and a disposable goal. Check installation health, the visible continuation mechanism, a blocked approval, a restart and the resulting ownership and evidence trail. These are suggested acceptance checks, not completed tests from this review.
If you are building the agent workflow itself, LangGraph's documented role is low-level orchestration for stateful agents with durable execution. If you need resilient application workflows with automatic retries, Temporal's server and supported-language workers address that layer. Neither is a drop-in replacement for LoopX's host connection commands.
How to read the scores
These are editorial assessments of the supplied evidence, not measured performance ratings. The scale is 1 for substantial documented obstacles, 2 for a limited basis to recommend, 3 for a credible option with material qualification, 4 for strong documented support with remaining limits, and 5 for unusually complete support within the assessed scope. Missing adoption or compatibility measurements cannot earn a high score.
Setup scores 3/5 because there is a documented user path but our npm step did not validate it. Documentation scores 4/5 for concrete installation, host, recovery and migration guidance; we did not execute its procedures. Community scores 3/5 because the extracts show external contribution and reporting, without measuring adoption or support responsiveness. Maturity scores 3/5 because the current product documents migration and host-specific boundaries, while our run predates 2.0.