Praxist: a persistent research loop for projects that already run

The gap Praxist targets: research on a project that already runs

Most agent tooling assumes the hard part is writing code. Praxist assumes the hard part is deciding what to try next, and that you already have something executable to try it on. The README frames the intended situation directly: use it when a project already runs and its objective is measurable, but the best path forward is still unknown. That is a narrower claim than "autonomous AI researcher", and it is the more useful one, because it tells you what disqualifies you. If your objective cannot be turned into a number a script can compute, the system has nothing to rank. If nothing runs yet, there is no baseline to verify and no evaluator to validate. The README states that Praxist contains no task-specific scientific assumptions, and that the task remains the single source of truth for what should be tested and what counts as valid evidence. That division is the whole design: Praxist owns orchestration, lifecycle, evidence protocols, replay, scheduling and extension interfaces; the task project owns the objective, the executable code, the evaluator, the metrics, the baselines, the prompts, the roles and the domain constraints. The audience is therefore a specific one: research and ML engineers who have a training script, a benchmark harness or a simulation, plus a metric, and who want a machine to explore the space around it without losing track of which candidate produced which number.

How the loop works: peers, generations, evidence lanes

The mechanism the README describes has four moving parts. Parallel research peers explore competing hypotheses and implementations concurrently, so the search is breadth-first across candidates rather than a single chain of edits. Multi-generation synthesis carries useful evidence and strategy from one generation into the next, which is what makes this a persistent process rather than a sequence of disconnected prompts. Durable evidence lanes preserve candidates through what the README names incubator, frontier and Gems state, so a promising candidate that loses an early comparison is not simply deleted. Multi-metric evaluation ranks task-defined evidence, including Pareto-optimal tradeoffs, which matters because most real research has more than one number that must not regress. Around those sit two optional exploration policies: Quality-Diversity, documented under docs/guides/qdig-cohort-allocator.md, and the optional Deep Innovation Gate, documented under docs/guides/deep-innovation-gate.md. The README's phrasing is that QD and DIG maintain diversity "without forcing one exploration policy", which is a design commitment worth noting: the system does not pick your search strategy for you. Central resource scheduling adapts experiment admission to observed resource pressure, and resume, replay and monitoring exist so a long run stays inspectable and recoverable. Plugin boundaries are declared for runtimes, providers, tools, budgets and workflows. What the README does not describe is the scheduling policy itself, or how evidence maturity is scored. Those details live in the documentation site and the arXiv paper the README links, not on the repository front page.

Installing Praxist and running the takeover on a real project

The README gives a single pip command that installs the runtime integrations and then runs the first-use wizard. The extras matter: agents pulls in the Claude Agent SDK and MCP, codex pulls in openai-codex and codex-relay. Python 3.11 or newer is required by pyproject.toml.

python3 -m pip install --index-url https://pypi.org/simple "praxist[agents,codex]" && praxist setup --interactive --install-skills codex

The wizard, in the README's words, covers the Fair Source License, User Agreement, privacy, runtime profile, masked credentials, Codex skills, writable examples and readiness checks. It does not select a research project or launch a run. Expect to answer questions about licence acceptance and credentials before anything else happens; if you are evaluating Praxist for a team, that is the point at which procurement questions surface.

The README recommends Codex as the operating interface and says Praxist is not a replacement for it. After installation you open Codex in the root of an already runnable project and invoke the takeover skill:

$praxist-takeover

The takeover skill inspects readiness, creates or repairs the task harness, validates its evaluator and evidence contract, and launches the run once the required gates pass. The README's example brief asks for the baseline and its evaluation path to be verified before anything changes, then names a primary metric and direction, key constraints, a peer count, a generation count, a time or cost budget, and explicit switches for literature search, QD and generation-zero DIG. It also asks for a separate task harness with explicit metric directions, baseline provenance, protocol-integrity checks, evidence maturity rules and justified retention lanes. That brief is the real interface. A vague one produces a vague plan.

Once a run exists, the README lists the operational commands:

praxist status --json
praxist --monitor --latest
praxist stop <run_id>
praxist resume <run_dir>

One detail worth internalising before you start: the README states that Ctrl-C closes only the monitor and does not stop the research run. If you assume otherwise, you will leave compute running. The README also lists praxist examples list and praxist examples instal, and the repository ships examples/rocket_booster_recovery and examples/rocket_booster_recovery_rust as worked task projects.

Where Praxist is the wrong tool

The strongest constraint is the one the README states as a precondition: the objective must be measurable and the project must already run. There is no documented path for exploratory work where you do not yet know what to measure, and no documented path for a codebase that has never executed successfully. The evaluator is the load-bearing element, and the README does not describe what happens when an evaluator is subtly wrong. A task harness that ranks candidates against a broken metric will optimise the metric, and the evidence lanes will preserve the resulting candidates as though they were meaningful. Protocol-integrity checks and evidence maturity rules are named as parts of the harness, but the README does not document how they detect a mis-specified evaluator, so that validation is on you.

A second boundary is the interface. Praxist is not a chat product. The README is explicit that Codex remains the interactive agent that understands your project and communicates with you, while Praxist adds the persistent loop. If your team wants a conversational assistant, this is the wrong layer to adopt.

A third is operational. Long-running research consumes budget and compute, and the README's own guidance points toward open-source model APIs with a high observed cache-hit rate for sustained work, which implies that cost behaviour depends on your provider choice rather than on Praxist alone. The README does not document rollback semantics for a completed generation, nor does it describe how to undo a task harness that was built incorrectly; the repair path it names is the takeover skill and the task-initialization skills, not a revert command.

Praxist versus a plain agent loop in Codex

The honest alternative is not another research framework. It is Codex or Claude Code on its own, with you driving. In that setup the agent edits files, runs your script, reads the number and tries again, and you keep the plan in your head or in a markdown file. The difference in approach is where state lives. A plain agent loop keeps state in the conversation window, which means a candidate that looked promising forty turns ago is only recoverable if it is still in context or committed to disk. Praxist externalises that state into evidence lanes with named retention stages, into a task harness that owns the evaluator and baseline provenance, and into a generation boundary that synthesises across rounds. It also parallelises peers, which a single conversation does not do. The cost of that structure is setup: a plain loop starts immediately, while Praxist requires a runnable project, a computable metric, a harness with validated evaluator and evidence contracts, and a brief that specifies peers, generations and budget. For a one-off question, the plain loop wins on time to first result. For a search that will run for days across many candidates and must remain auditable afterwards, the harness is the point.

Maintenance, licence and what the repository does not declare

The last push to the default branch was on 2026-09-15, the day before this review, and the repository is not archived, so the project is being worked on right now. That is a statement about commit activity, not about stability. There are no releases retrieved for this repository, and pyproject.toml records version 0.5.0, which is pre-1.0. Expect interface movement: the skills table, the CLI verbs and the task harness contract are all things a 0.x project can change between minor versions. The dependencies are pinned unevenly, which tells you something about where the authors expect breakage. In the agents extra, claude-agent-sdk is pinned exactly at 0.2.136, while anthropic, openai, httpx, requests and the document-parsing libraries use lower bounds. In codex, openai-codex is pinned at 0.147.0 and codex-relay at 0.5.5. The base install is deliberately thin: pyyaml, jinja2 and pydantic only. That means an upgrade can pull a newer agent SDK or model client without warning unless you pin the extras yourself.

On licensing: pyproject.toml declares the license as a file, LICENSE.md, and the repository metadata carries no SPDX identifier. The README's setup wizard is described as covering the Fair Source License and a User Agreement. Fair Source is not an OSI-approved open source licence, and the terms that matter for a company are in LICENSE.md and the User Agreement, not in the README. Nothing here is legal advice; read the file and have counsel read it if you intend to build a product on top of Praxist. The project also ships a praxist-uninstall script and a praxist-retention entry point, and there is a product-usage server extra with alembic, fastapi, psycopg, sqlalchemy and uvicorn, which suggests telemetry or usage collection is part of the product. The README does not document what that server collects. Verify it against your own data-handling rules before you point Praxist at proprietary research.

Editorial conclusion

Adopt Praxist when you already have an executable project, a metric that can be computed automatically, and a willingness to let a separate task harness own the evaluator, baselines and evidence rules. Do not adopt it when the objective is not measurable, when there is no runnable baseline to verify, or when you want a chat interface to do the reasoning for you: Praxist is explicit that Codex remains the interactive agent and Praxist adds the loop. Before committing compute, verify three things in this order: that the takeover skill accepts your evaluator and evidence contract, that the task harness it builds records metric directions and baseline provenance as the brief requires, and that praxist status --json reports the run you think you started. The pyproject.toml records version 0.5.0 under a license file whose SPDX identifier is not declared, so read LICENSE.md before you ship anything built on it.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. sapientinc/PRAXIST on GitHub