DEV Community: Andrew

FrontierAgent Review: Apodex's Open Agent Team Harness 2026

Andrew — Sat, 12 Sep 2026 10:12:59 +0000

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

TL;DR

FrontierAgent is the open-source half of Apodex's August 2026 release: an agent runtime, a terminal TUI (frontier-agent), and a benchmark harness in one Apache-2.0 repository. It ships two workflows — a Stateful ReAct single agent and an Agent Team mode where a coordinator keeps a task board, dispatches parallel sub-agents, collects their structured reports, and synthesizes the answer. The same engine runs Apodex's published benchmarks, so you can reproduce the ReAct-vs-Agent-Team comparison on your own machine.

Key facts (verified 2026-09-12):

2,664 GitHub stars, 179 forks, 13 open issues — repo created 2026-08-22, last push 2026-09-12
Python 3.12 + uv; works against any OpenAI-compatible endpoint, not just Apodex's models
Apache 2.0 framework; companion Apodex-1.1-mini (35B MoE, Apache-2.0, built on Qwen3.5-35B-A3B, 262K context) has 9.4K+ Hugging Face downloads
Fixed task sandbox: /inputs (read-only) → /workspace → /outputs; bubblewrap or container isolation on Linux, fail-closed authorization
Approval gate, JSONL trace of every action, /revert to undo a session, --resume for saved runs
Bundled evaluation for 14 benchmarks (BrowseComp, HLE, GDPval, APEX, OfficeQA, FrontierSearchBench, ...)
Free two-week Apodex-1.1 API trial at platform.apodex.ai (limited-time as of this writing)

The short version: FrontierAgent is the most complete open agent-team harness released this summer. It is also three weeks old, and the issue tracker already shows a security-relevant bug in the Bash allow-list and a process leak on shell timeouts.

Why This Matters Now

Agent frameworks are converging on the same shape: a coordinator, a pool of sub-agents, a shared task list, and a sandbox. We have covered several this year — TrueForge, PRAXIST, Prime Agent, Hermes Agent. What is different about FrontierAgent is the claim behind it.

Apodex's position, in the Apodex 1.1 blog post (24 Aug 2026), is that task decomposition should be a trained capability of the model, not a script wrapped around it: the model decides at inference time whether to split a task, how many sub-agents to run, and when to consolidate. Their numbers: Agent Team adds 4.1 to 9.3 points over plain ReAct on the same model, and the 35B Mini in Agent Team mode reaches 27.7 on APEX-Agents vs 27.9 for Kimi K2.6, a roughly 1T-parameter model.

Those are vendor benchmarks, and two of them (FrontierFinance, FrontierScience-Research) are Apodex's own. The harness is what makes the claim checkable: it includes the runner, judges, and dataset keys Apodex used, and it accepts any OpenAI-compatible endpoint. The interesting experiment is not "does Apodex-1.1 score 38.5 on APEX" but "does Agent Team mode help my model through the same harness."

The release was covered by HPCwire/AIwire and drew a team AMA on r/LocalLLaMA, where the intended use was described as "long-horizon agentic tasks: deep research, file/code analysis, and workflows that benefit from multiple agents working and verifying in parallel."

What FrontierAgent Actually Is

Four deliberately separated layers:

frontier_agent/  generic loop, scheduling, registries, AgentBus, observers
plugins/tools/   web, shell, file, sandbox, and team tool implementations
workflows/       ReAct and Agent Team pipelines, profiles, prompts, observers
apodex/          terminal CLI/TUI, approvals, sessions, traces, and Docker path
benchmarks/      public harness plus bundled FrontierSearchBench/FrontierChallenge

The framework layer has no dependency on benchmarks; CI enforces that with a framework-only import smoke test. Practically, uv sync installs a lightweight terminal runtime without datasets or judges, and you can embed run_agent_loop in your own code without inheriting the TUI.

Mode	Best for	Execution model
`react`	focused research, repository analysis, document/file work	one stateful agent
`agent_team`	broad questions that benefit from decomposition	coordinator + task board + bounded parallel sub-agents + report collection + synthesis

The tool surface in plugins/tools/ is broader than most harnesses: bash, run_python_code, read_file/write_file/file_editor, glob_search/grep_search, web_search/web_fetch, download_file, view_image, readers and writers for PDF, DOCX, PPTX, XLSX, plus the team primitives create_subagent, assign_task, collect_reports, submit_report, stop_subagent, task_board, finalize_answer. The registry exposes only an explicit allowlist — dropping a module into plugins/tools/ does not make it agent-accessible.

The document toolchain is the tell for who this is for. Apodex's headline demos are a survival analysis from raw clinical tables, powder-XRD unit-cell refinement, and building a GROMACS simulation system from a protein structure. The harness is optimized for "here are 40 files in odd formats, produce a deliverable," not for editing a web app.

Architecture: Loop, Observers, AgentBus

The core is run_agent_loop, a domain-neutral ReAct kernel:

result = await run_agent_loop(
    system_prompt=system_prompt,
    user_message=question,
    llm=llm,
    tools=tools,
    config=loop_config,
    observers=observers,
    model_profile=model_profile,
)

Planning, terminal-tool behavior, reporter routing, and recovery live outside the kernel.

Observers are the extension point. They implement only the callbacks they need (on_tool_call, on_llm_response, on_turn_end, and so on) and return an Intervention to stop, retry, or replace content. Authorization observers must fail closed. Several shipped observers encode hard-won lessons about models looping:

Observer	Signal	Action
`DuplicateQueryRollbackObserver`	a `web_search` already ran and returned content	pops the turn and re-samples without spending a `max_turns` slot
`RepetitionGuard`	consecutive byte-identical tool calls	hint at 3, stop at `stop_after`
`TextRepetitionGuard`	near-verbatim prose across turns	hint, then stop
`NoProgressGuard`	coordinator keeps spawning/assigning with nothing coming back	owns the coordinator's spin pathology

There is also a reasoning-runaway watchdog for thinking models (reasoning_only_timeout_s 120, reasoning_only_max_tokens 16384, logical_call_timeout_s 900). It only works on the streaming path, so the anthropic, responses, and bedrock protocols ignore it.

Agent Team runs on AgentBus (task submission, messaging, report collection, cancellation, shared context) with a SpawnGuard limiting nesting depth, parallelism, and wall time. Sub-agents can search, read files, use the sandbox, and submit reports; they cannot spawn their own team unless the budget explicitly allows it. The coordinator's add_task/update_task events render live in the TUI sidebar. One footnote: the subsystem was originally called swarm, and the name survives on identifiers other code binds to (response.swarm.*, logs/swarm/, load_swarm_profile). In the code, "swarm" means Agent Team.

The Sandbox and Safety Model

Most agent frameworks hand-wave this; FrontierAgent is unusually explicit.

Path	Policy	Purpose
`/inputs`	read-only	supplied documents and benchmark inputs
`/workspace`	read-write	source checkout, extracted data, scratch
`/outputs`	controlled read-write	final persistent deliverables

File and shell tools share this one sandbox and path policy. Backends are auto (probe bubblewrap, fail with guidance if unavailable), bwrap, and container. The docs state there is no unisolated host fallback at the framework layer; network and path policies apply before execution, and authorization or sandbox failures are fail-closed. Output publication is manifest-aware — only declared publishers may write final deliverables.

The interactive terminal adds a second layer: an approval gate on writes, deletions, package installs, and risky shell commands (with a unified diff shown first), hard denials that survive --yes, and a journal backing /revert. Every action lands in a JSONL trace under <project>/.apodex/runs/<session-id>/, alongside the checkpoint, engine log, and trajectories.

Caveat for Mac users: the macOS native path is approval-gated but explicitly "not an OS sandbox" — commands run with your user's permissions. Real isolation means bubblewrap on Linux or Docker.

Getting Started

Requirements: Git, Python 3.12, uv, and an OpenAI-compatible endpoint. Docker is optional.

git clone https://github.com/ApodexAI/FrontierAgent.git
cd FrontierAgent
uv sync --python 3.12 --extra dev
cp .env.example .env

OPENAI_API_KEY=your-key
OPENAI_BASE_URL=https://your-openai-compatible-endpoint/v1
OPENAI_MODEL=your-model-name

# Optional web research tools
SERPER_API_KEY=
JINA_API_KEY=

Web search goes through Serper and page fetching through Jina Reader; without keys you get a closed-book agent. A fix merged 9 Sep (issue #34) makes the TUI warn about missing search credentials at startup instead of failing mid-run. .env.example also exposes SUMMARY_LLM_* so whole-page condensation can go to a cheaper model, and READDOC_VISION_URL for image-only PDF pages.

# Single stateful agent
uv run frontier-agent --mode react --cwd /path/to/project

# Coordinator plus parallel sub-agents, with a task
uv run frontier-agent --mode agent_team --cwd /repo \
  "Research the alternatives, verify the evidence, and write a report"

# One-shot / line mode / resume
uv run frontier-agent --mode react --cwd /repo -p "explain src/main.py"
uv run frontier-agent --mode agent_team --no-tui "compare these implementations"
uv run frontier-agent --resume

# Attach read-only inputs; auto-approve for trusted batch use
uv run frontier-agent --mode react --cwd /repo --input ~/Downloads/claim.pdf
uv run frontier-agent --cwd /repo --yes "add a --verbose flag to the CLI"

Scientific and document packages are optional in native mode; the agent installs only what a task needs into <project>/.apodex/runtime/native. Pre-built linux/amd64 and linux/arm64 images are on GHCR (docker compose run --rm agent).

Asynchronous intervention is the TUI feature people notice first: type while an agent is running and the instruction is injected at the next safe turn boundary without discarding the active run. In Agent Team mode it steers the coordinator; running sub-agents finish.

Going fully local with Apodex-1.1-mini

The mini is a 35B MoE fine-tune of Qwen3.5-35B-A3B with 262K context, published as FP16 (roughly 70 GB) plus FP8, GPTQ-Int4, NVFP4, and GGUF. Apodex's serving command:

python3 -m sglang.launch_server --model-path apodex/Apodex-1.1-mini \
  --tp 8 --host 0.0.0.0 --port 1234 --context-length 262144 \
  --tool-call-parser qwen3_coder --reasoning-parser qwen3

config/sglang/ ships templates for one RTX 4090 (24 GB), one RTX 5090 (32 GB), and a two-GPU host. Read the caveat: none of the consumer-GPU templates can load FP16 as-is — quantize first (GPTQ-Int4 is "the only format that fits" a 5090) and set SGLANG_LOCAL_MODEL_PATH. Driver/CUDA/SGLang mismatches surface late as opaque Triton errors; check the GPU compatibility matrix first.

Benchmark Evaluation

Each question runs in an isolated subprocess with resumable multi-run experiments and benchmark-specific judges:

uv sync --extra eval --extra sandbox --extra document-readers
uv run python -m benchmarks.public.runner.run_subprocess \
  --benchmark browsecomp --pipeline stateful-react-agent --profile default \
  --limit 1 --concurrency 1 --out ./results/smoke

Supported: BrowseComp, BrowseComp-ZH, xbench-DeepResearch, HLE, SuperChem, FrontierScience-Research/Olympiad, DeepSearchQA, WideSearch, FrontierSearchBench, OfficeQA, GDPval, APEX, OneMillion-Bench. GDPval uses deterministic deliverable validation only — the agentic pairwise grader is excluded, so the 78.8 GDPval figure is not reproducible from this repo alone. Agent Team parallelism multiplies with --concurrency; start at 1.

For reference, Apodex's own table has Apodex-1.1 Agent Team at 38.5 APEX-Agents / 78.8 GDPval / 56.1 HLE versus 34.4 / 69.5 / 53.2 for the same model in ReAct mode.

Community Reaction

No big Hacker News thread — the discussion happened on r/LocalLLaMA, X, and in the repo. The pattern is consistent: praise for the harness, skepticism about the model claims. Julian Goldie called it "the most complete open-source agent-team harness to ship this month" while noting the model claims "need independent verification"; explainx.ai flagged the Kimi K2.6 comparison as "a strong signal on Apodex's own benchmark suite, not yet an independently reproduced result."

The GitHub issues are the better signal, because they come from people who ran it:

#39 — Bash allow-rule bypass via command substitution. A saved Bash(git push) rule matches by string prefix without unwrapping $(...), and the rules layer downgrades CONFIRM to SAFE, so git push --force can slip past the typed-confirmation gate — the exact case the module docstring says is impossible. Reproduced on main; fix PR #42 is open.
#40 — run_shell leaks the child process on timeout on the host/native/container path (the Linux default). The caller sees TimeoutError; the child keeps mutating the workspace. Only the bwrap path reaps.
Benchmark-runner bugs, fixed fast: inverted --web/--no-web (#26, fixed 1 Sep), --limit applied before the seeded shuffle (#32, fixed 8 Sep). Still open: the FrontierChallenge open track needs a licensed ORCA runtime for one task and ships a stale checksum file (#27, #28).

Read together: a young codebase with real users, maintainers merging community fixes within days, and the bugs you expect three weeks in — including one in the safety layer.

Honest Limitations

Three weeks old, no tagged releases. You are tracking main. Open issues #39 and #40 touch exactly the pieces you trust when you pass --yes.
Research-shaped, not code-shaped. It can edit code, but there is no test-runner, git, or LSP integration; it is not competing with Claude Code or Codex on software work.
Web research needs paid keys (Serper, Jina). Otherwise closed-book.
Local model is a real GPU commitment. 35B, 4-bit export, 24-32 GB card minimum; no Ollama-style path.
Runaway watchdogs are streaming-only. Non-streaming protocols get only the post-hoc reduced-cap resample.
macOS native is not isolated. Approval-gated, journaled, revertible — but running as your user.
Partly vendor-owned benchmarks, and the GDPval agentic grader is excluded from the open harness.

Who Should Use FrontierAgent

Good fit: teams testing whether Agent Team decomposition helps their model; analysts working from piles of PDFs and spreadsheets who want an auditable, revertible local agent; runtime builders who want a reference implementation of observers, spawn guards, and a manifest-aware sandbox; self-hosters with a 24 GB+ NVIDIA card who want a fully local deep-research stack.

Bad fit: coding-agent users (Claude Code, Codex, OpenCode are better at software work); anyone who needs it fully local on a Mac; production deployment today — wait for a tagged release and the #39/#40 fixes.

FrontierAgent vs Alternatives

	FrontierAgent	GPT Researcher	Local Deep Research	PRAXIST
Primary job	file + web research deliverables	web research reports	self-hosted research, local models	ML experiment campaigns
Multi-agent	coordinator + parallel sub-agents, task board	planner + parallel researchers	no (iterative)	parallel peers across generations
Sandbox	3-dir layout, bwrap/container, fail-closed	none	Docker	project-scoped
Document I/O	PDF/DOCX/PPTX/XLSX read + write	web + local docs	web + local docs	task project defines
Eval harness	14 benchmarks bundled	no	no	MLE-bench focus
License	Apache 2.0	Apache 2.0	MIT	Fair Source 1.0

If your question is "which open framework should I copy the design from," FrontierAgent's observer contract and sandbox policy are the most carefully specified of the four. If your question is "what runs on my laptop tonight," Local Deep Research still wins.

FAQ

Does FrontierAgent require Apodex's models?
No. It needs an OpenAI-compatible chat endpoint; OPENAI_BASE_URL can point at OpenAI, OpenRouter, vLLM, SGLang, or anything else that speaks the API. Apodex-1.1-mini is the intended companion and the target of the shipped SGLang templates, but the harness is model-agnostic.

What is the difference between react and agent_team mode?
react runs one stateful agent through the research/read/write/run loop in a task-scoped sandbox. agent_team runs a coordinator that decomposes the request into a task board, dispatches bounded parallel sub-agents, collects their structured reports, and synthesizes an answer (optionally via a fast "reporter"). Apodex reports 4.1-9.3 points of lift; it also multiplies concurrent model calls.

Can I run FrontierAgent on macOS?
Yes, natively without Docker, against a hosted or reachable endpoint — ./scripts/run-macos.sh does the install. The native macOS path is approval-gated and revertible but not an OS-level sandbox; use Docker Desktop for isolation. Local SGLang serving is Linux/NVIDIA only.

How much GPU do I need for Apodex-1.1-mini?
The FP16 checkpoint is about 70 GB. The shipped templates target one 24 GB RTX 4090 or one 32 GB RTX 5090 with a 4-bit export, or two GPUs with tensor parallelism. FP8, NVFP4, and GGUF variants are on Hugging Face. Budget KV cache separately; you will cap the 262K context.

Is FrontierAgent production-ready?
Not yet. No tagged releases, and two open issues affect the safety layer: the Bash allow-rule bypass (#39) and the child-process leak on timeout (#40). Treat it as a research workbench until those close.

Does it work with Claude Code or Codex skills?
Not directly. Unlike PRAXIST, which ships as Codex/Claude Code skills, FrontierAgent is its own runtime. You can embed run_agent_loop in Python or drive it with --no-tui, but there is no MCP server or skill package in the repo as of 2026-09-12.

Verdict

FrontierAgent is the rare vendor open-source release that is more interesting than the model it ships with. The observer contract, the repetition and no-progress guards, the fixed three-directory sandbox with fail-closed authorization, the journaled /revert, and the bundled eval runner add up to a genuinely reusable reference for building an agent-team harness. Because it is endpoint-agnostic, it lets you test Apodex's central claim — trained-in decomposition beats scripted orchestration — with your own model instead of taking the benchmark table on faith.

What it is not, yet, is something to hand --yes and walk away from. Give it a tagged release and the #39/#40 fixes and it becomes the default open workbench for file-heavy research agents. Today: star it, run the smoke benchmark against your endpoint, and read docs/framework.md even if you never adopt the tool.

Rating: 4/5 — excellent architecture and documentation, model-agnostic, Apache 2.0; docked for age, open safety-layer bugs, and the GPU bar for going fully local.

Sources

ApodexAI/FrontierAgent on GitHub — README, docs/framework.md, workflows/agent_team/README.md, config/sglang/README.md, issues #26-#42
Apodex 1.1: Scaling Agentic Intelligence for Complex Work — Apodex blog, 24 Aug 2026
Apodex-1.1 technical report — arXiv
apodex/Apodex-1.1-mini — Hugging Face model card
Apodex Launches 1.1 Model for Complex Professional and Scientific Work — HPCwire/AIwire, 2 Sep 2026
r/LocalLLaMA: We're the Team Behind Apodex 1.1 — Ask Us Anything — 27 Aug 2026

PRAXIST Review: Sapient's Autonomous R&D System (6.5K Stars)

Andrew — Fri, 11 Sep 2026 10:13:57 +0000

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

TL;DR

PRAXIST is an autonomous research system from Sapient Intelligence (the Singapore/Palo Alto lab behind the Hierarchical Reasoning Model). You hand it a project that already runs and has a measurable objective; it runs parallel "research peers" that propose, implement, and evaluate competing approaches, then synthesizes the evidence into the next generation's agenda. The pitch is not "an agent that writes code" — it's a persistent research loop with an auditable lineage for every reported improvement.

Key facts (verified 2026-09-11):

6,559 GitHub stars, 624 forks, 10 open issues — repo created 2026-08-27, last push 2026-09-09
Python 3.11+, pip install "praxist[agents,codex]"; operated through Codex or Claude Code skills, or the plain praxist CLI
Fair Source License 1.0 — source-available, free under US$1M annual revenue and for academic use
Headline benchmark (arXiv 2608.25955, 26 Aug 2026): 60 medals / 49 gold on the 75-task MLE-bench at US$3,054 model spend, vs 55 / 34 gold for a Claude Code baseline on Claude Opus 4.8 at US$38,370
Runs on DeepSeek V4 Pro (the "priority 1" profile), OpenRouter, Anthropic, or a no-API-key Codex-native mode
Release-tested only on Linux; macOS is a "compatibility target"

The interesting part is the architecture claim: instead of a tree search that prunes weak branches, PRAXIST keeps a generation-layered evidence graph so later attempts can recombine mechanisms from failed lineages.

Why This Matters Now

We've covered the "AI runs your experiments" space before. Karpathy's AutoResearch is the minimalist end — 630 lines of Python, one GPU, let the agent loop overnight. Prime Agent and Hermes Agent are self-improving harnesses. PRAXIST sits at the heavyweight end: a full orchestration layer with preregistered metrics, evidence maturity rules, resource scheduling, and legal acceptance flows.

The paper's framing is the sharpest statement of the problem. From the arXiv abstract:

"Most systems treat each attempt as nearly self-contained, so logs, memories, and search trees record what happened without establishing which design element produced an improvement... Long campaigns therefore keep re-learning the same lessons."

Anyone who has run a coding agent on a long optimization task will recognize that: the agent tries the same three ideas, in a slightly different order, every session. PRAXIST's answer is to make evidence — not conversation history — the unit of memory.

It also matters who is shipping it. Sapient Intelligence made noise in 2025 with HRM, a tiny recurrent model that punched above its weight on ARC-style puzzles. A commenter in the r/LocalLLaMA thread read PRAXIST as a pivot from "better motor" to "better car body around any motor" — the same bet much of the harness ecosystem is making this year.

What PRAXIST Actually Is

PRAXIST owns orchestration, run lifecycle, evidence protocols, replay, scheduling, and plugin interfaces. Your task project owns the objective, executable code, evaluator, metrics, baselines, prompts, roles, and domain constraints — PRAXIST "contains no task-specific scientific assumptions."

Every run is driven by a task project — a directory with a task.yaml, a description.md, a roles/ folder of Markdown role contracts, audit_rules/, and an evaluations/<name>/run.py that turns a candidate into structured metrics. PRAXIST never touches your original project; run artifacts land in a separate experiments/ directory.

The three prerequisites from the README's FAQ are the whole gating logic:

The objective is measurable — at least one metric with a known direction.
The project already runs — baseline code, environment, data or simulator all work without PRAXIST.
The best path forward is unknown.

If any prerequisite is missing, PRAXIST is designed to stop and say so. It will not "silently download unspecified datasets, invent a simulator, or fabricate baseline performance." Given how often coding agents hallucinate a benchmark number to close a loop, that refusal is one of the more valuable design decisions here.

Architecture: Generations, Lanes, and the Evidence Graph

The core loop runs in generations. In each, a cohort of parallel research peers (the docs' examples use 12) each build a candidate; a task-owned evaluator scores every candidate through the same protocol; then a planning panel of Principal Investigator (PI) agents — optionally with a Chair in multi-PI mode — reads the accumulated evidence and writes the next generation's agenda.

What distinguishes it from a plain best-of-N loop:

Typed evidence graph. Evaluator outcomes become findings with provenance and lineage, not free-form logs. The press release contrasts this with "the tree-like search used by other similar systems, where each candidate inherits from one parent and weaker branches are pruned." A later peer can inherit a mechanism from a dead branch.

Frontier lanes. Candidates live in incubator, frontier, and "Gems" states. Each lane declares parent_eligible — only mature, durable lanes seed the next generation; partial, diagnostic, and "suspect" results stay visible without contaminating the parent pool. Multi-metric tasks can retain Pareto-optimal solutions.

Deep Innovation Gate (DIG). An optional pre-code reasoning phase, recommended only for generation zero. Before a peer writes anything, it maps the baseline mechanism, critiques a pool of candidate mechanisms with read-only planner tools, and commits to a selected_contract.yaml naming the intervention surface, rejected alternatives, expected metric signature, and fail-fast checks. Deviating mid-implementation requires an auditable contract_amendment.yaml.

Quality-Diversity (QD) allocation. An independent switch that spreads peers across diversity cells so the cohort doesn't collapse onto one approach.

Central resource scheduler. Experiment admission adapts to observed resource pressure, with explicit NVIDIA/CUDA UUID handling for multi-GPU boxes.

Everything is designed for resume, replay, and audit. praxist resume <run_dir> picks a run back up; Ctrl-C closes the monitor, not the research.

The Benchmark Claims

The MLE-bench numbers are why this repo hit 6.5K stars in two weeks.

System	Model	Medals (of 75)	Gold	Recorded model spend
PRAXIST	DeepSeek V4 Pro	60 (80.0%)	49	US$3,054
Claude Code baseline	Claude Opus 4.8	55 (73.3%)	34	US$38,370

Source: arXiv 2608.25955, "finalized official-grader results."

Three things to note before quoting these:

These are vendor-run evaluations. Sapient ran both arms. A Claude Code baseline is a choice of harness, and Claude Code isn't designed for multi-day research campaigns.
The cost comparison mixes model and harness. DeepSeek V4 Pro is far cheaper per token than Opus 4.8, and PRAXIST's docs favor it for "high observed cache-hit rate." The 12× cost gap is at least partly a model-pricing story. The medal gap (60 vs 55) is the cleaner signal.
The engineering case studies are partner-provided. The press release reports a rocket-landing simulation reaching 100% success within 12 hours (TRL 3), and an industrial SLAM problem where 9.37 cm of accumulated error dropped to 5.01 cm in three days. Neither the simulators nor the baselines are public; the two rocket_booster_recovery examples in the repo (Python/JAX and Rust) are the closest reproducible artifact.

The honest read: the medal count on a standardized suite is a strong result, the cost multiplier is a marketing number, and the partner stories are unverifiable.

Getting Started

The README's one-liner installs the runtime integrations and launches an interactive first-use wizard:

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

The wizard walks through Fair Source License acceptance (explicit, digest recorded), optional usage consent (nothing preselected), a runtime profile (provider + agent runtime + model + auth mode), masked API-key entry, and readiness checks. It deliberately does not pick a project or start a run. Claude Code users get a separate one-liner and invoke /praxist-takeover instead of $praxist-takeover.

Codex-native mode (no API key)

The shortest path: choose the Codex-native profile and PRAXIST uses your saved ChatGPT/Codex login. It's meant for trying things out — for sustained runs the docs steer you to a cheaper API-backed profile.

Agent-managed install

Or open codex --yolo (or claude --dangerously-skip-permissions) and ask it to "Install and configure Praxist. Follow the packaged OOBE runbook and stop after readiness checks." The agent polls praxist setup --agent-managed for JSON describing the next decision; it's forbidden from accepting the license on your behalf or asking for an API key in chat.

Takeover

Once installed, cd into a project that already runs and hand it over:

# Codex
praxist --takeover --task-path /absolute/path/to/research-project
# Claude Code
praxist --takeover --operator claude --task-path /absolute/path/to/research-project

Takeover runs Discover → Design → Verify → Launch: inspect the project, runtime, and baseline; design metrics, evidence rules, roles, and resource plans; run task tests plus praxist resolve and praxist doctor; launch a detached run. The brief matters: the README's template asks for objective, metric direction, constraints, peer and generation counts, budget, and whether launch is authorized.

Operate a running campaign with:

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

Try a bundled example first: praxist examples install rocket_booster_recovery installs a writable copy to run from.

Bundled Skills

PRAXIST ships as Agent Skills-style commands rather than a monolithic CLI:

Skill	Purpose
`praxist-takeover`	Inspect readiness, build/repair the harness, launch after gates pass
`praxist-task-initialization`	Build or repair a task harness without launching
`praxist-control`	Start, stop, resume, monitor, inspect runs
`praxist-diagnostic`	Diagnose run health, produce reports
`praxist-scientific-research`	Gather sourced literature and benchmark context

The README is explicit that PRAXIST is "not a replacement for Codex" — Codex (or Claude Code) stays the interactive agent that talks to you; PRAXIST adds the persistent loop underneath.

Community Reaction

Reception has been cooler than the star count suggests. The r/LocalLLaMA post sat at a 38% upvote ratio; the top comment was "buy an ad." Another called the "vague and 'scientific' descriptions" a possible "money pump from VC funds" and asked for something "down to earth for regular pleb" — like finding the cheapest RTX 3090 in Europe — rather than tokamak control. The most-repeated correction: it is not open source — "source available, as they write themself on their github page." The Hacker News submissions got one point each, no discussion.

Some of that is r/LocalLLaMA's allergy to enterprise press releases. But the README, docs, and paper are written in a dense, contract-heavy register ("lane-structured frontiers," "cooperative launch guard") that makes it hard to tell in five minutes whether this is for you.

The issue tracker is healthier: recent PRs added Groq, Mistral, and xAI provider plugins (#184), provider cost metering (#111), and macOS symlink fixes (#192). One open bug (#189) reports the rocket_booster_recovery example failing a canary check due to a stale hash pin — check before using it as your first run.

Honest Limitations

Source-available, not open source. Fair Source License 1.0. Free under US$1M aggregate annual revenue (affiliates included) and for academic research; above that, you negotiate with Sapient Intelligence Pte Ltd. Externally published outputs must keep the attribution "Praxist by Sapient Intelligence."
Linux-first. Release-tested only on Linux with CPython 3.11/3.12. macOS is a compatibility target. Windows isn't mentioned.
Heavy onboarding. Legal acceptance, consent, profile selection, skills registration, then a separate takeover with its own gates. For a weekend project it's overkill.
Requires a measurable objective. No evaluator, no PRAXIST. Fuzzy goals are out of scope by design.
Cost is open-ended. Twelve peers over thirty generations, each running your evaluator, adds up fast. The docs advise one or two bounded calibration runs first.
Beta. Two weeks old, 10 open issues, an example with a broken canary. Expect churn.
Vendor benchmarks only. No independent reproduction yet.

Who Should Use PRAXIST

Good fit: ML teams with a pipeline that already runs, a clear metric, and GPU budget for parallel experiments; robotics/controls/simulation groups where the objective is a simulator score; Kaggle-style competition work (literally what MLE-bench measures); academic labs, since the revenue threshold doesn't apply.

Poor fit: anyone without a working evaluator; companies over the $1M threshold who want an open-source guarantee; quick one-off optimizations (use AutoResearch or a plain Codex/Claude Code loop); macOS-only shops that need release-qualified stability today.

PRAXIST vs Alternatives

	PRAXIST	Karpathy AutoResearch	Plain Claude Code / Codex loop	AutoML (Optuna etc.)
Search space	Methods, architectures, code	Code edits in one file	Whatever you prompt	Predefined hyperparameters
Memory across attempts	Typed evidence graph, lineages	Git history + results log	Conversation / files	Trial database
Parallelism	Cohorts of peers, scheduled	Sequential, one GPU	Manual	Built-in
Audit trail	Preregistered metrics, provenance	Commit log	None by default	Trial log
License	Fair Source 1.0 (<$1M free)	MIT	Proprietary tools	Open source
Setup weight	Heavy	Trivial	Light	Light

Sapient's framing of the AutoML comparison is fair: "AutoML tunes parameters within a predefined search space. Praxist runs the full research loop."

FAQ

Is PRAXIST open source?

No. It's under the Fair Source License Agreement 1.0 — source-available. You can read, download, and modify the code; organizations under US$1M aggregate annual revenue and academic institutions can use it commercially for free. Above that, you negotiate a commercial license with Sapient Intelligence.

Do I need an API key?

Not for a first try — Codex-native mode uses your saved ChatGPT/Codex login. For sustained research, the docs recommend an API-backed profile: DeepSeek V4 Pro direct (priority 1), open models via OpenRouter, or Anthropic. Keys are entered at a masked local prompt, never in chat.

What did PRAXIST score on MLE-bench?

Per the paper (26 Aug 2026): 60 medals out of 75 tasks (80.0%), 49 gold, at US$3,054 recorded model spend on DeepSeek V4 Pro. Sapient's Claude Code baseline on Claude Opus 4.8 scored 55 medals / 34 gold at US$38,370. Vendor-run; no independent reproduction yet.

Does PRAXIST work with Claude Code?

Yes. Install with the Claude Code one-liner from the docs, then use /praxist-takeover inside Claude Code or praxist --takeover --operator claude --task-path <path> from the shell. Codex is the default and the only runtime with the no-key mode.

Does it run on macOS?

It's a "compatibility target," not a release-qualified host — only Linux on CPython 3.11/3.12 is continuously tested. Run praxist doctor first. A recent PR fixed macOS symlink handling, so it's being actively worked on.

How is this different from Karpathy's AutoResearch?

AutoResearch is ~630 lines letting one agent edit one training file sequentially on one GPU. PRAXIST runs cohorts of parallel agents across generations with a typed evidence graph, preregistered evaluation, Pareto lanes, and resource scheduling. AutoResearch is a script; PRAXIST is a platform with a license agreement.

Verdict

PRAXIST is the most serious attempt we've seen to turn "let the agent run experiments" into an auditable process rather than a vibe. The evidence-graph design targets the biggest weakness of long agent campaigns — re-learning the same lessons — and the refusal to fabricate baselines or datasets is exactly the discipline the space needs.

But it's heavy, it's beta, it's source-available rather than open, and its headline cost number leans on model pricing as much as orchestration. If you have a measurable objective, a working evaluator, and a Linux box with GPUs, install a bundled example and run one calibration generation — that will tell you more than the press release. If you don't have all three, start lighter and come back when you do.

Links: GitHub · Docs · Paper (arXiv 2608.25955) · Launch press release

Codex with ChatGPT Review: ChatGPT Plans, Codex Executes

Andrew — Thu, 10 Sep 2026 10:11:58 +0000

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

TL;DR

Codex with ChatGPT (repo: XiaoDuoYa/codex-with-chatgpt, "C2C" for short) is an open-source bridge that makes the ChatGPT web app the planning-and-review brain for your Codex coding sessions, while Codex keeps every write, shell command, test run and git operation. The pitch in one line from the README: "ChatGPT thinks. Codex works." It was created on August 28, 2026, shipped v0.1.0 on August 30, and sits at ~3,900 stars and 400+ forks on September 10 — the fastest-growing new agent repo on GitHub this fortnight.

Key facts, as of September 10, 2026:

What it solves: your paid ChatGPT Plus/Pro web quota sits idle while Codex burns its own scarce quota on planning and code review. C2C moves the thinking to the subscription you already pay for.
How: a loopback-only local "C2C Bridge" exposes 9 read-only MCP tools (read_file, search_workspace, git_diff, test_status, …) to ChatGPT via an OAuth 2.1-protected Cloudflare tunnel. No API key, no reverse proxy, no cookie scraping.
Control loop: Codex and ChatGPT exchange tiny [C2C] state messages (INIT → PLAN → EXECUTED → REVIEW → DONE), never diffs or logs. Default cap: 12 iterations per task (configurable in .c2c.json).
Security posture is the strongest part: write/shell/commit tools do not exist on the server; .env*, keys and SSH files are denied by default; tokens are stored only as SHA-256 hashes; the pairing code is the only secret that ever touches a browser.
Requirements: Node.js ≥ 20, git, cloudflared, a ChatGPT plan with Developer Mode enabled (Plus works — see the caveats), and the Codex desktop app's built-in browser.
Honest limits: setup takes 20-40 minutes the first time, temporary tunnel URLs mean re-pairing after restarts unless you own a Cloudflare domain, Computer Use driving the ChatGPT UI is token-hungry and sometimes flaky, and the project is a V1 maintained by a single student author (with an AI agent answering issues).
License: MIT. Unofficial — not affiliated with OpenAI.

If you pay for both a ChatGPT plan and Codex and you're hitting 5-hour limits, this is the most interesting "use the quota you already have" hack of the month. If you want a polished, hands-off tool, wait for V2.

What Codex with ChatGPT actually is

Most "connect model A to coding agent B" projects are cookie-scraping proxies that break on every header change and violate the terms of service. C2C instead splits the collaboration into two planes:

Control plane (Computer Use): Codex opens ChatGPT in its built-in in-app browser and types short structured messages into the chat. ChatGPT replies in the same format. Messages are capped at < 1 KB and carry state only — a goal, a plan, a count of changed files, a test summary. No file bodies. Ever.
Data plane (MCP): ChatGPT reads whatever it needs itself through a custom MCP connector pointed at your local bridge. It pulls the exact lines it wants to see, runs a search, inspects the real git diff, and checks recorded test results.

So ChatGPT never receives a pasted dump of your repo, and Codex never spends its own tokens re-explaining the codebase. The piece most agent setups skip: ChatGPT does not trust Codex's "all tests passed" claim — it reads git_diff and test_status through MCP and checks.

It ships as a Codex Skill (skill/SKILL.md) plus a Node CLI called c2c. The Skill is the real UX layer: it tells Codex how to start the bridge, pair, drive the ChatGPT tab, and speak the protocol.

Installation

The README offers a one-paste prompt that makes Codex do everything, dependencies included. Here's the manual path:

git clone https://github.com/XiaoDuoYa/codex-with-chatgpt ~/codex-with-chatgpt
cd ~/codex-with-chatgpt
corepack pnpm install
corepack pnpm build        # -> dist/, exposes the `c2c` bin
pnpm test                  # vitest: 146 tests (path security, OAuth, pairing, MCP e2e)

# install the Codex Skill
mkdir -p ~/.codex/skills/codex-with-chatgpt
cp skill/SKILL.md ~/.codex/skills/codex-with-chatgpt/SKILL.md
# then edit the "The codex-with-chatgpt checkout lives at:" line to your clone path

Then, inside your project, tell Codex: "Set up Codex with ChatGPT." The Skill runs:

c2c setup           # bridge + tunnel + pairing code, all in one
c2c sandbox-allow   # whitelist the C2C settings dir in Codex's sandbox
c2c doctor --json   # health gate — nothing talks to ChatGPT until this is green

c2c setup starts the bridge on 127.0.0.1:48765 (ephemeral port on conflict), launches a Cloudflare Quick Tunnel for a public HTTPS URL, and prints a one-time 8-character pairing code (5-minute TTL, 5 attempts, rate-limited). Codex then opens chatgpt.com in the in-app browser, creates a custom MCP connector pointing at the tunnel URL, completes OAuth and enters the pairing code. You log into ChatGPT once. Success looks like:

Codex with ChatGPT

✓ Project detected
✓ Workspace Bridge started
✓ Secure connection established
✓ ChatGPT connected
✓ File read test passed

Ready.

Since v0.1.1, first-time setup asks one explicit question: auto (Codex drives the ChatGPT settings pages itself) or manual (Codex tells you exactly which fields to fill in). Given how flaky Computer Use can be — more on that below — I'd pick manual on the first run.

Optional: a stable hostname

The default Quick Tunnel URL is temporary: when the bridge restarts, the URL changes and Codex has to delete and re-create the ChatGPT connector — the "why do I reconnect every day?" complaint in issue #60. If you own a domain on Cloudflare, setup offers a Named Tunnel (c2c-<project>.your-domain.com) that survives restarts after a one-time Cloudflare login. Credentials live in the OS app-state directory (~/Library/Application Support/codex-with-chatgpt on macOS), never in the repo.

The C2C protocol in practice

Once paired, a task looks like this. You say: "Use Codex with ChatGPT to implement dark mode." Codex types into the ChatGPT tab:

[C2C]
STATE: INIT
TASK_ID: c2c_f81a
ITERATION: 0

GOAL:
Implement dark mode.

INSTRUCTION:
Inspect the connected workspace through Codex with ChatGPT MCP.
Create an implementation plan for Codex.

ChatGPT calls workspace_info, list_directory, search_workspace and read_file through the connector, then answers with a plan:

[C2C]
STATE: PLAN
TASK_ID: c2c_f81a
ITERATION: 1

RATIONALE:
Theme tokens live in src/styles/tokens.css; components read CSS vars…

ACTIONS:
1. Add [data-theme="dark"] token overrides in tokens.css
2. Add useTheme() hook with localStorage persistence
3. Wire toggle into Header.tsx

FILES_LIKELY_INVOLVED:
src/styles/tokens.css, src/hooks/useTheme.ts, src/components/Header.tsx

TESTS:
pnpm vitest run src/hooks

SUCCESS_CRITERIA:
Toggle persists across reload; no contrast regressions in Header

Codex applies the plan, runs the tests, and records the iteration locally before reporting back:

c2c record --task c2c_f81a --iteration 1 \
  --changed-files 3 --tests "27 passed" --exit-status ok \
  --command "pnpm vitest run src/hooks" --output-file /tmp/vitest.log

Then it sends STATE: EXECUTED with just the metadata (CHANGED_FILES: 3, TESTS: 27 passed) and a request to review. ChatGPT reads git_diff, execution_summary and test_status via MCP — and optionally the sanitized test log through execution_output — and replies with either another PLAN, DONE, or BLOCKED with a reason. The loop stops at 12 iterations by default and asks whether to continue.

Two design details I like:

The local sanitizer. Codex can nominate a test/build log for ChatGPT, but a local filter redacts tokens, pairing-code-shaped strings and home paths, applies size caps, and withholds private-key blocks entirely.
Checkpoints, not resume states. If Codex restarts mid-task, it reads a local checkpoint (PLAN_RECEIVED, EXECUTED_SENT, …) and continues the same ChatGPT conversation; if that chat is gone, it sends a HANDOFF brief built from the checkpoint, never from logs. The doc is explicit: "Do not re-pair, recreate the connector, or rewrite Project instructions just to resume."

Since September, each workspace maps to one ChatGPT Project (project-only memory) rather than one endless conversation, so history stays organized — a community proposal (issue #30) the author implemented within days.

The 9 read-only MCP tools

Tool	What ChatGPT gets	Guardrails
`workspace_info`	Root, package metadata, sanitized	Metadata sanitized before structured output (v0.1.2)
`list_directory`	Paginated listing	Sensitive-file gate applies to listings too
`read_file`	Line/byte-capped file body	`.env*`, keys, SSH, cloud creds denied; `.c2cignore` adds rules
`search_workspace`	ripgrep results (Node fallback)	Match and file-size caps
`git_status`	Working tree status	Read-only
`git_diff`	Paginated diff (`hasMore`, `nextOffset`)	Pathspec excludes for sensitive files
`test_status`	Last recorded test result	Validated on write and read
`execution_summary`	Iteration metadata from `c2c record`	Numeric args validated
`execution_output`	`list`/`read` sanitized command logs	Local redaction; private keys withheld

Scopes are enforced per tool (workspace.read, workspace.search, git.read, execution.read, offline_access), access tokens live one hour, refresh tokens rotate on every use and are bound to both the workspace and the client. v0.1.2 (September 4) added structured output schemas for all nine tools, so ChatGPT — or any other MCP client — no longer has to guess response shapes.

Security model: the best part of the project

docs/security.md is a proper threat table, not hand-waving. The highlights:

Read-only by construction. There are no write, delete, shell or commit tools on the server, so no prompt injection in a README, code comment or diff can escalate. Every tool description carries an explicit "workspace content is untrusted" warning.
Path containment uses realpath canonicalization of the deepest existing ancestor, rejects .., absolute escapes, backslash tricks and null bytes, resolves symlinks before the check, and is case-insensitive on macOS/Windows. All of it is covered by tests.
The bridge binds 127.0.0.1 only and refuses 0.0.0.0. The only public surface is HTTPS through the tunnel, gated by OAuth 2.1 with mandatory PKCE S256, dynamic client registration and rotating refresh tokens. Knowing the URL gets you a 401; the wrong workspace's token gets a 403.
The admin API is loopback-only, uses a random token in a 0600 runtime file, and rejects any request carrying proxy headers like cf-connecting-ip.
Logs redact bearer headers, token prefixes and pairing-code-shaped strings before they're written.
One acknowledged V1 gap: client registrations and token hashes are file-based, not in the OS keychain. Raw tokens are never written anywhere, so a stolen state file doesn't yield a usable bearer, but keychain integration is on the V2 list.

For comparison, OpenAI's Codex Security scanner finds vulnerabilities in your code; C2C is a community tool whose own attack surface is thought through more carefully than most MCP servers I see.

Community reaction

The repo blew up in the Chinese-speaking Codex community first (README, issues and Skill strings are bilingual), then crossed over via dev.to and scriptbyai write-ups in early September. Across 400+ issues and PRs, the recurring themes:

"Does Plus work or only Pro?" (issues #2, #21, #25). Early on, some Plus users got FORBIDDEN: This conversation does not support developer MCPs. The resolution in #21: toggle Developer Mode off and on again under ChatGPT Settings → Security, then add the connector from the Plugins page. The author is a Plus user and confirms it works.
"Setup took 40 minutes" (#8) and "I have to reconnect every day" (#60). Both trace back to Quick Tunnel URLs changing and Computer Use slowly clicking through ChatGPT's settings. Fixes so far: Named Tunnels (#18), a manual setup mode (v0.1.1), and a machine-level preference cache after one user noted the Skill "asks the same questions every day."
"Computer Use is unreliable and eats tokens" (#126). The author's answer: fully manual mode exists; only ChatGPT reading the workspace through MCP is irreplaceable.
"My quota exploded after the Project update" (#407). The user had left ChatGPT's high-effort mode on. The web model will call MCP tools liberally when reviewing; the author's own pairing is Codex on Luna Max + web ChatGPT on Sol High (#24).
Windows pain (#7, #59, #164): external browser launching, cloudflared path discovery, console windows flashing. v0.1.2 fixed the console spam and made Quick Tunnel startup fail closed.
"Why can't the web model write code directly?" (#24). Intentional. The author deliberately exposed only read access and is evaluating a safer hand-off, without committing to it.

Most first responses in the tracker come from "the author's AI Agent," which logs the issue, notes the author "is currently at school," and promises a human look within 48 hours — a fitting meta-detail, and a reminder that the bus factor is one.

Also watch PR #409: a machine-wide gateway with authentication set to none plus two write-capable MCP "mailbox" tools. The author's agent flagged it as breaking the read-only boundary. That thread decides whether V2 keeps the security story intact.

Codex with ChatGPT vs the alternatives

Approach	Where planning runs	Repo exposure	Bills against	Setup friction
Codex with ChatGPT (C2C)	ChatGPT web (Plus/Pro)	Read-only MCP, OAuth, tunnel	ChatGPT plan + Codex plan	High first run, then low with Named Tunnel
Codex alone	Codex's own model	Local	Codex quota only	None
`codex-bridge` (Claude Code plugin)	Codex, called from Claude Code	Local process	ChatGPT plan via `codex login`	Low
Cookie/session proxies	ChatGPT web	Full request forwarding	ChatGPT plan (ToS risk)	Low, but breaks often
Two-agent setups (planner API + executor)	API model	Whatever you paste	API credits	Medium

C2C is the only option where the planning model gets self-serve, scoped, read-only access to the code rather than a pasted context blob, and the only one with an independent diff review between "Codex says done" and "done."

Limitations

Two subscriptions required. ChatGPT plan and Codex. It doesn't reduce what you pay; it rebalances which quota gets consumed.
Computer Use is the weak link. Driving the ChatGPT UI through the in-app browser is slower and more brittle than an API call, and it costs Codex tokens. Expect occasional stalls.
Temporary tunnels rot. Without a Cloudflare-managed domain, every bridge restart means a connector rebuild.
Codex-only. No Claude Code or Cursor path, and the ChatGPT side must be the web app, not the API.
Plan quality is bounded by what ChatGPT chooses to read. On a large monorepo, plans can miss context a full-repo agent would catch.
V1, single maintainer, moving fast. Three releases in six days, 400+ issues/PRs, an AI agent triaging — impressive velocity, also a stability warning.
Not for regulated codebases. Even read-only, source goes through a public HTTPS tunnel to a third-party model; the deny list is pattern-based.

FAQ

Does Codex with ChatGPT work with ChatGPT Plus, or do I need Pro?

Plus works. You must enable Developer Mode in ChatGPT settings to add a custom MCP connector; several Plus users hit a FORBIDDEN: This conversation does not support developer MCPs error until they toggled Developer Mode off and on again. The author uses it on a Plus account. Team/Business plans may have connector policies set by an admin.

Can ChatGPT modify my files through the bridge?

No. The bridge exposes nine read-only MCP tools and no write, delete, shell, commit or install tools exist on the server. Codex is the only component that edits files, runs commands and commits. A pending PR proposes write-capable "mailbox" tools, but as of September 10, 2026 it has not been merged.

Is my repository uploaded to OpenAI?

Not as a whole. ChatGPT pulls individual files, search results and diffs on demand through the MCP connection, capped in size, with .env*, private keys, SSH and cloud credentials denied by default. Whatever it reads does go to OpenAI's servers like any ChatGPT conversation, so treat it as you would pasting that code into ChatGPT manually.

Why does it need Cloudflare?

ChatGPT's connector must reach your machine over public HTTPS. The bridge only listens on 127.0.0.1, so cloudflared provides a Quick Tunnel (temporary URL) or a Named Tunnel (stable hostname on your own domain). No Cloudflare account is needed for the temporary option.

Does it cost extra?

The software is free (MIT). It uses your existing ChatGPT plan and Codex plan; there's no API key and no per-token bill. The trade-off is that ChatGPT-side MCP calls and Codex-side Computer Use both consume plan quota, so leave high-effort modes off unless you need them.

Can I use it without Computer Use?

Yes. Ask Codex for manual mode and the Skill will give you the exact settings values to enter and let you relay [C2C] messages yourself. Only the MCP read connection is mandatory.

Verdict

Codex with ChatGPT is a smart answer to a real problem: two paid quotas, one of them idle. The security design is genuinely good — read-only by construction, OAuth 2.1 with PKCE, realpath containment, sanitized logs — and the protocol is disciplined (tiny state messages, independent diff review, checkpoint-based resume). That's more engineering than most weekend MCP projects get.

The rough edges are all operational: first-time setup, Computer Use flakiness, tunnel churn, Windows quirks, a single student maintainer. If you're a Codex + ChatGPT Plus/Pro user who keeps hitting limits and can stomach a manual first setup and a Cloudflare domain, install it today. Everyone else: star it and check back when V2 lands — especially if the read-only boundary survives.

Rating: 4/5 — strong idea, unusually careful security, V1 ergonomics.

Sources

XiaoDuoYa/codex-with-chatgpt on GitHub — README, docs/protocol.md, docs/security.md, docs/architecture.md
Release v0.1.2 (September 4, 2026) — structured MCP outputs, Windows tunnel fixes
Issue #21 — Plus accounts and Developer MCP, Issue #60 — daily reconnects, PR #409 — machine-wide gateway proposal
Codex with ChatGPT splits planning from execution — dev.to

Reverify Review: Make Your AI Agent Prove Every Claim

Andrew — Wed, 09 Sep 2026 10:13:26 +0000

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

TL;DR

Reverify is a Python CLI and MCP server built on one rule: the model proposes, a deterministic tool decides. An LLM can hypothesize anything it likes about an artifact — a function prologue, an imported symbol, whether a refactor is behavior-equivalent — but nothing counts as a fact until a tool checks it against ground truth and returns VERIFIED or REFUTED with evidence. The model never gets to assert a fact on its own.

It picked the hardest place to prove that idea: binary reverse engineering, where hallucination is at its worst. On 71 real Windows system DLLs, the model's "textbook" answer for the entry-point prologue was wrong 97% of the time; Reverify's verifier refuted every wrong claim and accepted zero. That gate now runs in CI on Linux, macOS, and Windows on every push and fails the build if a single wrong claim is ever marked VERIFIED.

Key facts as of September 9, 2026:

1,053 GitHub stars, 217 forks, created August 31, 2026 — nine days old
MIT licensed, pip install reverify, pure standard library with zero required dependencies; optional capstone / unicorn / lief / Z3 / angr engines upgrade it in place
Ships as an MCP server (re_verify_claim, re_ledger, re_checkpoint, …) for Claude Code, Cursor, and any MCP client
reverify rollover replaces auto-compaction in Claude Code, Codex CLI, Gemini CLI, and OpenCode with a file-based hand-off
0 false VERIFIED across 275 binaries in four formats/architectures; v0.8.0 → v0.11.0 shipped September 3–4, 2026

This is a narrow tool with a very general idea inside it. If you do binary analysis, malware triage, or CTF work with an AI agent, it is immediately useful. If you don't, the interesting part is the architecture — an anti-hallucination pattern most agent frameworks still don't implement.

The problem Reverify is built around

Every agent framework has the same soft spot: the model's own output goes back into its context as if it were true. It guesses an API signature in turn 3, builds on it in turn 8, and by turn 20 an entire plan rests on something nobody checked. When the window fills, a summarizer compresses the transcript — and the guess and the verified fact get the same treatment, because nothing in a transcript marks which is which. Reverify's author frames it for binaries: "Ask a model to reconstruct a struct or an algorithm from a binary and it will confidently invent offsets, sizes, and behavior."

The fix separates two roles most agents blur. The proposer — the LLM — emits claims: structured JSON hypotheses about the artifact. The judge — deterministic tooling — checks each claim against the actual bytes and hands back a verdict plus the evidence it saw. Only verified claims become facts. Refuted claims come back with what the tool observed, so the model can correct instead of re-guessing.

The verification loop in practice

pip install reverify              # pure-Python core
# or: pip install "reverify[full]"  → capstone + unicorn + lief + z3
reverify auto sample.bin --json   # triage: format, arch, sections, strings
reverify backends                 # which engines are active

A claim is a JSON object with a kind and whatever the verifier needs to check it:

reverify verify sample.bin --claim '{
  "kind": "instructions", "offset": 4096,
  "mnemonics": ["push", "mov", "sub"],
  "note": "function prologue"
}'

The verifier disassembles at that offset and answers VERIFIED, REFUTED, or INCONCLUSIVE. Claims batch from a file (--claims-file claims.json), and the CLI exits non-zero if anything is refuted, which makes it a drop-in CI gate.

The claim vocabulary is wider than it first looks. Structural kinds: bytes_at, typed reads (u32_at / u64_at), pattern_present, string_present, import_present, export_present, section_present. Behavioral kinds: emulate_result (run the bytes, compare registers), behavior_equiv (run the original function and a candidate reconstruction over shared inputs), and prove_equiv (Z3 proves two expressions equal for all inputs — the tool for MBA deobfuscation). The v0.9.0 semantic layer adds function_at, calls, references, and reachable_from_entry on top of angr. A refuted bytes_at even reports where the expected bytes actually are, and "observe": true lets the model read a value instead of guessing it.

A real hallucination, caught

The repository's EXAMPLE.md walks through one run on C:\Windows\System32\kernel32.dll with Claude as the proposer. The model saw only a fact sheet — format, architecture, sections, imports, strings, entry RVA — and not the entry-point disassembly.

Round 1, the model proposed from priors:

[REFUTED ] instructions @ entry (rva 0x2c500)  mnemonics ["push","mov","sub"]
           note: "DllMainCRTStartup: standard frame prologue (prior guess)"
[VERIFIED] export_present  CreateFileW
[VERIFIED] export_present  GetProcAddress
[VERIFIED] section_present .text

The textbook push rbp; mov rbp, rsp; sub rsp, N frame prologue is the strongest prior in any model's training data. It is wrong here. The verifier refuted it and returned the real bytes — the MSVC x64 shadow-space prologue:

mov qword ptr [rsp + 8], rbx ; push rdi ; sub rsp, 0x20 ; mov edi, edx ; mov rbx, rcx

Round 2, the model corrected from evidence:

[VERIFIED] instructions @ entry  mnemonics ["mov","push","sub","mov","mov"]
           operands ["qword ptr [rsp + 8], rbx","rdi","rsp, 0x20","edi, edx","rbx, rcx"]  mode=exact
Verified 3/3.  Information 1.236.  Trustworthy: True  Grounded: True

That Information 1.236 line is the second clever piece. "Every claim verified" is trivially reachable — assert that the file starts with MZ and that .text exists. So Reverify weighs each verified claim by how much it actually says: restating the fact sheet weighs zero, and the rest is scored by how rare and high-entropy the expected content is in this specific binary. A reconstruction is only "grounded" when nothing is refuted and the verified weight clears --min-information (default 1.0).

The benchmark: 275 binaries, 0 false accepts

BENCHMARK.md applies the textbook-prologue prior blind to a deterministic sample of the host's own system binaries and records, per file, whether the prior was wrong and whether the verifier ever accepted a wrong claim.

Platform	Format	Tested	Prior wrong	95% upper bound
Windows 11 (reference run)	PE x86 + x86_64	71	69 (97%)	5.1%
Linux x86_64 (ubuntu-latest)	ELF	40	40	8.8%
macOS (macos-latest, x86_64 slice)	Mach-O	77	77	4.8%
Windows Server (windows-latest)	PE	68	68	5.3%

Pooled with a third-party aarch64 replication: 275 binaries, 4 formats/architectures, 0 false VERIFIED, with a pooled 95% Wilson upper bound of about 1.4% on the false-accept rate. Two of the 71 Windows DLLs genuinely open with push; mov and were correctly verified — the benchmark is not rigged to always refute.

A control corpus makes this more credible: CI compiles two small C libraries with gcc, clang, and MSVC at -O0 and -O2. At -O0 the frame-pointer prologue really is there and verifies; at -O2 it isn't and gets refuted. Every run leaves a record with the SHA-256 of every binary and every verdict under benchmarks/results/, and releases ship with SLSA build provenance. For a nine-day-old solo project, this is an unusual amount of evidence engineering.

The ledger: facts that survive `/clear`

The second half of the project generalizes from "verify a claim" to "manage context." Every harness handles a full window the same way: summarize and drop the rest. Reverify's argument is that this loss is only unavoidable because the transcript doesn't know which parts were state. Its loop does know: the only things that matter are what the tools verified, observed, proved, and refuted. Everything else was never trusted, so dropping it loses nothing.

Since v0.8.0 that state lives in .reverify/ledger/<sha256>.json per binary (content-keyed, so a renamed copy shares its ledger), checkpointed after every round. Refutations are stored as KNOWN FALSE, so a fresh context doesn't re-propose the same wrong prior — the part a summary usually drops.

reverify reconstruct target.exe --goal "..."   # resumes from .reverify/ automatically
reverify ledger target.exe                     # what is established, what is known false
reverify ledger --hook                         # Claude Code SessionStart hook

Over MCP, re_verify_claim records every grounded result and re_ledger hands them back after the host compacts or clears. re_checkpoint notes are explicitly labelled UNVERIFIED — "only re_verify_claim results become facts."

reverify orchestrate closes the loop across sessions, running a goal as a sequence of fresh contexts and rolling over on the model's request, a token budget, or drift. The recorded run on msimg32.dll with the Claude Agent SDK driver — 2 sessions × 4 turns — produced 15 grounded facts across the rollover, 2 refuted guesses, 0 false accepts, and a second session that started from the ledger rather than a summary.

`reverify rollover`: the same idea for any agent CLI

This is the piece most readers will actually try, because it has nothing to do with binaries.

reverify rollover install          # wires hooks into every CLI on PATH (backups kept)
reverify rollover doctor           # what is wired, recent events
reverify rollover claude           # launch Claude Code through the launcher
reverify rollover codex --full-auto

install turns off native auto-compaction in each CLI and installs a guard at its "turn finished" hook. At the threshold — REVERIFY_ROLLOVER_TOKENS, default 200k — or when the model runs reverify rollover request, the guard blocks one stop and asks the model to write a hand-off file with fixed sections, labelled UNVERIFIED. Nothing is summarized inside the conversation.

The design is fail-closed: on the next stop the guard checks that the hand-off was really rewritten, and only then writes a receipt carrying the transcript's SHA-256 and the user's verbatim first and latest messages. Then whoever can end the session does it — the launcher for any CLI, Gemini in-process, OpenCode via the SDK. The old transcript stays on disk as an audit trail. In the author's words, the hand-off is written while the model still has the whole context, "and the conversation that produced it is dropped, not paraphrased."

The same rule now reaches ordinary code: reverify equiv <reference> <candidate> --lang python (or C) runs both implementations over shared inputs and returns a counterexample on mismatch, so an AI's refactor is tested, not trusted. It is a small feature today, but it is the one that could pull Reverify out of its niche.

Setting it up as an MCP server

{
  "mcpServers": {
    "reverify": {
      "command": "python",
      "args": ["/path/to/reverify/reverify/mcp_server.py"]
    }
  }
}

Exposed tools: re_auto_triage, re_parse, re_pattern_scan, re_disasm, re_verify_claim, re_semantic, re_checkpoint, and re_ledger. Once wired, your agent can have its hypotheses judged against the bytes before it reports them, and its grounded facts come back automatically after a /clear.

Community and early feedback

Reverify has not had a Hacker News or Reddit moment yet; the README notes it was shared on LINUX DO, a Chinese-language developer community. The 217-fork-to-1,053-star ratio is unusually high, which usually means people are pulling the code to run the benchmark locally — consistent with a project whose whole pitch is "replicate it yourself."

The most substantive external feedback is from contributor IMGillusion, who has landed five PRs (ARM64 disassembler routing, an ExeBench adapter, a multi-prior scorecard, among others). Their open issue #14 is the most honest picture of where the loop still breaks:

"When the orchestrate goal is phrased as an open-ended description, the model stops using the structured claim kinds and degrades to raw bytes_at guessing. The run never converges."

Their repro on a qwen3.8-27b endpoint: /usr/bin/ls with the goal "find the dynamic import list" converged on 14 import_present claims; /usr/bin/cat with an open-ended phrasing of the same goal produced zero structured claims and stalled. The root cause is a prompt gap, and the one-line fix in PR #19 flips the run to 100% structured claims. The verifier is airtight, but the proposer is still a language model, and small prompt details decide whether the loop converges.

Honest limitations

Nine days old, single-author, alpha. 74 of 82 commits are from 2akouwu; PyPI's classifier says Development Status :: 3 - Alpha. Four versions shipped in 48 hours, and PyPI currently lists 0.10.0 while the repo is at 0.11.0 — APIs will move.
The benchmark measures one prior. The 97%-wrong figure is for the textbook-prologue guess specifically, not a general hallucination rate — the author says to "treat it as a data point, not a headline."
The pure-Python core is limited. Without capstone/unicorn/lief, semantic claims answer INCONCLUSIVE for almost everything. Real work wants reverify[full]; the semantic layer wants angr, a heavy install, and its verdicts sit at a lower DERIVED tier because CFGFast is heuristic.
rollover has a sharp edge. The hooks can write the hand-off but cannot end a Claude Code or Codex session. Start the CLI yourself with native compaction now disabled and the conversation has no ceiling — the README admits "one measured session reached 909k tokens before its owner noticed." Use the launcher, set REVERIFY_ROLLOVER_SUCCESSOR=bg, or run doctor regularly.
Authorized use only. Malware analysis, CTF, interoperability research, and software you own — a policy line, not a technical control.

How it compares

Tool	What it does	Judge is deterministic?	Survives context reset?
Reverify	Model proposes claims about bytes/code; tools verify with evidence	Yes	Yes (content-keyed ledger + rollover)
Ghidra / IDA + LLM plugins	LLM annotates a decompilation	No	No
Guardrails / LLM-as-judge	A second model scores the first model's output	No	No
Native auto-compaction (Claude Code, Codex)	Summarize transcript when full	No	Lossy (summary includes guesses)
ExeBench-style re-executability	Compile and run candidate vs. reference	Yes	N/A (one-shot)

The unique seat is the combination: deterministic verdicts and a memory that only stores what was verified.

FAQ

Is Reverify free?

Yes. MIT license, pip install reverify, zero required dependencies. The optional engines (capstone, unicorn, lief, Z3, angr) are open-source too.

Does it need an API key or a specific model?

No. The proposer is whatever agent you already run over MCP. reverify orchestrate --driver claude uses your Claude Code login via the Claude Agent SDK; --driver openai takes OPENAI_* env vars for any OpenAI-compatible endpoint; --driver mock runs the loop with no model at all.

How is this different from an LLM-as-judge guardrail?

The judge is not a model. A claim is checked by disassembling, emulating, or proving against the actual artifact, and the verdict comes with the observed bytes. The verifier is itself cross-checked against capstone, Unicorn, lief, and objdump, fuzzed nightly, and gated so that 0 of 475 known-false claims may ever be accepted.

Can I use it on source code, not binaries?

Partially — reverify equiv covers Python and C behavior equivalence. The structural claim vocabulary (bytes_at, import_present, etc.) is binary-specific.

Bottom line

Reverify is two products in one repo. The first is a rigorous reverse-engineering companion for AI agents — if you do binary analysis with Claude Code or Cursor, install it today. The second is a working prototype of an idea the whole agent ecosystem needs: an agent's memory should contain only what a deterministic tool confirmed, and a context reset should drop the chatter, not the facts.

It is early, niche, and moving fast. But the evidence discipline — receipts on every verdict, a CI benchmark that fails on a single false accept — is better than most tools ten times its age. Watch reverify equiv and reverify rollover; those are the parts that could matter to everyone.

Install: pip install "reverify[full]". Source, benchmarks, and replication package at github.com/2akouwu/reverify.

Sources

2akouwu/reverify on GitHub — README, star/fork counts, release history (v0.8.0–v0.11.0, September 3–4, 2026)
EXAMPLE.md — the kernel32.dll worked example
BENCHMARK.md — the 275-binary, 0-false-accept measurement and CI records
Issue #14 and PR #19 — open-ended goal drift reported by IMGillusion
reverify on PyPI — version, license, optional dependency groups

VoiceStudio Review 2026: Local ElevenLabs Alternative

Andrew — Tue, 08 Sep 2026 10:10:51 +0000

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

TL;DR

VoiceStudio is a desktop app that bundles 16 local text-to-speech engines and 11 speech-recognition engines behind one UI, plus an OpenAI-compatible API on localhost:3900. It does voice cloning, voice design, video dubbing, dictation, and audiobook production without an account, an API key, or a usage meter.

Repo: debpalash/VoiceStudio — 21,026 stars, 2,618 forks, Python + TypeScript, AGPL-3.0, created April 9, 2026.
Momentum: roughly 7,900 stars in the last week, which is what put it near the top of GitHub Trending.
Formerly: OmniVoice-Studio. The rename is recent, so search results and forks still carry the old name.
Latest release: v0.5.1 (August 28, 2026). The README labels the project an active beta in a warning box.
The catch nobody mentions: the app is AGPL-3.0, but the default model weights are CC-BY-NC. Commercial use requires switching engines. More on this below.

Quick Reference

Item	Detail
Repo	github.com/debpalash/VoiceStudio
App license	AGPL-3.0 (commercial license on request)
Default model license	CC-BY-NC weights (Apache-2.0 code)
Stack	Tauri v2 (Rust) + React/Vite + FastAPI + SQLite
Backend port	`127.0.0.1:3900` (loopback only)
TTS engines	16
ASR engines	11
Language catalogue	646 (engine-dependent)
Platforms	macOS 13.3+ (Apple Silicon), Windows 10/11 x64, Linux x86_64 glibc 2.39+, Docker
Compute	CUDA · MPS/MLX · ROCm (Linux) · CPU
Data dir	`omnivoice_data/`

The Problem VoiceStudio Actually Solves

The local TTS ecosystem in 2026 is not short of models. It is short of plumbing.

If you want to clone a voice on your own hardware today, the usual path looks like this: clone a model repo, fight a PyTorch version, discover the weights need a Hugging Face token, write a script to chunk long text, write another to stitch WAVs, then realise the model cannot do the language you need and start over with a repo that has entirely different conventions.

Every one of those models is good. The glue between them is what nobody ships.

VoiceStudio's actual contribution is the glue: a registry-based engine interface where 16 TTS backends and 11 ASR backends expose the same capabilities to the same UI and the same API. You switch engines from the status bar with Ctrl/Cmd+E. The app handles the Python environment, model downloads, GPU routing, and disk accounting.

That reframing matters when you judge it. VoiceStudio is not competing with OmniVoice or CosyVoice — it ships them. It is competing with the afternoon you would otherwise spend wiring them together.

Installation

The one-command installer covers every desktop OS:

# macOS / Linux / WSL
curl -fsSL https://voicestudio.sh/install | sh

# Windows
irm https://voicestudio.sh/install | iex

Prebuilt packages are on the releases page: an Apple Silicon DMG, a Windows x64 MSI (with a current-user build that skips admin rights), and a Linux AppImage. Docker works if you would rather keep it contained:

docker run -d -p 127.0.0.1:3900:3900 \
  -v omnivoice-data:/app/omnivoice_data \
  --name voicestudio \
  palashdeb/omnivoice-studio:stable

From source it is Bun-based (bun install && bun run desktop, or bun run dev for the browser UI). First launch builds a managed Python environment via uv and pulls the default model. Budget time and disk for that — the stated minimum is 10 GB free, with 20 GB+ SSD recommended.

The macOS footnote that will bite someone: Intel Macs cannot run the local Python backend at all, because current PyTorch wheels are unavailable for them. Intel Mac owners have to point the app at a remote backend. Apple Silicon gets MPS and MLX paths.

Your First Clone

The documented flow is three steps: open Voice Cloning, drop in a reference clip, generate. The interesting detail is in the FAQ, and it corrects the most common user assumption — longer reference audio does not reliably produce a better clone:

Cloning is zero-shot: the clip is a prompt, not training data. Use 5 to 15 seconds of one speaker, close to the microphone, without music, noise, or reverb.

Three seconds works; five to fifteen is the sweet spot. Feeding it two minutes of podcast audio is not "more training data" — it is a longer prompt with more chances to include a cough. If you genuinely want a trained voice rather than a zero-shot prompt, the repo has separate data-preparation and training docs.

The API Is the Real Story

For anyone building rather than clicking, the OpenAI-compatible endpoint is the headline feature. It is a one-line base-URL swap:

- base_url="https://api.openai.com/v1"
+ base_url="http://localhost:3900/v1"

from openai import OpenAI

client = OpenAI(base_url="http://localhost:3900/v1", api_key="local")

with client.audio.speech.with_streaming_response.create(
    model="tts-1",
    voice="<profile-id>",
    input="Made on my own hardware.",
    response_format="wav",
) as response:
    response.stream_to_file("speech.wav")

Or without an SDK at all:

curl http://localhost:3900/v1/audio/speech \
  -H "Content-Type: application/json" \
  -d '{"model":"tts-1","input":"Made on my own hardware.","voice":"default","response_format":"wav"}' \
  --output speech.wav

The surface covers more than synthesis:

Endpoint	Purpose
`POST /v1/audio/speech`	TTS to mp3, opus, aac, flac, wav, pcm
`POST /v1/audio/transcriptions`	STT to json, text, verbose_json, srt, vtt
`WS /v1/audio/transcriptions/stream`	Live PCM/WebM transcription with partial + final events
`GET /v1/audio/voices`	List local voice profiles and engines
`GET /.well-known/voicestudio-speech`	Transport discovery (HTTP, WS, MCP, dictation)

There is also an MCP server mounted at http://localhost:3900/mcp, exposing generate_speech, clone_voice, and transcribe to Claude Desktop, Cursor, and other agent clients:

{
  "mcpServers": {
    "voicestudio": { "url": "http://localhost:3900/mcp" }
  }
}

And agent skills, if your harness speaks skills.sh:

npx skills add debpalash/VoiceStudio

Security posture is sane by default. The backend binds loopback only. Loopback calls need no key; anything non-local requires a share PIN or API key. Non-loopback ASR endpoints must be HTTPS and redirects are explicitly not followed. Analytics is off until you consent, and when enabled sends allowlisted, content-free metadata — never text, audio, filenames, or projects.

Picking an Engine

Sixteen engines is a lot of choice, which is its own kind of problem. The README's hardware table is the shortcut:

Hardware	Recommended TTS	Recommended ASR
Apple Silicon (M1–M4)	MLX-Audio · OmniVoice (MPS)	MLX Whisper · Parakeet MLX
NVIDIA GPU (8 GB+ VRAM)	OmniVoice · CosyVoice 3	WhisperX
Low VRAM / CPU-only	PocketTTS · Sherpa-ONNX · KittenTTS	Moonshine · Faster-Whisper (`int8`)

The engine roster spans licenses and capabilities unevenly, and that unevenness is the thing to check before committing:

OmniVoice (default) — 600+ languages, cloning, instruct. Apache-2.0 code, CC-BY-NC weights.
CosyVoice 3 — 9 languages + 18 dialects, cloning, instruct, Apache-2.0. The best all-round permissive option.
VoxCPM2 — 30 languages, cloning, instruct, Apache-2.0, runs on MPS.
MOSS-TTS-v1.5 — 31 languages, cloning, Apache-2.0.
GPT-SoVITS — 5 languages, cloning, MIT, but no macOS support.
KittenTTS — English only, CPU only, no cloning, MIT.
IndexTTS 2.5 — 5 languages, cloning, under a Bilibili model license that requires a separate written agreement above 100 million MAU or RMB 1 billion annual revenue.

One design decision deserves credit: engines without cloning support cannot preserve a reference speaker in dubbing or pinned-voice batch jobs, and VoiceStudio rejects those jobs rather than silently swapping engines. Failing loudly beats quietly producing the wrong voice, and plenty of tools get this wrong.

Beyond Cloning

The feature list is wider than "ElevenLabs alternative" implies:

Video dubbing — transcribe, translate, preserve speakers, synthesize, export. Completed dubs flag timing issues for review, plus a glossary for term consistency.
Stories and audiobooks — multi-voice scripts, EPUB/PDF import, chapter rendering, .m4b export.
Dictation widget — system-wide shortcut, live transcription, optional local-LLM cleanup.
Vocal isolation — Demucs speech/background separation.
Speaker diarization — Pyannote and WhisperX speaker assignment.
Batch queue — large job sets with per-job progress, or watch a folder for new videos.
AudioSeal watermarking — imperceptible synthetic-speech watermarking, on by default.

That last one is worth pausing on. Zero-shot voice cloning on consumer hardware is genuinely dual-use, and the project enables Meta's AudioSeal watermarking by default rather than hiding it behind a checkbox nobody finds. Not a complete answer to misuse, but a better default than most of the field.

What the Community Says

The underlying OmniVoice model has strong word of mouth. From r/LocalLLaMA:

"It's way better than Qwen3, Chatterbox or any other local TTS that I was able to use."

The same commenter supplied the useful number: on an RX 590, roughly 15 seconds of audio takes 25–30 seconds to generate at 32 inference steps. Slower than realtime on old hardware — fine for audiobooks and dubbing, not fine for a live conversational agent.

The counterweight comes from r/TextToSpeech, where someone who tested echoTTS, Chatterbox, VibeVoice, Qwen3-TTS, IndexTTS2, Fish Audio, MOSS-TTS, and OmniVoice concluded:

"Once in a while, one model will outperform the other. So is there one best? I would not say so."

Which is, incidentally, the strongest argument for VoiceStudio. If no single model wins across languages, voices, and speed, then the app that lets you switch between sixteen of them behind a stable API is worth more than any individual model choice.

Honest Limitations

The license trap is the big one. The application is AGPL-3.0 and does not restrict selling generated audio. But the default OmniVoice weights are CC-BY-NC — non-commercial. Anyone who installs VoiceStudio, records a demo, and ships it in a client project has a problem they probably do not know they have. The fix is straightforward: switch to CosyVoice 3, VoxCPM2, or MOSS-TTS-v1.5, all Apache-2.0. But the default is the trap, and "read the model terms" in a footnote is not a loud enough warning for how easily this goes wrong.

AGPL matters if you host it. Modify VoiceStudio and offer that version as a network service, and AGPL requires you to publish your source. A commercial license for VoiceStudio-owned code exists on request — it does not relicense the third-party models.

It is beta, and the release notes prove it. v0.5.1's highlights are a catalogue of crash fixes: fatal MPS memory exits taking down the backend on Apple Silicon, a Windows 0xC0000005 access violation from overlapping WhisperX calls, remounts stacking native jobs. These are all fixed — the maintainer is clearly responsive, and several fixes credit outside contributors. But 91 open issues and that changelog shape say pre-1.0 loudly. Issue #315 is representative: on Windows, the first voice-clone render is perfect and every render afterward in the same session comes out with static and slowed playback.

Cold-start latency is real. The v0.5.1 notes measure first synthesis on a cold filesystem at roughly 42 seconds, three seconds short of a 90-second client timeout — which is why the AudioSeal watermark generator now warms on a background thread ~35s after boot, and cloned voice references persist to disk (~10 KB each) so the first generation of a session skips the re-encode. Good fixes that exist because the cold path was genuinely painful.

Hardware reality check. 8 GB RAM and CPU-only technically works, but the default multi-stage workflow wants 8 GB+ VRAM and large optional engines want 12–16 GB. ROCm is Linux-only; Windows AMD and Ryzen AI fall back to CPU.

646 languages is a catalogue number, not a quality claim. The README says so directly: coverage and quality depend on the engine. Only the OmniVoice family reaches 600+. CosyVoice 3 does 9. KittenTTS does English.

Who Should Use This

Good fit: volume work where per-character cloud billing hurts — audiobook production, multilingual dubbing, dataset generation. Privacy or compliance constraints that keep audio on the machine. Agents needing a local voice via MCP or the OpenAI-compatible endpoint. A/B testing several TTS models without maintaining several repos.

Bad fit: realtime conversational agents on modest GPUs — the latency is not there yet. Intel Mac owners. Teams that need commercial rights and will not audit which engine is loaded. Anyone who needs a hosted API with an SLA.

FAQ

Is VoiceStudio really free?
The software is, with no paid tier and no usage meter for the local workflow. You supply the hardware, and development is donation-funded. The cost that is not money is disk, VRAM, and setup time.

Can I sell audio I generate with it?
Not with the default engine, realistically. The AGPL-3.0 application license does not restrict generated audio, but the default OmniVoice weights are CC-BY-NC and the bundled audio tokenizer carries separate Boson Higgs Audio 2 and Meta Llama community terms. For commercial work, switch to an Apache-2.0 engine — CosyVoice 3, VoxCPM2, or MOSS-TTS-v1.5 — and confirm the terms of the specific weights you download.

How is this different from just running OmniVoice directly?
OmniVoice is one model. VoiceStudio is the application layer around 16 TTS and 11 ASR engines: managed Python environment, model catalogue, GPU auto-detection, batch queue, dubbing pipeline, diarization, watermarking, an OpenAI-compatible API, and an MCP server. If you only ever want OmniVoice and you are comfortable in Python, run it directly. If you want to compare engines or expose speech to other apps, the wrapper is the point.

Does it work without a GPU?
Yes. CPU mode is supported and some engines target it specifically — PocketTTS, Sherpa-ONNX, KittenTTS for synthesis, Moonshine and Faster-Whisper at int8 for transcription. Expect substantially slower generation with the heavier engines, and expect low-VRAM systems to offload to CPU automatically.

Does it phone home?
Not by default. Analytics is off until you opt in, and skipping the consent prompt keeps it off. When enabled it sends allowlisted, content-free usage metadata — never text, audio, filenames, voices, or projects. The backend is loopback-only. The exceptions are all explicit opt-ins: remote workers, external OpenAI-compatible ASR endpoints, and the Colab notebook, which is remote compute by definition.

Can other apps and agents drive it?
Yes, through several transports: REST, SSE, WebSocket, JSON-RPC, a CLI, and an MCP server at localhost:3900/mcp. A bundled Rust control sidecar lets coding agents, VS Code, desktop apps, and TUIs trigger the system-wide dictation flow or reuse its native text insertion. Read the API auth doc before exposing the backend beyond loopback.

Verdict

VoiceStudio is the most complete local voice stack currently packaged as a single install, and the OpenAI-compatible API plus MCP server make it useful as infrastructure rather than just a desktop toy. 21,000 stars in five months is not noise — the plumbing problem it solves is real, and the maintainer is shipping fixes fast.

Two caveats decide whether it fits you. It is beta, and the crash-fix-heavy changelog means you should track releases rather than run main. And the default engine's CC-BY-NC weights make the out-of-box configuration non-commercial — check which engine is loaded before you invoice anyone for the output.

For personal projects, privacy-constrained work, and high-volume audio where cloud billing stings, it is an easy recommendation. For commercial pipelines, it is an easy recommendation after you have deliberately switched engines.

Sources

debpalash/VoiceStudio on GitHub — README, engine tables, architecture, FAQ, license notice
VoiceStudio v0.5.1 release notes — crash isolation, cold-start measurements, prompt disk cache
Issue #315: Windows repeat-render static noise
r/LocalLLaMA — OmniVoice quality and RX 590 generation timings
r/TextToSpeech — comparative testing across local TTS models
k2-fsa/OmniVoice model license on Hugging Face

Future AGI Review 2026: Open-Source LLM Eval Platform

Andrew — Mon, 07 Sep 2026 10:12:01 +0000

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

TL;DR

Future AGI is an Apache-2.0 platform that tries to replace four or five separate LLMOps tools at once: tracing, evaluation, guardrails, an LLM gateway, agent simulation, and prompt optimization — all self-hostable, all in one Docker Compose stack.

Repo: future-agi/future-agi — 1,944 stars, 583 forks, Python, Apache 2.0, created April 23, 2026.
Activity: genuinely busy. ~4,849 commits in 52 weeks, 66 contributors, 1,690 merged PRs, and v1.35.0 shipped September 4, 2026.
The pitch in one line: stop stitching Langfuse + Braintrust + Helicone + Guardrails AI together and run one feedback loop instead.
The catch: the README itself opens with a nightly-release warning — "Expect rough edges." There are 294 open issues, no official Kubernetes/Helm support yet, and the self-hosted build phones home with admin email addresses unless you opt out.
Verdict: the most ambitious open-source LLMOps scope I've reviewed this year, and the least settled. Great for a team that wants one stack and can tolerate churn. Wrong choice if you just need a span viewer.

Quick Reference

Item	Detail
Repo	github.com/future-agi/future-agi
License	Apache License 2.0
Latest release	v1.35.0 (September 4, 2026)
Language	Python (Django 5.1) + Go 1.23 gateway + React 18
Datastores	PostgreSQL, ClickHouse, Redis, RabbitMQ + Temporal
Install	`git clone` + `./bin/install` (Docker Compose)
Local UI	http://localhost:3000
Python SDK	`pip install ai-evaluation`
TS SDK	`npm i @traceai/fi-core`
Managed option	Cloud free tier at app.futureagi.com

What Future AGI Actually Is

Most LLM observability tools pick a lane. Langfuse is tracing plus prompt management. Phoenix is an OpenTelemetry span viewer with evals bolted on. Helicone is a proxy that happens to log. Guardrails AI does input/output validation and nothing else.

Future AGI's bet is that those lanes are artificial — that the interesting product is the loop between them. Production traces should become eval datasets. Eval failures should become simulation scenarios. Simulation results should feed a prompt optimizer. The optimizer's output should go back out through the gateway.

That's a real architectural argument, and it's the reason this repo is worth looking at even if you don't deploy it. Whether the loop actually closes in practice is the open question, and I'll get to that.

The system ships as six pillars:

Pillar	What it does	Replaces
Simulate	Multi-turn conversations against generated personas, adversarial inputs, edge cases. Text and voice (LiveKit, VAPI, Retell, Pipecat).	Custom simulator scripts
Evaluate	50+ metrics behind one `evaluate()` call — groundedness, hallucination, tool-use correctness, PII, tone, custom rubrics. LLM-as-judge + heuristic + ML.	Braintrust, Ragas
Protect	18 built-in scanners (PII, jailbreak, injection) plus 15 vendor adapters (Lakera, Presidio, Llama Guard).	Guardrails AI
Observe	OpenTelemetry-native tracing across 50+ frameworks. Span graphs, latency, token cost.	Langfuse, Phoenix
Gateway	OpenAI-compatible Go proxy. 100+ providers, 15 routing strategies, semantic caching, virtual keys, MCP, A2A.	Helicone, LiteLLM, Portkey
Optimize	Six prompt-optimization algorithms: GEPA, PromptWizard, ProTeGi, Bayesian, Meta-Prompt, Random.	Nothing mainstream

The last row is the genuinely differentiated one. Agent simulation and automated prompt optimization are not standard features in this category — Langfuse, Phoenix, Braintrust, and Helicone don't ship either.

Getting It Running

Self-hosting needs Docker Desktop or Docker Engine with Compose available first. Then it's one command:

# macOS / Linux / WSL
git clone https://github.com/future-agi/future-agi.git
cd future-agi
./bin/install

# Windows PowerShell
git clone https://github.com/future-agi/future-agi.git
cd future-agi
.\bin\install.ps1

The installer pulls published images rather than building from source, which keeps first-run time reasonable. The UI comes up at http://localhost:3000.

For anything beyond a laptop trial, use the production path instead — it generates secrets and pins image tags rather than tracking latest:

./deploy/setup.sh

Pinning matters more than usual here. At the current release cadence — five releases in the first four days of September — an unpinned latest is a moving target under your production traffic.

One upgrade gotcha worth knowing before you hit it. If you're upgrading an install that already holds traces, you need to explicitly initialize inactive property catalogs after the new stack is healthy:

# macOS / Linux / WSL
./bin/property-catalog-backfill --execute

# Windows PowerShell
.\bin\property-catalog-backfill.ps1 -Execute

To the project's credit, ordinary restarts never trigger a historical scan, the command reuses the image Compose already selected, it skips already-active workspaces, and it resumes through a durable ledger. That's a carefully-built migration path, not an afterthought.

Instrumenting Your App

This is the part that will decide whether you adopt it, and it's genuinely low-friction. Tracing is two lines before your existing code — no call-site rewrites:

from fi_instrumentation import register
from traceai_openai import OpenAIInstrumentor

register(project_name="my-agent")
OpenAIInstrumentor().instrument()

# Your existing OpenAI code is now traced.
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": query}],
)

TypeScript is the same shape:

import { register } from "@traceai/fi-core";
import { OpenAIInstrumentation } from "@traceai/openai";

register({ projectName: "my-agent" });
new OpenAIInstrumentation().instrument();

// Your existing OpenAI code is now traced.
const response = await openai.chat.completions.create({
  model: "gpt-4o",
  messages: [{ role: "user", content: query }],
});

Because instrumentation is OpenTelemetry-native, the lock-in risk on the tracing layer specifically is low. Your spans are OTLP. If Future AGI doesn't work out, you point the exporter somewhere else. The SDKs are also split into independently packaged, independently usable repos — traceAI for instrumentation, ai-evaluation for metrics, agent-opt for optimization, agent-simulate for voice simulation. You can adopt one piece without the platform, which is a materially better deal than an all-or-nothing install.

Framework coverage is broad: LangChain, LangGraph, LlamaIndex, CrewAI, AutoGen, PydanticAI, DSPy, Haystack, Instructor, LiteLLM, plus 100+ model providers including self-hosted Ollama, vLLM, and LM Studio.

The Gateway and Its Benchmarks

The Agent Command Center is a Go gateway claiming ~29,000 req/s on a t3.xlarge, P99 ≤ 21 ms with guardrails enabled, and ~9.9 ns weighted routing overhead.

Those numbers are plausible for a Go proxy doing header-level routing, and the project publishes a committed benchmark harness so you can reproduce them. That's better practice than most vendors manage — a reproducible harness beats a marketing chart.

Two caveats. First, these are vendor-run benchmarks on vendor-chosen hardware; a t3.xlarge is a modest instance, so the throughput figure is more impressive than the box, but your routing rules and guardrail scanner mix will move P99 substantially. Second, guardrail latency is highly dependent on which scanners you enable — an ML-based jailbreak classifier is not the same cost as a regex PII match. Run the harness on your own config before quoting the P99 anywhere it matters.

How It Compares

The README ships a comparison table against Langfuse, Phoenix, Braintrust, and Helicone. It's vendor-authored — Future AGI wrote a table in which Future AGI wins — and it's dated "as of April 2026," which is five months stale in a category that ships weekly. Treat it as a feature checklist to verify, not as a finding.

Here's the number the table omits, and it's the one that matters most for an infrastructure dependency:

Project	Stars	License	Language
Langfuse	34,286	(custom/MIT core)	TypeScript
Arize Phoenix	11,354	(custom)	Python
Helicone	6,134	Apache 2.0	TypeScript
Future AGI	1,944	Apache 2.0	Python

Future AGI has roughly 6% of Langfuse's community. For a tool you're putting in the request path of a production agent, ecosystem size is a real input: Stack Overflow answers, third-party integrations, battle-tested edge cases, and the odds the project is still maintained in three years all scale with it.

Where Future AGI legitimately leads is breadth under one license. Braintrust is not open source in the way the others are. Helicone and Langfuse have no simulation or optimization layer. Phoenix has no gateway. If you actually want all six pillars self-hosted under Apache 2.0, this is currently the only option — the comparison isn't rigged so much as it's asking a question only one product answers.

The honest framing: Future AGI competes on scope, not on maturity.

Honest Limitations

It calls itself a nightly. The README's first line is a warning that this is an early-testing release with rough edges and a stable version "coming out soon." Believe it.

The stack is heavy. PostgreSQL and ClickHouse and Redis and RabbitMQ and Temporal, fronting Django, a Go service, and a React app. That's six stateful components before you've traced a single span. Langfuse self-hosts on Postgres and ClickHouse. If you're a small team without platform engineering capacity, this is a real operational tax — and Temporal in particular is not a casual dependency.

No Kubernetes or Helm yet. Docker Compose on a VM is the supported production path today; official manifests and Helm charts are listed as coming soon. For orgs that deploy exclusively via Helm, that's a hard blocker right now.

Default telemetry collects admin email addresses. On first boot the self-hosted instance registers instance ID, version, deployment type, and the email addresses and domains of active admin users, then sends periodic anonymous usage heartbeats. You can set FUTURE_AGI_TELEMETRY_DISABLED=1 to opt out — but even disabled, it still sends one minimal census ping (instance ID, version, deployment type, no emails). The project documents this clearly and says no traces, prompts, or API keys are ever sent, which is the right disclosure. It's still a surprising default for a tool marketed on data sovereignty, and if you're self-hosting for compliance reasons, set that variable in your .env on day one:

# .env (or deploy/.env.production for the production overlay)
FUTURE_AGI_TELEMETRY_DISABLED=1

294 open issues against a repo that's under five months old. High velocity cuts both ways.

The open-source/cloud boundary needs watching. The commercial product is the same brand, and the repo is where the free tier funnel lives. Nothing about the Apache 2.0 grant is ambiguous today, but "open core drifts" is the default outcome in this category — Braintrust and Phoenix both carry non-standard licenses for a reason.

Who Should Use It

Use Future AGI if: you're building agents where correctness is the hard problem, not throughput — RAG with citation verification, voice agents, customer support, computer-use agents. You want evals, guardrails, and simulation under one roof, you have the ops capacity for a six-service stack, and you're comfortable pinning versions and reading changelogs.

Skip it if: you want a span viewer (use Phoenix), you want the largest ecosystem and the safest bet (use Langfuse), you have one LLM call per request and want zero friction (use Helicone), or you need Helm charts today.

Middle path, and the one I'd actually recommend for most teams: adopt traceAI or ai-evaluation standalone. They're separately packaged, OTel-native, and Apache/MIT licensed. You get the evaluation depth without betting your infrastructure on a four-month-old platform, and you can graduate to the full stack later if the loop proves out.

FAQ

Is Future AGI actually open source, or open core?
The repo is Apache 2.0, including the evaluators, the gateway, and the simulation engine — genuinely permissive, not source-available. A managed cloud exists alongside it with SOC 2 Type II and HIPAA claims. As of September 2026 there's no visible feature gating in the OSS build, but as with any commercially-backed project, verify the license on the specific components you depend on before you commit.

Can I self-host it fully air-gapped?
Yes. The docs list air-gapped/on-prem as supported with no phone-home. Set FUTURE_AGI_TELEMETRY_DISABLED=1, and block egress at the edge if you need full silence — the census ping still fires once otherwise.

How does it compare to Langfuse for pure tracing?
Langfuse is more mature, has ~17x the community, and is lighter to operate. If tracing and prompt management are all you need, Langfuse is the better tool. Future AGI's advantage only materializes when you also want evals, guardrails, gateway, and simulation in the same system.

Do I have to use the gateway to get tracing?
No. The instrumentation SDKs work independently — register() plus an instrumentor traces your existing client calls with no proxy in the path. The gateway is optional and separately useful if you want provider routing and semantic caching.

What are GEPA and ProTeGi?
They're published prompt-optimization algorithms. Future AGI's agent-opt package implements six of them (GEPA, PromptWizard, ProTeGi, Bayesian, Meta-Prompt, Random), using production traces as training data. This is the most experimental pillar — treat automated prompt rewriting as something to evaluate carefully, not enable blindly against a live agent.

Is it production-ready?
The project says stable is "coming soon" and labels current builds nightly. Real teams are clearly running it — the release cadence and closed-PR count suggest active production users — but I would not put a four-month-old, self-declared-nightly platform in the synchronous request path of a critical system without pinned images, a rollback plan, and a load test of your own.

Sources

future-agi/future-agi on GitHub — README, license, install instructions, telemetry disclosure, and comparison table (retrieved September 7, 2026)
Future AGI release v1.35.0 — release cadence and changelog
Future AGI documentation — evaluation, simulation, guardrails, and gateway references
traceAI instrumentation repo — OpenTelemetry SDK packaging
langfuse/langfuse, Arize-ai/phoenix, Helicone/helicone — comparison star counts and licenses (retrieved September 7, 2026)

Star counts, issue counts, and release dates were pulled from the GitHub API on September 7, 2026 and will drift.

Magnitude Review 2026: Local Models for Coding Agents

Andrew — Sun, 06 Sep 2026 10:13:16 +0000

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

TL;DR

Magnitude is an Apache-2.0 local inference server that does the one job Ollama and LM Studio deliberately leave to you: deciding what to run. It profiles your machine, measures actual memory bandwidth, ranks complete model configurations for that hardware, then downloads, tunes, and serves the one you pick — and writes your coding agent's config file so the agent switches over to it.

Repo: magnitudedev/magnitude — 3,370 stars, 243 forks, TypeScript, Apache 2.0, created June 12, 2026.
Momentum: roughly 1,400 stars in the last week, which is what put it on GitHub Trending.
Maturity: young. CLI is at v0.0.11 (published September 2, 2026), with 0.0.12-alpha.0 already out. Treat it as alpha.
The pitch in one line: it is not a model runner, it is a model chooser that also runs the model.
Harnesses supported: Pi, OpenCode, Hermes, OpenClaw, Codex, Claude Code, Oh My Pi, and Cline — plus an optional built-in harness.
Platforms: macOS and Linux natively; Windows through WSL.

Quick Reference

Item	Detail
Repo	github.com/magnitudedev/magnitude
License	Apache License 2.0
Language	TypeScript (CLI) + Rust inference engine over llama.cpp
Install	`npm i -g @magnitudedev/cli`
Package	`@magnitudedev/cli` (v0.0.11 latest stable)
Service port	`127.0.0.1:10100` (loopback only)
APIs	OpenAI-compatible + Anthropic-compatible
Model format	GGUF
Docs	docs.magnitude.dev
Data dir	`~/.magnitude/`

The Problem Magnitude Actually Solves

Getting a model to run locally has been solved for years. Ollama does it, LM Studio does it, llama.cpp does it. What none of them do is tell you which model to run on your machine.

That gap matters more for agents than for chat, and the reason is structural. A chat session is a few thousand tokens. An agent trajectory accumulates for twenty or thirty turns, and every turn drags along the whole conversation history, every command run, every tool call and result. That context sits in RAM alongside the weights, and on long runs it routinely grows larger than the weights themselves.

Three things follow, and they're why "just use Ollama" is weaker advice for agents than for chat:

Quantization damage is not forgiving. A slightly degraded answer is fine in conversation. There is no partial credit on a tool call — it's either structurally valid JSON or the loop breaks.
Slow speeds compound instead of resetting. 20 tok/s feels fine when you're reading along as it types. Across a twenty-step agent loop, it's unusable.
The agent runs flat out for minutes, which is exactly when memory pressure and thermal throttling appear.

The search space has four interacting axes: which model, how heavily it's compressed, how the runtime is tuned, and how much context you configure. The honest industry practice today is to download twenty gigabytes and find out.

Why you can't just read a spec sheet

Producing one token requires reading the model's weights out of memory. So the ceiling on generation speed is roughly memory bandwidth ÷ size of the weights being read. Compute barely enters into it. That's why a high TFLOPs rating doesn't rescue a slow generation rate, and why configurations copied from a forum post so often disappoint — they were tuned against someone else's memory bus.

Two examples show how sharp the edges are:

Capacity cliffs. Qwen3.6 35B-A3B is an MoE model — 35B total parameters, ~3B active per token — but all experts must be resident when routing picks, so the full 35B sits in memory regardless. At 8-bit that's ~38GB (fine on 64GB, impossible in BF16 at ~70GB). A 16GB machine never loads it at any setting: even 4-bit is ~20GB before a single token of context.
Equal bit depth, unequal damage. Gemma 4 E2B ships as a quantization-aware-training model and holds most of its accuracy at 4-bit. Liquid LFM2.5 2.6B, at the same width, was compressed after training and gives up more. Bit depth tells you file size. It does not tell you what you gave up.

Magnitude's bet is that this decision belongs to the layer that can see the hardware, not to whoever happens to be installing the tool.

How It Works

1. It profiles the machine

Magnitude detects processor, memory, architecture, and acceleration (Metal or CUDA). Then it does the part that separates measurement from arithmetic: it measures achieved memory bandwidth and runs short test inferences to see how the machine behaves in practice — before downloading anything large. Two machines with identical spec sheets can differ on real throughput because of architecture, thermal behavior, and whatever else is competing for memory. The profile is cached and recalibrated when needed.

2. It ranks complete configurations

You don't get a list of models — you get complete configurations, each naming a model, a quantization, a context size, and an expected speed range. Magnitude ranks up to ten of them using model intelligence, estimated generation speed, quantization quality, configured context size, and physical memory.

A Fast ↔ Smart slider sits across the top, and moving it re-runs the recommendation against your hardware rather than just re-sorting a list. Speed is reported honestly as a range like ~36–48 tok/s, not a single flattering number.

3. It runs the model like an agent server, not a chat server

The inference engine is written in Rust on top of llama.cpp, installed and managed by Magnitude, so there's no separate runtime to configure. The agent-specific behavior is where it earns its keep:

On-demand loading. Models stay on disk until requested, then unload when idle or when the machine needs memory. Only the first request after an unload pays load time.
Memory protection. It re-checks free memory before every load and stops a running model if memory gets dangerously low — before inference destabilizes the machine.
Context is preserved, not silently shrunk. Leftover capacity goes to concurrency rather than quietly cutting each request's context. This is a bigger deal than it sounds (see below).
Prefill reuse. In ongoing sessions it reuses compatible prompt state and processes only new input.
Format normalization. Local models differ in reasoning formats, tool-call formats, chat templates, and history conventions. Magnitude normalizes them so a harness can swap models without model-specific code.

The concurrency trap, and why it's the best argument for this tool

Concurrency trades directly against how much context each request keeps. Set it too high on a constrained machine and your context window silently shrinks. Nothing crashes. The logs look fine. The agent just gets quietly worse at long tasks — forgetting what it did ten steps ago — and the natural conclusion is "this model isn't smart enough."

That failure mode is invisible, and it's almost certainly responsible for a chunk of the "local models can't do agentic work" consensus.

Getting Started

The manual path is two commands:

npm i -g @magnitudedev/cli
magnitude setup

Interactive setup profiles the hardware, shows the recommendations, downloads your pick, and connects it to your harness.

The agent-first path is the interesting one — you paste a prompt into the agent you already use:

Set up local models for me with the Magnitude CLI. Install it with
`npm i -g @magnitudedev/cli` (or my package manager), then run
`magnitude docs onboarding` and follow the instructions.

Your agent profiles the hardware, walks you through the options, downloads what you choose, and rewrites its own config to point at the local model. Every non-interactive command supports --json, which is what makes this workable for agents rather than a gimmick.

The CLI worth knowing

magnitude service status              # installation, runtime, active model
magnitude catalog list                # what fits this machine, with state
magnitude catalog pull <model-id>     # install or update a catalog model
magnitude models status               # installed models + residency
magnitude models load <model-id>      # load by canonical ID
magnitude models stop                 # stop the active model
magnitude connections list            # supported + installed harnesses
magnitude connections add claude-code --set-model <model-id>
magnitude connections sync            # refresh harness config
magnitude docs onboarding             # the agent-facing setup workflow

Talking to it directly

The background service listens on loopback at http://127.0.0.1:10100 and speaks two dialects:

API	Base URL
OpenAI-compatible	`http://127.0.0.1:10100/inference/v1`
Anthropic-compatible	`http://127.0.0.1:10100/inference/anthropic`

So anything that speaks either protocol works without adapters:

curl http://127.0.0.1:10100/inference/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma-4-e2b",
    "messages": [{"role": "user", "content": "Refactor this function."}]
  }'

The OpenAI side supports model listing, Chat Completions, and Responses; the Anthropic side supports Messages and token counting. That Anthropic-compatible endpoint is the quiet reason Claude Code drops in cleanly.

Where things live

~/.magnitude/models/                   # managed local models
~/.magnitude/cache/                    # metadata, hardware profiles
~/.magnitude/config.json               # settings and model selections
~/.magnitude/harness-connections.json  # managed harness connections

Deleting ~/.magnitude/cache rebuilds derived data without losing downloaded models. The docs explicitly warn against nuking all of ~/.magnitude as a reflex troubleshooting step.

A Real Run

The most detailed independent walkthrough so far comes from Daily Dose of DS, who ran it on an Apple M5 with 10 cores and 16GB of unified memory. The profile finished in under a minute.

The balanced recommendation came back as Gemma 4 E2B at 4-bit QAT — a 5B dense text-and-vision model holding 50K context in 4.6GB, predicted at 43–51 tok/s, accuracy rated very high. Below it sat Liquid LFM2.5 2.6B and Qwen3.5 4B at various quantization levels.

Two details there show the tool isn't just marketing itself:

Predicted speed is a range, and its bottom sits near the point where an agent loop stops feeling usable. Magnitude doesn't round that up.
The balanced pick had no speculative decoding available, while the model beneath it did. That's a real trade, not a bug — Gemma 4 E2B is faster and more accurate at the same bit depth, and gives up the drafter to get there.

They connected it to the Pi harness, turned off wifi, and had the agent review internal client files for PII. It completed the task offline and correctly, with nothing leaving the machine — the product claim, tested the only way it can honestly be tested.

On speculative decoding

Since reading the weights is the expensive part, the trick is getting more out of each read: a small fast model proposes several tokens ahead, and the real model verifies the whole proposal in one pass. Correct guesses yield several tokens for the cost of one. Whether it pays off depends on the model pairing and your bandwidth — exactly the judgment that needs a hardware profile, which is why Magnitude sets it rather than exposing it as a flag.

Honest Limitations

This is a young project and it shows. Being specific:

It's alpha. v0.0.11 stable, 59 npm versions published, a 0.0.12-alpha.0 already out, and commits landing daily. Expect breaking changes.
Small community, real bus factor. 3,370 stars but only ~21 watchers and 17 open issues on a repo created in June 2026. Most contributions come from a handful of people around founder Tom Greenwald.
GGUF and llama.cpp only. No vLLM, no native MLX, no ExLlama. On Apple silicon an MLX-native path can beat llama.cpp on some models — you give that up for the automation.
Loopback only. The service binds 127.0.0.1, with no documented LAN-serving story. That rules out the homelab "one GPU box, many clients" pattern without your own proxy.
Not a production serving layer. Single-machine, single-user, on-demand loading. For multi-user throughput you still want vLLM.
The catalog is curated. Outside-catalog GGUF models work only via the Hugging Face CLI into the HF cache, followed by a restart to refresh inventory.
Windows is WSL-only.
No published benchmarks. No reproducible suite of its own, so the speed estimates — refreshingly presented as ranges — are the tool grading its own homework.
Physics still applies. A well-chosen 5B model is still a 5B model. Magnitude removes configuration error, not the capability gap against frontier models.

How It Compares

Tool	Chooses the model for you	Agent-tuned serving	Writes harness config	Best for
Magnitude	✅ hardware-profiled ranking	✅ on-demand, memory-guarded	✅	Agents on local models
Ollama	❌ you pick a tag	⚠️ general-purpose	❌	Simplest general local LLM
LM Studio	⚠️ compatibility hints	⚠️ chat-oriented	❌	GUI exploration
llama.cpp	❌	❌ manual flags	❌	Maximum control
vLLM	❌	❌ throughput-oriented	❌	Multi-user GPU serving

Magnitude isn't competing with llama.cpp — it runs llama.cpp. It competes with your afternoon, and with the failure mode where someone tries a local model once, picks a configuration nobody measured for them, and concludes their hardware isn't good enough.

Who Should Use This

Use it if: you want a coding agent running fully offline; compliance, client-data, or air-gap constraints make hosted inference a non-starter; you have decent hardware and don't know what it can run; or you burn tokens on high-volume mechanical work where per-token pricing dominates.

Skip it if: you need frontier-model quality on hard problems; you're serving multiple users; you're on bare Windows; you've already tuned llama.cpp yourself; or you can't tolerate alpha tooling in your critical path.

FAQ

Is Magnitude free and open source?

Yes — Apache License 2.0, all of it, including the inference engine. No token costs, API keys, or rate limits. Your only cost is hardware and electricity.

How is this different from just using Ollama?

Ollama runs the model you name. Magnitude decides which model, quant, and context size to run by profiling your machine, tunes speculative decoding and concurrency for it, and writes your agent's config. As the project's FAQ puts it: an agent setting up Ollama is guessing — it doesn't know your hardware, which quant fits, or how fast it'll go.

Does any data leave my machine?

No. Prompts, files, and models stay local. Once Magnitude and a model are downloaded it runs fully offline — verified in the Daily Dose of DS test with wifi off.

Which coding agents does it work with?

Pi, OpenCode, Hermes, OpenClaw, Codex, Claude Code, Oh My Pi, and Cline, plus an optional built-in harness. Because it exposes OpenAI- and Anthropic-compatible endpoints on 127.0.0.1:10100, most other tools speaking either protocol can be pointed at it manually.

What hardware do I need?

No fixed minimum — Magnitude profiles what you have and recommends accordingly. A 16GB Apple M5 got a usable 5B recommendation at 43–51 tok/s. Memory bandwidth, not core count, sets your token rate.

Can I use models outside the catalog?

Yes. Download compatible GGUF packages into your Hugging Face Hub cache with the HF CLI, then restart Magnitude to refresh inventory.

Do I have to manage it after setup?

No. It runs headless, loads models when the agent needs them, and unloads them when idle or memory tightens. Your agent can install or switch models via the CLI anytime.

Is it production-ready?

Not as a multi-user serving layer, and v0.0.11 says the rest. For a single developer running an agent on their own machine it's usable today — expect frequent updates.

Verdict

Magnitude treats model selection as the product rather than an exercise left to the reader, and it targets the exact seam where local inference keeps failing agent workloads: not "can this run?" but "is this configured for the machine it's running on?"

The measurement-over-arithmetic approach — profiling real bandwidth, running test inferences before downloading 20GB, reporting speed as an honest range, refusing to silently trade context for concurrency — is the right design. The Anthropic-compatible endpoint and --json on every command show it was built for agents to drive, not just for humans to click through.

It's also 0.0.11 software with a three-month-old repo and a small maintainer pool, bound to llama.cpp and loopback. If you want offline agent coding and have hardware you don't understand, install it this week. If you need stable infrastructure, watch it for a few months — but watch it, because this is the layer the local-agent stack has been missing.

Sources

magnitudedev/magnitude — GitHub repository (stars, license, release history)
Magnitude documentation — Models, Inference, Reference
Stop Guessing Which Local Model To Run — Daily Dose of DS (independent M5 walkthrough)
@magnitudedev/cli on npm (version history)

TrueForge Review: Open-Source Agent Harness, 30% Cheaper

Andrew — Sat, 05 Sep 2026 10:11:33 +0000

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

TL;DR

TrueForge is TrueFoundry's open-source agent harness — the runtime layer that sits between a model and a working agent. It owns the execution loop (model calls, MCP tools, skills, sandboxing, approvals, context management, session state) and exposes it three ways: a chat UI, an HTTP API with a TypeScript SDK, and an embeddable UI SDK.

Key facts (verified 2026-09-05):

5,226 GitHub stars, 375 forks, 91 open issues — created 2026-07-23, last push 2026-09-04
MIT licensed, TypeScript, requires Node.js ≥ 22.14; ~31 contributors
Ships as four npm packages (trueforge, -core, -sdk, -ui) plus an OCI Helm chart
Current release train is 0.2.0-rc.0 (2026-08-27) — still pre-1.0
Two modes: local (one process, SQLite) or hosted (Postgres + Redis via Docker Compose, Helm, or Railway)
Vendor benchmark on DevRev's Enterprise-Bench: ~30% cheaper than Claude Managed Agents on the same model, ~2.5× cheaper than deepagents, ~75% cheaper on GLM-5.2
Sandbox is a tool, not the execution environment — the agent loop stays on the server, secrets stay out of the sandbox

The pitch isn't a smarter agent. It's that the loop is the expensive part, and TrueForge argues most harnesses are wasting your money in it.

Why This Matters Now

We've reviewed a lot of harnesses this year, and they mostly cluster into two shapes. There's the terminal-native coding agent — Pi competing on minimalism, DeepSeek Harness on extensibility. And there's the framework you assemble at runtime — LangGraph, deepagents, and friends, where you write the loop yourself.

TrueFoundry's team put the gap plainly in the Hacker News thread, responding to a comparison with Pi:

It's a CLI coding agent that lives in your terminal, built mainly for devs working on a codebase on their own machines. TrueForge is a runtime for building and running general agents. It comes with a server and web UI, plus an SDK and API. So you can build production agents and run them for yourself or your org, self-hosted behind SSO.

That's the actual positioning: not a coding agent, and not a library. A server you deploy, configure once, and hand to an org. The closest thing we've covered structurally is QM, which solves the multi-person scoping problem; TrueForge is aiming at the multi-agent, multi-application problem instead — one runtime, many agents defined as data, consumed over HTTP.

The Benchmark Claim, Examined

This is the part worth reading carefully, because it's the strongest claim and the one most likely to be misread.

TrueFoundry ran 14 L1–L2 tasks from DevRev's Enterprise-Bench — cross-system B2B operations tasks spanning engineering, sales, and support, where each task forces the agent to join data across three MCP servers (a Salesforce-style CRM, a Jira-style tracker, a Drive-style doc store). Every harness got the same model, same three MCP servers, same system prompt, fresh session per task, n = 3 trials, graded by a blind LLM judge that never sees which harness produced the answer.

Configuration	Solved / 14	$ / run	Tokens / run
Claude Managed Agents · Opus 4.8	10.7	$11.8	10.0M
TrueForge · Opus 4.8	10.7	$8.6	3.7M
TrueForge · GLM-5.2	11.7	$3.0	3.8M
deepagents · Opus 4.8	10.0	$21.2	16.5M
deepagents · GLM-5.2	12.0	$9.1	11.9M

The headline is cost, but the token column is the real story. TrueForge solves the same number of tasks as Claude Managed Agents using 37% of the tokens (3.7M vs 10.0M), and roughly 22% of what deepagents burns on Opus. That's not a pricing trick — it's a structurally leaner loop.

Their explanation of why holds up:

Leaner context each turn — a compact instruction instead of heavy scaffolding. deepagents carries planning state, a virtual filesystem, and sub-agent machinery on every turn.
Fewer tool calls — 19 per task, versus 32 and 40 for the other two. Every extra round-trip re-ships the entire growing context.
Compaction instead of replay — history gets trimmed and large tool responses offloaded, rather than re-sent verbatim.

The honest caveats. This is a vendor-run benchmark — TrueFoundry designed the comparison, tuned their own configuration, and published the result. Fourteen tasks at n=3 is a small sample, and the per-task table shows genuine variance (deepagents beats TrueForge outright on eng-l2-a and eng-l2-b; TrueForge wins sales-l2-d and support-l1-b where deepagents scores 0/3). Note too that deepagents on GLM-5.2 scored the highest raw accuracy of any configuration (12.0/14) — TrueForge's own table doesn't hide that. To their credit the benchmark kit is in the repo and points at DevRev's canonical rubric rather than redistributing a private copy, so the claim is falsifiable. Treat it as "plausible and reproducible," not "independently verified."

Architecture: Sandbox as a Tool

The design decision that most separates TrueForge from its peers is where the agent loop lives.

Most sandboxed harnesses — Tilde Run among them — run the whole agent inside a VM or container. TrueForge inverts it: the agent loop stays on the server, and the sandbox is just another tool it can call for code, files, and shell.

Chat UI ─┐
SDK ─────┼─→ TrueForge server ─→ SQLite | Postgres+Redis
UI SDK ──┘      (agent loop)    ─→ models (BYO)
                     │           ─→ MCP servers
                     └─────────→ sandbox (Daytona) — provisioned on demand

Two consequences fall out of that:

Secrets stay in the harness. Your API keys and MCP OAuth tokens never enter the sandbox, so a prompt-injected agent that gets shell access still can't read your credentials off disk.
Compute is provisioned only when needed. A conversational agent that never writes code never spins up a sandbox at all. Skills and Code Mode require one; nothing else does.

The tradeoff: you're depending on an external sandbox provider. Today that means Daytona, with "more providers planned." If you need fully air-gapped execution right now, that's a real gap.

Context Engineering: The Actual Product

Strip away the UI and TrueForge is a set of opinions about what the model sees each step. The docs split it into two phases, and the distinction is genuinely useful even if you never run TrueForge.

Input context is loaded at the start of every run and is mostly static: instructions, skills, MCP tool definitions.

Skills are git-backed SKILL.md instruction packs. Critically, each attached skill contributes only its name and description to context — the full body is read from the sandbox on demand when the agent decides it's relevant. That's progressive disclosure, and it's the same pattern that makes agent skills scale past a handful.
MCP tool definitions are the sneaky context killer. Name, description, input schema, and output schema all cost tokens, and a few MCP servers exposing dozens of tools each can eat a large chunk of the window before the user types anything. TrueForge defaults to preload: false: each server contributes only its name and description, and individual tool schemas get discovered on demand.

Runtime context is what accumulates during the run — user messages, tool calls, tool results, subagent output. This is what compaction, large-result offloading, and subagents manage.

The docs also give the single best piece of prompt advice in the whole project, which applies regardless of harness:

Don't duplicate MCP tool docs or skill content — the harness already injects those. Move long procedures into skills — anything that reads like a workflow or playbook belongs in a skill, not the instructions.

Getting Started

Local mode is genuinely one command:

npx @truefoundry/trueforge@latest

That gives you one process backed by SQLite, a chat UI, and the HTTP API. Connect a model provider (OpenAI, Anthropic, Gemini, or any OpenAI-compatible endpoint), point it at some MCP servers, and you have a working agent.

Read the warning before you get clever with it. The README is unusually blunt:

Local mode is for your machine only... There is no login by default, and data lives in a local SQLite file. Please keep it on localhost.

For anything shared, hosted mode means Postgres + Redis via Docker Compose, the Helm chart, or Railway, with optional OIDC login.

Agents themselves are data, not code — an AgentSpec you POST once and reference by name:

{
  "model": {
    "name": "anthropic/claude-sonnet-4-6",
    "params": { "max_tokens": 4096 }
  },
  "instructions": "You help customers with orders. Look up order details before taking action. Always confirm before processing refunds.",
  "mcp_servers": [
    {
      "name": "orders-api",
      "enable_tools": ["get_order", "process_refund"],
      "require_approval_for_tools": ["process_refund"]
    }
  ],
  "config": { "iteration_limit": 25 }
}

Note require_approval_for_tools — human checkpoints are a field on the spec, not something you wire up yourself. Same for iteration_limit, which is your runaway-loop circuit breaker.

The SDK's mental model is a clean hierarchy: one Agent → many Sessions → many Turns → many Events → some Deltas. An agent is a reusable definition; a session is one issue worked through (persist its id and the user resumes tomorrow); a turn is one request; events stream out (turn.created, model.message, tool.response, tool.approval_required, turn.done), with deltas as the streaming chunks. Turns chain automatically via previous_turn_id: "auto", so you never resend history — a small API decision that eliminates a whole class of bugs.

Who Should Use This

Good fit:

Teams that need several agents behind one runtime, consumed by apps over HTTP rather than by one developer in a terminal
Anyone who wants model portability as a structural property — the benchmark's GLM-5.2 column is the argument, and in 2026 the best-value model changes roughly monthly
Orgs with self-hosting or SSO requirements that rule out Claude Managed Agents outright
Teams currently on deepagents/LangGraph who are feeling the token bill and would rather configure a loop than maintain one

Poor fit:

Solo devs who want a coding agent in their terminal — use Pi or a CLI agent; TrueForge's own team says so
Python-first shops — the SDK is TypeScript, and while the HTTP API is language-neutral, the ergonomics aren't there yet
Anyone needing air-gapped sandboxing today (Daytona-only)
Teams that can't run pre-1.0 software in production. It's 0.2.0-rc.0 with 91 open issues, six weeks old

Honest Limitations

Pre-1.0, and young. Created 2026-07-23. The changelog still contains things like "migrate persisted legacy token thresholds" — schema churn is ongoing.
Self-reported benchmarks. Reproducible, but designed and run by the vendor. See the caveats above.
Single sandbox provider. Daytona today.
Commercial parent. TrueFoundry is a paid platform company. The MIT license is real and the company insists it's "not a cut-down free tier with the good parts held back" — but the open-core funnel risk is the standard one, and worth pricing in.
Local mode has no auth. Easy to misdeploy; the README warns you, but warnings in READMEs have a poor track record.

FAQ

What is an agent harness, exactly?
The runtime layer between an LLM and a working agent: it runs the loop of model call → tool call → result → model call, while managing session state, context size, tool permissions, and sandboxing. A framework makes you assemble that; a harness ships it.

How is TrueForge different from LangGraph or deepagents?
deepagents is a framework you build a loop with; TrueForge is a server you deploy that already has one. Practically, TrueForge's benchmark shows it using 3.7M tokens per task versus deepagents' 16.5M on the same model — mostly from compaction and deferred tool loading rather than replaying accumulated context every step.

Is TrueForge really free?
Yes — MIT licensed, all four npm packages and the Helm chart. You pay for your own model tokens, infrastructure, and sandbox provider.

Can I use open models instead of Claude or GPT?
Yes, and that's the main cost argument. Any OpenAI-compatible endpoint works. The vendor benchmark puts GLM-5.2 at $3.0/run versus $8.6 for Opus 4.8 — with higher measured accuracy (11.7 vs 10.7 of 14).

What do I need to run it?
Node.js ≥ 22.14 and npx @truefoundry/trueforge@latest for local mode. Hosted mode needs Postgres and Redis, deployable via Docker Compose, Helm, or Railway. A Daytona sandbox is only required for skills and Code Mode.

Does it support MCP OAuth?
Yes — remote MCP servers with header auth or OAuth, including in-chat authorization, where the agent surfaces a Connect button mid-conversation when a connector needs authorizing.

Is it production-ready?
Hosted mode is the supported path, with OIDC login and multi-replica Postgres/Redis. But at 0.2.0-rc.0 and six weeks old, pin your versions and expect breaking changes. Local mode is explicitly not production.

Sources

truefoundry/trueforge on GitHub — README, releases, license (verified 2026-09-05)
TrueForge Benchmarking — Enterprise-Bench methodology and results
TrueForge Harness Capabilities — context engineering, sandbox-as-tool
TrueForge SDK Concepts — Agent/Session/Turn/Event model, AgentSpec
TrueForge – The open-source agent harness — Hacker News discussion

GitNexus Review: A Knowledge Graph for Your AI Agent

Andrew — Fri, 04 Sep 2026 10:12:15 +0000

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

TL;DR

GitNexus indexes a codebase into a knowledge graph — every call, import, inheritance edge, and execution flow — then exposes that graph to AI agents through MCP tools. It sits at roughly 47,000 stars and 5,150 forks, was created on August 2, 2025, and shipped v1.6.10 on August 27, 2026. The short version:

It is not a search tool. Semantic search finds files that look relevant. GitNexus answers "what breaks if I change this function" from a precomputed dependency graph. Different question, different machinery.
The MCP server is the product. Seventeen tools — impact, trace, context, detect_changes, rename, cypher, and more — callable from Claude Code, Cursor, Codex, Cline, Roo Code, and Windsurf.
Two-command setup: npx gitnexus analyze then npx gitnexus setup. The first indexes and writes AGENTS.md/CLAUDE.md; the second writes MCP config for every editor it detects.
The design bet is "precomputed relational intelligence" — do the clustering and tracing at index time so one tool call returns a complete answer instead of a ten-query exploration chain.
The big catch: it is not open source. GitNexus ships under the PolyForm Noncommercial License 1.0.0. Personal projects and evaluation are fine; using it at your job is not, without a commercial license.
Other honest catches: npm 11 can crash the install, indexing is memory-bound on large repos, the browser UI caps out around 5,000 files, and there are 320 open issues.

The problem it targets

Every coding agent has the same blind spot. Claude Code, Cursor, and Codex are excellent at reading the files you point them at, and they are good at grepping for more. What they cannot cheaply do is know the shape of a repository they have only partially read.

The README states the failure mode bluntly:

AI edits UserService.validate()

Doesn't know 47 functions depend on its return type

Breaking changes ship

This is not a model-intelligence problem but a retrieval problem. The information needed to avoid that mistake exists in the codebase, but finding it requires traversing a call graph the agent never built. So the agent either burns context on exhaustive searches, or guesses.

GitNexus's answer is to build the graph once, ahead of time, and hand the agent structured answers instead of raw material.

Precomputed relational intelligence

The interesting architectural claim is not "knowledge graph" — plenty of tools index code into graphs. It is where the reasoning happens.

Conventional Graph RAG hands the LLM a graph and lets it explore. Ask "what depends on UserService?" and the model issues a query for callers, another to resolve files, another to filter out tests, another to score risk. Four-plus round trips, each one spending tokens and each one a chance to stop early with an incomplete answer.

GitNexus does that work at index time. Clustering, tracing, and confidence scoring are already computed, so impact UserService --upstream returns "8 callers, 3 clusters, all above 90% confidence" in a single call. The maintainer's framing is that this buys three things: reliability (the model can't fail to explore, because exploration already happened), token efficiency (no query chains), and model democratization (smaller models perform better when the tool does the reasoning).

That last claim has some independent support. In an r/vibecoding thread comparing GitNexus to alternatives, one user testing it for exactly this reported that "lower-tier models get a little better with it" — which is the predicted result if the tool is genuinely offloading reasoning rather than just relocating it.

Getting it running

The install path is two commands from the repo root:

# 1. Index your repo
npx gitnexus analyze

# 2. Connect your editors (auto-detects Claude Code, Cursor, Codex, …)
npx gitnexus setup

analyze does more than parse. It indexes the codebase, installs agent skills, registers Claude Code hooks, and writes AGENTS.md / CLAUDE.md context files. setup writes the MCP configuration.

Two practical notes that will save you time. First, install globally before running setup:

npm install -g gitnexus
gitnexus setup

This writes an absolute-path MCP config that bypasses npx entirely. On a cold cache, an npx-based MCP launch can exceed Claude Code's default MCP_TIMEOUT of roughly 30 seconds, and you get a server that mysteriously fails to start.

Second, if you are on npm 11.x, npx can crash during install with Cannot destructure property 'package' of 'node.target'. That is an npm/arborist bug that fires before GitNexus runs at all (issue #1939). The documented workaround is pnpm, which builds the native dependencies explicitly:

pnpm --allow-build=@ladybugdb/core --allow-build=gitnexus \
     --allow-build=tree-sitter dlx gitnexus@latest analyze

No C++ toolchain on the machine? Set GITNEXUS_SKIP_OPTIONAL_GRAMMARS=1 before installing. You lose Dart, Proto, Swift, and Kotlin parsing, and the install finishes in seconds without needing python3/make/g++. Note the value must be exactly 1 — anything else falls through to a full rebuild.

The tool surface

Seventeen MCP tools ship in the current release. The ones that earn their keep day to day:

Tool	What it does
`query`	Process-grouped hybrid search (BM25 + semantic + RRF)
`context`	360-degree symbol view — categorized refs, process participation
`impact`	Blast-radius analysis with depth grouping and confidence scores
`trace`	Shortest directed path between two symbols
`detect_changes`	Git-diff impact — maps changed lines to affected processes
`rename`	Multi-file coordinated rename using graph + text search
`cypher`	Raw Cypher queries against the graph
`route_map`	Which components fetch which API endpoints, and the handlers
`shape_check`	Validates API response shapes against consumers' property access
`api_impact`	Pre-change impact report for a route handler

shape_check deserves a callout because it catches a specific, expensive bug class: the backend changes a response field, the frontend keeps reading the old property, nothing fails at build time, and it breaks in production. Checking response shapes against actual consumer property accesses is exactly the kind of cross-boundary reasoning agents are bad at unaided.

Index with --pdg and you unlock two more: pdg_query for statement-level control and data dependence, and explain for taint analysis — tracing source-to-sink data flows. That is genuine program-dependence-graph territory, not just a call graph.

Alongside tools, GitNexus exposes MCP resources (gitnexus://repos, gitnexus://repo/{name}/clusters, .../processes, .../schema) and prompts (detect_impact for pre-commit analysis, generate_map for architecture docs with mermaid diagrams).

The skills layer

This is where GitNexus goes further than its peers. Beyond static tools, it installs slash-command skills that chain them into workflows:

/gitnexus-plan — implementation-ready engineering plans backed by the graph and PDG slices
/gitnexus-work — executes a plan as impact-checked, detect_changes-gated atomic commits
/gitnexus-review — graph-backed review of a PR, branch, or local diff, with a taint pass
/gitnexus-lfg — the full pipeline: plan → user gate → work → review

The genuinely clever piece is repo-specific generated skills. Run gitnexus analyze --skills and GitNexus applies Leiden community detection to find the functional areas of your codebase, then writes each one as a project skill under .claude/skills/gitnexus-area-<name>/. Each generated skill documents that module's key files, entry points, execution flows, and cross-area connections — and gets regenerated on every --skills run, so it doesn't rot the way hand-written docs do.

If the repo has an .agents/ directory, the skills are mirrored to .agents/skills/ so tools like Codex that read repo-local skills stay in sync.

CLI versus browser

There are two ways to run GitNexus, and they are not equivalent.

	CLI + MCP	Web UI
For	Daily development in your editor	Quick exploration, demos, one-offs
Scale	Full repos, any size	~5,000 files (browser memory)
Storage	LadybugDB native, persistent	LadybugDB WASM, per-session
Parsing	Tree-sitter native bindings	Tree-sitter WASM
Install	`npm install -g gitnexus`	None — gitnexus.vercel.app

The web UI answers "what is this repo?" about someone else's project in ninety seconds. But the CLI is the real tool. gitnexus serve bridges the two — the web UI auto-detects a local server and browses your CLI-indexed repos without re-indexing.

How it compares

GitNexus's own positioning is "like DeepWiki, but deeper" — DeepWiki helps you understand code, GitNexus lets you analyze it, because a graph tracks relationships rather than descriptions.

Against the tools we've reviewed here, the distinction is retrieval strategy. Claude Context does semantic search over embeddings — great for "where is the thing that does X," weaker for "what else touches it." Graft builds a code graph with a similar thesis but a lighter tool surface. Serena works through LSP symbols, which gives precise definitions and references but no clustering or execution-flow modeling.

GitNexus is the heaviest of the four: slowest to index, most to install, and by some distance the most it can tell you. That trade scales with codebase size. On a 5,000-line project, ripgrep and a good model are fine. On a 500,000-line monolith where nobody remembers what calls what, the graph is the point.

Honest limitations

It is not open source. This is the headline caveat and it is easy to miss, because the project is described as open source nearly everywhere it is discussed — including in the Reddit and press coverage. The LICENSE file is the PolyForm Noncommercial License 1.0.0, which grants rights only "for any permitted purpose," and permitted purposes exclude commercial use. Personal projects, research, and evaluation are fine. Indexing your employer's codebase is not, absent a commercial license from Akon Labs. GitHub's own license detector returns NOASSERTION for the repo, which is why so much downstream coverage assumes MIT. Check with whoever owns licensing at your company before you run analyze on work code.

Indexing is memory-bound. On large repositories the indexer is the constraint. The project's own Render blueprint notes that if the server OOMs you need a bigger plan — standard gives 2 GB, pro gives 4 GB. Locally this means a big monorepo can be an unpleasant first run.

The hosted deploy has a thin security story. The one-click Render blueprint costs about $35/month ($25 server + $7 web + $2.50 for a 10 GB disk) and protects everything with a single GITNEXUS_SERVE_AUTH_TOKEN. The web proxy strips Origin before forwarding, which means the server's CSRF guard does nothing for proxied traffic by design. The token is the only control, and anyone holding it can read every indexed repo. That is documented honestly in SECURITY.md, but it means the hosted path is not a multi-tenant story.

Install has sharp edges behind a proxy. onnxruntime-node's postinstall fetches optional CUDA binaries from api.nuget.org and ignores HTTP_PROXY/HTTPS_PROXY (issue #2370). It no longer breaks installs — the embedding stack is optional and self-heals on first gitnexus analyze --embeddings — but that path needs Node ≥ 22.15 (22.x) or ≥ 23.5 (23.x). On older Node, install with ONNXRUNTIME_NODE_INSTALL=skip.

320 open issues. Fast-moving project, large surface area. The README's install-notes section is unusually long — both a good sign (documented) and a warning (they exist).

Codex needs care. Newly installed hooks need one-time approval via /hooks, and you must pick one install route — plugin hooks load alongside ~/.codex/hooks.json, so installing both fires duplicate hooks on every tool call.

A scam warning worth repeating. The README opens by stating GitNexus has no official cryptocurrency or token, and anything using the name on Pump.fun is unaffiliated. At 47,000 stars, impersonation follows.

Who should use it

Good fit: large, unfamiliar, or long-lived codebases; agents that keep breaking things three modules away; refactors where you want blast-radius analysis first; architecture docs that regenerate instead of rotting.

Poor fit: projects small enough to hold in context; anyone needing a permissive license for commercial use; constrained machines where indexing cost outweighs the benefit.

FAQ

Is GitNexus free?
Free to download and use for noncommercial purposes. It is licensed under PolyForm Noncommercial 1.0.0, not an OSI-approved open source license, so commercial use at a company requires a separate license from Akon Labs. Much of the coverage online calls it "open source" — that framing is inaccurate.

How is this different from semantic code search?
Semantic search retrieves code that resembles your query. GitNexus answers structural questions — what calls this, what breaks if I change it, what path connects these two symbols — from a graph of actual relationships. They solve different problems and can be used together.

Which AI coding tools does it support?
Claude Code, Cursor, Codex, Cline, Roo Code, Windsurf, Antigravity, and OpenCode are all auto-detected by gitnexus setup. Anything that speaks MCP can use the server; you can also write the config manually.

Do I have to re-index when I change branches?
No. Omitting the branch parameter queries the workspace index, which follows your checked-out working tree. Switching branches and re-running gitnexus analyze updates it incrementally. You can also pin dedicated indexes with gitnexus analyze --branch.

Does my code leave my machine?
In CLI mode, no — indexing and storage are local, in LadybugDB. The web UI runs entirely in-browser with WASM. The exception is the hosted Render deploy, where indexed repos live on that server and are protected by a single shared token.

What is the --pdg flag for?
It builds a program dependence graph alongside the knowledge graph, enabling pdg_query for statement-level control and data dependence, and explain for taint analysis showing source-to-sink data flows. It makes indexing slower, so it is opt-in.

Verdict

GitNexus is the most complete implementation of "give the agent a map" that we have looked at. The precomputed-intelligence design is the right instinct — moving graph traversal from inference time to index time is what makes the results reliable rather than merely available, and the generated per-area skills are a genuinely novel idea that other tools should copy.

The reservations are practical rather than architectural. It is heavy, the install has real sharp edges, and — most importantly — the noncommercial license means a large share of the developers reading about it cannot legally use it for the work where it would help most. That is the project's choice to make, and the enterprise offering is presumably the business model. But it should be stated plainly, because almost nobody else covering this tool is stating it at all.

If you are working on personal projects in a large codebase, index it today. If you are at a company, talk to legal first.

Sources

GitNexus on GitHub — README, tool reference, install notes, and SECURITY.md (v1.6.10, August 27, 2026)
PolyForm Noncommercial License 1.0.0 — the license in the repo's LICENSE file
r/mcp — "Building opensource Zero Server Code Intelligence Engine" — maintainer's launch thread
r/vibecoding — GitNexus vs Codegraph for codebase context — user reports on token savings and smaller-model performance
MarkTechPost — MCP-native knowledge graph engine — independent coverage of the architecture
GitHub REST API — star, fork, and issue counts as of September 4, 2026

OpenSEO Review: The Open-Source Ahrefs Your Agent Uses

Andrew — Thu, 03 Sep 2026 10:11:56 +0000

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

TL;DR

OpenSEO is an MIT-licensed SEO platform that positions itself as the open-source alternative to Semrush and Ahrefs. It sits at roughly 16,500 stars and 2,000 forks after being created on February 27, 2026, shipped v0.1.7 on September 2, 2026, and has been climbing GitHub trending through early September. The short version:

It is not a crawler. OpenSEO is a UI, workflow engine, and MCP server on top of DataForSEO. You bring your own API key and pay per query. Understanding that one fact resolves most of the arguments about it.
The MCP server is the actual product. ~20 tools covering keyword research, SERPs, backlinks, rank tracking, domain footprints, local/Maps rank grids, and first-party Google Search Console data — callable from Claude Code, Cursor, Codex, and Claude Desktop.
Nine Agent Skills ship alongside the MCP, so your agent knows how to run keyword clustering or link prospecting, not just which endpoint to hit.
Self-hosting is genuinely free — Docker or Cloudflare Workers (works on Cloudflare's free plan). The hosted version is $10/month including $10 of usage, funded by a ~28% markup on DataForSEO calls.
Real cost math: ~$0.05 per keyword search, ~$0.08 per backlink domain overview, ~$1.09 per ChatGPT brand-visibility check. Ahrefs' cheapest plan is $129/month.
The honest catches: Docker self-hosting runs with authentication disabled by default, DataForSEO's minimum top-up is $50, it's pre-1.0 with 135 open issues, and the architecture is Cloudflare-shaped in ways that matter if you host elsewhere.

What OpenSEO actually is

The origin story is refreshingly literal. The maintainer, Ben Senescu of Every App, posted in r/TechSEO asking whether an open-source tool wrapping DataForSEO would be useful. People said yes. He posted the working build the following week.

That framing — a wrapper, deliberately — is the key to evaluating it fairly. Ahrefs and Semrush are expensive largely because they operate their own web crawlers and maintain proprietary link indexes. That is a capital-intensive moat, and no MIT-licensed weekend project is going to replicate it.

OpenSEO doesn't try. It rents the data layer from DataForSEO — which the Product Hunt discussion describes as "the gold standard for backlinks + keyword data outside of Ahrefs and Semrush" — and competes on the two layers above it: workflow design and agent access.

The README's own pitch is blunt about the target user:

OpenSEO is an SEO tool for the people. If tools like Semrush or Ahrefs are too expensive or bloated, OpenSEO is a pay-as-you-go alternative that you actually control.

The core workflows are keyword research, rank tracking, competitor insights, backlinks, site audits, and AI visibility.

The economics, concretely

This is where OpenSEO makes its strongest argument, so it's worth putting real numbers on the table. From the project's own pricing estimator:

Operation	Approximate cost
Keyword search (typical result limits)	~$0.05
Backlink domain overview (1 year history)	~$0.08
ChatGPT brand-visibility check	~$1.09
Rank tracking	fractions of a cent per keyword check
Google Search Console data	free — first-party, no credits

A worked example from their estimator: 100 keyword searches, 20 backlink checks, and weekly rank tracking on 50 keywords lands around $7.12/month of usage — comfortably inside the $10 that the hosted Base Plan already includes.

Against Ahrefs' entry plan at $129/month, that's an order of magnitude. But the comparison only holds for a specific user: someone doing bursty, project-shaped research rather than continuous large-scale monitoring. Run enough site audits or ChatGPT brand checks and pay-as-you-go stops being cheap — that's the nature of metered billing, and it cuts both ways.

Two caveats the marketing page doesn't lead with:

DataForSEO's minimum top-up is $50. New accounts get $1 of free credit to test. So "pay only for what you use" has a $50 on-ramp when self-hosting.
Self-hosting is free; the hosted version requires an active subscription. Top-up credits roll over indefinitely, but the $10 of included monthly usage resets each cycle.

Getting it running

Two supported paths, and the docs are opinionated about which to pick.

Docker — for trying it on your own machine:

git clone https://github.com/every-app/open-seo
cd open-seo
cp .env.example .env
# set DATAFORSEO_API_KEY in .env
docker compose up -d

It pulls ghcr.io/every-app/open-seo:latest and serves on port 3001 (first start takes 1–2 minutes). Follow along with docker compose logs -f.

Read this before exposing it anywhere. Docker mode sets AUTH_MODE=local_noauth — no auth checks at all, with a local admin user admin@localhost. The compose file binds to 127.0.0.1 by design. The docs are explicit:

Only expose it behind your own auth-protected reverse proxy, tunnel, or private network.

That's a sane default for local use and a genuine footgun if you casually stick it behind a tunnel. If you want internet-facing multi-device access, the project steers you to the Cloudflare path instead, which provisions Cloudflare Access and gates sign-in on an allowlist:

# .env.selfhost
DATAFORSEO_API_KEY=
ACCESS_ALLOWED_EMAILS=you@example.com

Optional keys unlock the rest: GOOGLE_CLIENT_ID / GOOGLE_CLIENT_SECRET / BETTER_AUTH_SECRET for Google Search Console, and OPENROUTER_API_KEY for SAM, the in-app SEO agent (hidden entirely if unset).

On telemetry: OpenSEO sends anonymized heartbeats — aggregate install/user/project/feature counts against a random install ID, every 5 minutes for the first two hours, then at most daily. The docs state that no URLs, keywords, prompts, emails, or IP-derived location are collected, and idle installs send nothing. Opt out with OPENSEO_TELEMETRY_DISABLED=1 or the standard DO_NOT_TRACK=1, then force-recreate the container. Documented and easy to disable is about as good as telemetry gets.

The MCP layer is the real differentiator

Plenty of projects wrap DataForSEO. What makes OpenSEO interesting in late 2026 is that it was built MCP-first rather than bolting an API onto a dashboard.

Connecting Claude Code is one line:

claude mcp add --transport http --scope user openseo https://app.openseo.so/mcp

Cursor takes the usual mcp.json entry:

{
  "mcpServers": {
    "openseo": {
      "url": "https://app.openseo.so/mcp"
    }
  }
}

Codex CLI:

codex mcp add openseo --url https://app.openseo.so/mcp

For CI and headless environments, API keys work instead of OAuth:

export OPENSEO_API_KEY=oseo_YOUR_KEY
codex mcp add openseo --url https://app.openseo.so/mcp \
  --bearer-token-env-var OPENSEO_API_KEY

Note the security posture the docs state plainly: API keys are personal — anything an agent does with your key acts as you in your workspace. Scope accordingly before wiring one into an unattended pipeline.

The exposed toolset is broader than "keyword lookup." It covers live Google organic SERPs, exact keyword/page/rank/volume/CPC/intent rows for a domain, SERP competitor comparison across a keyword set, backlink and referring-domain overviews, saved-keyword management, rank tracker configs, and a surprisingly deep local-SEO block — Maps and Local Finder SERPs, Google Business Profile audits, review collection, category-slug lookup, and Maps rank at each point of a geographic grid around a business.

Two tools stand out for agent workflows specifically:

Google Search Console — performance data (clicks, impressions, CTR, position) plus URL inspection for index status, crawl, and canonical, up to 10 URLs per call. First-party, and it doesn't consume credits.
Project context — a shared, free, credit-less store for business description, goals, positioning, writing preferences, competitors, key pages, and a research log. Your agent reads and writes it.

That last one is the quiet good idea. The failure mode of agentic SEO is an agent that re-derives your positioning from scratch on every invocation and produces subtly inconsistent recommendations. A persistent context object that every skill reads from is the right structural fix.

Agent Skills: telling the agent how

MCP gives an agent access to data. It doesn't teach judgment. OpenSEO ships nine Agent Skills — SKILL.md files following the open Agent Skills standard — for that second half.

The Claude Code and Codex plugins install MCP and all nine skills together, which is the recommended path over adding MCP alone. The skills cover SEO project setup, an SEO coach for people who don't know which workflow to run, keyword research, competitive landscape mapping, single-competitor analysis, keyword clustering, and link prospecting.

The docs give one piece of advice worth repeating for any agent tooling:

Start with one focused workflow instead of asking your agent to "do SEO" broadly.

Under the hood the repo is a modern Cloudflare-native TypeScript stack: TanStack Start and Router, Drizzle ORM, better-auth, Cloudflare Workers with an Alchemy deployment layer, daisyUI, recharts, and OpenRouter for the AI features. Roughly 17 contributors, 36 documented release notes, and a Playwright e2e suite.

Honest limitations

It's a client, not an index. No proprietary crawler, no independent link graph. Your data quality ceiling is DataForSEO's. If you specifically need Ahrefs' link index, this is not a substitute at any price.

Docker mode ships without auth. Documented, deliberate, and still the most likely way someone gets burned.

It's pre-1.0. Version 0.1.7, 135 open issues. A commenter in r/SEO noted that "the issue for me was the amount of dependency issues it had at the time" and went with a paid alternative — though that was an earlier build, and the release cadence since has been brisk.

The $50 DataForSEO floor undercuts the pay-as-you-go pitch for anyone wanting to spend $5 and stop.

Cloudflare-shaped architecture. The docs recommend Cloudflare over Railway, Coolify, or Dokploy unless you're already confident self-hosting, and note that broader platform support is planned "in the next few months." Workers-oriented dependencies mean this is not a drop-in for an arbitrary VPS today.

Volume without filtering is noise. A Reddit commenter pushed back on 100-related-keyword expansions: "I used a similar keyword expansion tool once and ended up spending more time filtering than actually building pages. If it's research-only, keep it tight and focus on intent, not just volume." That's a critique of the whole category, but it applies here — and it's exactly where the clustering skill has to earn its keep.

ChatGPT brand checks are the expensive button. At ~$1.09 each, a daily automated check across a keyword set is a real line item. Budget it deliberately.

Who this is actually for

Good fit: indie hackers, founders, and small teams who need real keyword and backlink data a few times a month and can't justify $129/month. Anyone running an agentic content pipeline who wants their coding agent to query SEO data directly. Teams already pushing volume through DataForSEO — as one Product Hunt commenter put it, self-hosting becomes "a real cost-control lever" when you're not paying twice for the same data. And anyone who wants to fork it: the README openly invites you to "fork and vibe code your own custom tool."

Poor fit: agencies needing enterprise reporting, white-labeling, and SLAs. Anyone dependent on Ahrefs' specific link index. Teams without someone comfortable running Docker or Cloudflare Workers. High-volume continuous monitoring, where metered billing loses to a flat subscription.

The strategic read: OpenSEO is a bet that the SEO tool of 2027 is not a dashboard you log into, but a data layer your agent queries while it writes. On that axis it's ahead of the incumbents — and it's the reason a pre-1.0 project cleared 16,000 stars in six months.

FAQ

Is OpenSEO really free?
The software is MIT-licensed and free to self-host. The data isn't — you need a DataForSEO API key and pay them per query ($1 free credit to start, $50 minimum top-up after). The hosted version is $10/month including $10 of usage.

How is it cheaper than Ahrefs?
It doesn't operate a crawler or link index. It resells DataForSEO metered per call, so you pay for the queries you make instead of a flat $129/month for capacity you may not use. Heavy continuous use erodes that advantage.

Can Claude Code actually use it?
Yes — that's the headline feature. claude mcp add --transport http --scope user openseo https://app.openseo.so/mcp connects it, and the Claude Code plugin adds MCP plus all nine Agent Skills in one install. Cursor, Codex CLI, and Claude Desktop are also supported.

Is self-hosted OpenSEO safe to expose to the internet?
Not the Docker path as shipped — it runs AUTH_MODE=local_noauth with no auth checks. Put it behind your own authenticated reverse proxy or private network, or use the Cloudflare path, which provisions Cloudflare Access with an email allowlist.

Does it send my data anywhere?
Anonymized telemetry only: aggregate counts against a random install ID. The docs state no URLs, keywords, prompts, emails, or location data are collected. Disable with OPENSEO_TELEMETRY_DISABLED=1 or DO_NOT_TRACK=1. Your SEO queries go to DataForSEO, since that's where the data comes from.

Is it production-ready?
For a solo operator or small team, yes with caveats — it's at v0.1.7 with 135 open issues and active weekly releases. For agency work with client SLAs, wait for 1.0.

Sources

every-app/open-seo on GitHub — README, license, release history (v0.1.7, September 2, 2026)
OpenSEO MCP documentation — client setup, full tool list, API key auth
Docker self-hosting guide — auth mode, telemetry, image pinning
OpenSEO pricing estimator — per-operation costs and the 28% hosted markup
r/TechSEO launch thread and Product Hunt discussion — community reactions

Colibri Review: Run a 744B Model on Hardware You Own

Andrew — Wed, 02 Sep 2026 10:11:02 +0000

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

TL;DR

Colibrì is a pure-C inference engine that runs frontier Mixture-of-Experts models — 744B to 2.8T parameters — on hardware you already own, by treating VRAM, RAM, and NVMe as one memory hierarchy instead of one memory requirement. It went from first commit on 2026-07-01 to 26,662 stars in two months.

26,662 stars, 2,920 forks, Apache-2.0, written in C with zero engine dependencies
Eight model families run today: GLM-5.2 (744B), Inkling (975B), Kimi K3 (2.8T), GLM-5.3-Flash (321B, vision), DeepSeek V4 Flash (284B), Qwen3.8-Flash-Next (125B), Qwen3.6 (35B-A3B), OLMoE (7B)
No GPU required for any of them — a GPU only ever makes it faster
The trick: a 744B MoE activates only ~40B params per token, and only ~11 GB changes between tokens
Real measured range: 0.05 tok/s on a 25 GB dev box, ~1.8 tok/s on a 128 GB CPU desktop, 5.8–6.8 tok/s on 6× RTX 5090
The catch: you need 372 GB of disk for GLM-5.2 (1.6 TB for Kimi K3), and decode speed is set by your SSD

This is not a way to get ChatGPT speeds for free. It is a way to hold a frontier model instead of renting one — and to watch every expert fire while it answers you.

Quick Reference

Field	Value
Repo	JustVugg/colibri
Site	justvugg.github.io/colibri
License	Apache-2.0
Language	C (single file per engine)
Created	2026-07-01
Latest release	v1.10.1 (2026-08-31)
Stars / forks	26,662 / 2,920
Open issues	97
Runtime deps	none (Python only for the converter and API gateway)
Reference model	GLM-5.2 int4-gs64, ~372 GB

The Core Idea: Placement, Not Residency

Every "you need 8× H100" claim assumes the whole model must sit in fast memory at once. For a Mixture-of-Experts model, that assumption is wrong in an exploitable way: GLM-5.2 has 744B total parameters but activates roughly 40B per token — about 5.4%. Colibrì splits the model along that line:

The dense part (attention, shared experts, embeddings — ~17B params) stays resident in RAM at int4, about 9.9 GB.
The 19,456 routed experts (75 MoE layers × 256, plus the MTP head, ~19 MB each at int4) live on disk — ~370 GB — and get streamed on demand.

The README's framing is the clearest one I've seen: think of it as a JIT, but for weights. A compiler JIT never compiles the whole program; it watches what actually runs and compiles the hot paths just in time. Colibrì makes the same bet about a 744B parameter space — parameters are not resident state to be held, they are data to be staged across VRAM/RAM/NVMe exactly when the router proves they're needed.

The load-bearing commitment: placement only ever decides speed. Insufficient fast memory makes it slower; it must never quietly redefine the model.

What Makes It Fast Enough to Bother

A naive "read the expert when you need it" loop would be unusable. Most of the engine's cleverness goes into avoiding and overlapping disk misses:

Batch-union reads. Each expert's three matrices are stored adjacent and read in one pread; batched positions read each unique expert once.
Router lookahead (PILOT=1). A thread runs the router one layer ahead and prefetches. Routing is measurably 71.6% predictable one layer ahead — that predictability is the whole reason this works.
A learning cache. The engine records which experts your workload routes to in .coli_usage, updated every turn, and pins the hottest automatically. It literally gets faster the more you use it.
O(1) expert lookup (v1.8.0). A resident hit is one probe where the legacy worst case was 44 to 219.
O_DIRECT (DIRECT=1). Bypasses the page cache: +34% decode measured on a Blackwell/Windows box, 4.25 → 9.69 GB/s in iobench on a GB10. Drive-dependent — QLC and DRAM-less disks can be neutral or negative.
Dual-SSD striping. Put a second full copy of the model on a second drive and stream from both. A 9 GB/s + 3 GB/s pair reads experts ~33% faster than the fast drive alone.

That last one has a nice failure model. The mirror is validated at startup (byte-identical safetensors headers), never written to, and a read error falls back to the primary with one warning — so unplugging the second drive mid-run degrades instead of killing the server. A partial mirror is fine too: coli mirror plan / stage / verify ranks which shards to copy from the expert history the engine already learned.

MLA attention also stores 576 floats/token instead of 32,768 (57× smaller) and persists it to .coli_kv, so conversations reopen warm with zero re-prefill, byte-identical to an uninterrupted session.

Getting It Running

You need two things: the program (a few hundred KB) and the model (372 GB).

Get the engine — prebuilt archives exist for Linux, macOS, and Windows:

mkdir colibri && tar xzf colibri-v1.10.1-linux-x86_64.tar.gz -C colibri && cd colibri
python3 coli info                          # engine ready ✓

Or build from source, which needs gcc (or clang) with OpenMP:

git clone https://github.com/JustVugg/colibri && cd colibri/c
./setup.sh                                 # checks gcc/OpenMP, builds, self-tests

Get the model. Use the group-scaled (gs64) container with the int8 MTP head:

https://huggingface.co/mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp

Or convert from the FP8 source with ./coli convert --model /nvme/glm52_i4 — one resumable command that never needs the full 756 GB on disk at once.

Run it:

COLI_MODEL=/nvme/glm52_i4 ./coli chat      # TUI; RAM budget, cache, MTP auto-detected
COLI_MODEL=/nvme/glm52_i4 ./coli plan      # inspect planned VRAM/RAM/disk placement
COLI_MODEL=/nvme/glm52_i4 ./coli doctor    # read-only readiness check
COLI_MODEL=/nvme/glm52_i4 ./coli tune      # measure this machine's fastest safe profile
./coli serve --model /nvme/glm52_i4        # OpenAI-compatible API + dashboard, headless

Run coli plan, coli doctor, and coli tune before your first real session. They're the difference between "why is this 0.05 tok/s" and knowing exactly which tier your experts landed in.

Switching models changes nothing about the command line — build the engine you want (make -C c inkling, make -C c kimi_k3), then point COLI_MODEL at the right directory. coli reads the model's config.json, picks the matching binary, and renders that family's chat template.

What Each Model Actually Costs You

This table is the single most useful thing in the repo, and misreading two rows together has confused people into thinking the requirements contradict each other. They don't — they're different models.

Model	Disk	RAM	GPU
OLMoE (7B/1B)	~7 GB	8 GB	not needed
Qwen3.6 (35B-A3B)	~20 GB	24 GB	optional — 7.0× with CUDA tier
DeepSeek V4 Flash (284B/13B)	~167 GB	16 GB min	optional — GTX 10-series and up
Qwen3.8-Flash-Next (125B)	~185.5 GB	16 GB min	CPU only
GLM-5.3-Flash (321B, vision)	~195 GB	25 GB	not needed
GLM-5.2 (744B/40B)	~372 GB	16 GB min, 24 comfortable	not needed
Inkling (975B/41B)	~469 GB	25 GB with int4 dense	not needed
Kimi K3 (2.8T/104B)	~1.6 TB	32 GB+	not needed

Note the shape of it: RAM barely moves from 8 GB to 32 GB across a 400× range in parameter count, while disk goes from 7 GB to 1.6 TB. That's the whole thesis in one table. The binding constraint moved from expensive scarce memory to cheap abundant storage.

The Benchmarks, Honestly

The project publishes a hardware ladder rather than a headline number, which I appreciate:

Hardware	Decode	Notes
6× RTX 5090, full residency	5.8–6.8 tok/s	TTFT ~13 s, disk drops out of decode entirely
128 GB CPU-only desktop	~1.8 tok/s	warm cache
Single RTX 5070 Ti box	1.07 tok/s	GPU-resident pipeline
25 GB dev box	0.05–0.1 tok/s	cold — the proven floor where the project started

Quality is measured rather than assumed. The forward pass is validated against a transformers oracle with teacher-forcing typically 30–32/32, and the int4 container's quantization cost has its own ablations. The Qwen3.6 CUDA VRAM expert tier measured 1.44 → 10.05 tok/s (7.0×) on two 8 GB cards with output bit-identical to the CPU path — verified with cmp over a full 200-token generation. That's the right way to report a speedup.

Speculative decoding gets the same treatment. GLM-5.2's native MTP head drafts 2.2–2.8 tokens/forward when it pays, with two hard-won defaults: the MTP head must be int8 (int4 heads collapse to 0–4% acceptance), and draft and verify must compute the same function (SPEC_PIN=1). And the honest counterpoint is published too — MTP measured a 32% loss around 85% expert hit rate. Use DRAFT=0 when it doesn't pay.

Community Reaction

The Show HN — "Getting GLM 5.2 running on my slow computer" landed on 2026-07-10 and the reception split along a predictable line.

The enthusiasm is about access. r/LocalLLaMA and r/LocalLLM both ran threads within days, and commenters immediately started asking about RAID0 and multi-SSD setups. One: "it would be interesting if with a really fast drive, potentially raid0... you could get to 1 to 2 tokens a second — then for really critical work that you have extra time for and want right, I could see it being quite valuable on consumer hardware."

The skepticism is about arithmetic. From r/LocalLLM: "I don't know about people but for my SSD it will take 1s, so best case I'll do is 1 tok/s, given everything else is perfect. The only scenario where this works at any reasonable speed is for you to have enough RAM to fit the model anyway." That is a fair reading of the cold-cache case — and the learning cache plus lookahead prefetch is precisely the counter-argument, though it only pays on repeatable workloads.

The sharpest criticism wasn't technical. An r/LocalLLaMA commenter called out the AI-written README and noted 24 of the first 32 commits were authored by Claude. The maintainer's reply: colibrì is a one-person project written and tested entirely on a 12-core laptop with 25 GB of RAM, and the published numbers are the ceiling of what they could measure at home. Two months and 26k stars later, that ceiling has been raised mostly by contributors A/B-testing on hardware the author doesn't have.

An r/technology thread also flagged generations getting stuck in loops. Worth knowing: that was traced to the older per-row int4 containers, which measure ~9pp worse on quality. The gs64 container fixed it in controlled A/Bs — but the maintainers explicitly say it is not a general repetition guard. Use the gs64 build.

Honest Limitations

Speed is your SSD. On a slow drive, expect a fraction of a token per second. No amount of engine cleverness fixes a cold cache on a QLC disk.
Storage is the new price. 372 GB for GLM-5.2, 1.6 TB for Kimi K3. Cheaper than 8 GPUs, not free.
No SLA on speed — the project says so explicitly. It's an engine you can run today and a research platform. Aggressive systems ideas ship behind flags.
97 open issues and a fast-moving release cadence (five releases in twelve days). v1.10.0 shipped broken prebuilt archives that v1.10.1 repaired the next day.
Not every knob is a win. O_DIRECT is drive-dependent, learned pins can overfit a prompt, and CPU/GPU overlap gains vanish on fast CPUs at low residency. The docs say this out loud, which is unusual and good.
TTFT is its own problem. 13 s to first token on a 6× 5090 rig is acceptable; on a cold streaming box it's a different conversation.

Who Should Actually Use This

Good fit: you have a big NVMe drive and normal RAM; you want a frontier model for batch work where 1–2 tok/s is fine (overnight analysis, offline drafting, air-gapped research); you want to study MoE routing — the Brain and Atlas pages visualize all 19,456 experts, 13,260 of them characterised, with 1,041 replicated specialists clustering by topic; or you want a C engine small enough to actually read.

Bad fit: interactive chat as a daily driver, anything user-facing with latency requirements, or a machine without hundreds of gigabytes to spare. A 30B dense model on the GPU you already have beats this every time.

FAQ

Does Colibrì really run a 744B model on 25 GB of RAM?
Yes, with the qualifier that matters: the 744B model's weights still occupy ~372 GB on disk. Only the dense portion (~9.9 GB at int4) plus an expert cache stays in RAM; the 19,456 routed experts stream from NVMe as the router calls them. On a 25 GB box that's 0.05–0.1 tok/s cold — correct, but slow.

Do I need a GPU?
No. None of the eight supported families requires one. A GPU only makes it faster — the DeepSeek V4 CUDA path makes prefill 5–10× and decode ~2.5× faster, and the Qwen3.6 VRAM expert tier measured 7.0× on two 8 GB cards. Backends exist for CUDA, Metal (experimental), and Vulkan, the last of which covers AMD cards via Mesa/RADV including ones ROCm dropped, like the RX 580.

How is this different from llama.cpp with mmap offloading?
mmap lets the OS page weights in reactively and leaves placement to the page cache. Colibrì treats placement as the engine's job: measured routing heat drives a per-layer LRU and a learned pinned hot-store, a lookahead thread prefetches next-layer experts using 71.6%-predictable routing, batch-union collapses duplicate reads, and O_DIRECT plus dual-SSD striping attack the I/O path directly. It's proactive scheduling versus reactive paging.

Will streaming from disk degrade output quality?
No — that's an explicit guarantee rather than a hope: placement decides speed, never semantics. The forward pass is validated against a transformers oracle (30–32/32 teacher-forcing), and the Qwen3.6 GPU tier produces bit-identical output to the CPU path. Quantization does cost quality, but that's the int4 container's doing, not the streaming. Use the gs64 container, not the older per-row mirrors.

Can I split it across multiple machines?
Yes, there's a local cluster mode. The coordinator keeps token generation, routing, and KV state local while disk-backed workers execute routed FFNs elsewhere; a layer's batched expert union goes as one persistent TCP request, so a token doesn't cost one round trip per expert. The transport stays disabled unless workers are configured, so the single-machine path is unchanged.

Is it production-ready?
No, and it doesn't claim to be. Treat it as a serious research engine with a usable front end — an OpenAI-compatible API, a web dashboard, persistent KV slots — but with 97 open issues, no speed SLA, and a release last week that shipped a broken archive. Pin a version, run coli doctor --deep, and measure your own hardware before depending on it.

Sources

JustVugg/colibri on GitHub — README, benchmark tables, per-model docs
Colibrì release notes — v1.7.0 through v1.10.1, 2026-08-20 to 2026-08-31
Show HN: Getting GLM 5.2 running on my slow computer — 2026-07-10 launch thread
r/LocalLLaMA: GLM-5.2 (744B MoE) on a 25GB-RAM consumer machine
r/LocalLLM: Is Colibri the right approach? — the skeptical arithmetic
GLM-5.2 int4-gs64 container on Hugging Face

QwenPaw Review: Self-Hosted AI Assistant, 34k Stars

Andrew — Tue, 01 Sep 2026 10:11:07 +0000

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

TL;DR

QwenPaw (Qwen Personal Agent Workstation) is an open-source personal AI assistant from the AgentScope team that you install on your own machine — not a hosted product with a self-hosted tier bolted on. It went from first commit to 34,000+ GitHub stars in roughly six months, which makes it one of the fastest-growing agent projects of 2026. Key facts:

34,759 GitHub stars, 3,052 forks, Apache-2.0 license — commercial use allowed
Created 2026-02-24; v2.0.0 ground-up rewrite shipped 2026-07-10, v2.1.0 on 2026-08-13, v2.2.0 currently in beta
Python 3.11 – <3.14; installs via pip, a shell installer, Docker, or a beta Tauri desktop app
Runs fully offline with bundled llama.cpp runtime + purpose-trained QwenPaw-Flash 2B/4B/9B models, or connects to Ollama, LM Studio, and 14+ cloud providers
Five security layers: kernel sandbox, Tool Guard, File Guard, Skill Scanner, Access Policy
Reachable from chat apps: DingTalk, Lark, WeChat, QQ, Discord, Telegram, iMessage
Three-layer memory via ReMe — plain Markdown on disk, editable by hand
597 open issues and a heavily China-first ecosystem — the biggest practical caveats

If you have wanted a persistent assistant — one that remembers last month, runs scheduled jobs, and answers you in Telegram — without renting it from someone else, QwenPaw is the most complete attempt shipping right now.

Quick Reference

Field	Value
Repo	agentscope-ai/QwenPaw
Docs	qwenpaw.agentscope.io
License	Apache-2.0
Language	Python (TypeScript console frontend)
Python	>= 3.11, < 3.14
Install	`pip install qwenpaw`
Docker	`agentscope/qwenpaw:latest`
Default port	`127.0.0.1:8088`
Stars / forks	34,759 / 3,052
Built by	AgentScope team (AgentScope, AgentScope Runtime, ReMe)

What QwenPaw Actually Is

The name decodes to Qwen Personal Agent Workstation, and "workstation" is the more honest half. This is not a chatbot wrapper. It is a long-running local service that owns a working directory, a memory store, a set of skills and plugins, a scheduler, and a permissions model — then exposes that single agent through a web console, a terminal UI, a desktop app, and a pile of chat channels simultaneously.

The mental model that helps most: think of it as a personal server for one agent, the way Home Assistant is a personal server for your devices. Install it once, configure a model provider, and it stays up. Sessions, memory, and skills are shared across every surface — a conversation started in the browser console continues from Telegram with the same context.

Version 2.0.0 (July 2026) rewrote the project on top of AgentScope 2.0 and introduced the architecture the project now leads with: Agent OS. It has two halves:

Workspace — three pillars per agent: Resources (stored transparently on disk, not in an opaque DB), Governance (allow / deny / ask / sandbox rules), and Sandbox (per-platform kernel isolation).
Drivers — a protocol-neutral connector layer speaking MCP, A2A, and ACP, with encrypted credentials and a per-call policy gate.

That second piece matters more than it sounds. Most agent frameworks pick one protocol and make you adapt. QwenPaw treats MCP servers, agent-to-agent calls, and ACP orchestration as three drivers behind one permission boundary, so a policy written once applies regardless of how the capability arrived.

Why It's Trending Now

Three things converged.

First, the self-hosting wave hit personal assistants. Through 2025 and early 2026 the self-hosted AI conversation was about inference — Ollama, LM Studio, llama.cpp. Those solved "run a model locally" but not "have an assistant." QwenPaw targets the layer above: memory, scheduling, channels, tools, and permissions.

Second, the v2.0 rewrite gave it a real story. Agent OS, Loop Engineering, and Scroll Context reframed a conventional agent app as infrastructure, and the star curve reflects it.

Third, it ships genuinely small models. The QwenPaw-Flash series (2B / 4B / 9B, Q4 and Q8 quantizations) is trained for agent tasks — tool calling, loop adherence, structured output — rather than general chat. With the bundled llama.cpp runtime, you go from pip install to a working agent with no API key at all. Few competing projects can say that honestly.

The Features That Matter

Scroll Context: nothing gets summarized away

Most agent frameworks manage long conversations by summarizing old turns and discarding the originals. That is lossy in exactly the way that hurts — the detail you need three weeks later is the detail the summarizer dropped.

Scroll Context persists every turn. When a turn is evicted from the live window it is indexed rather than compressed, and recalled on demand. The design goal, stated plainly in the v2.0 notes, is that nothing is summarized away. For an assistant you intend to keep for a year, this is the single most consequential architectural choice in the project.

ReMe: memory you can open in a text editor

Memory is powered by ReMe v0.4, a sibling AgentScope project. It maintains three layers: live working context, full verbatim history, and a self-evolving personal knowledge base.

The knowledge base is the interesting one, because it is Markdown on disk — readable, editable, searchable, and linked. Conversations and resources continuously become notes. If the agent learns something wrong about you, open the file and fix it. Compare that to vector stores, where correcting a bad memory means deleting an embedding you cannot read.

Five security layers, and they are not decorative

Running an agent with shell access on your own machine is the whole value proposition and the whole risk. QwenPaw's answer is unusually thorough:

Sandbox — real kernel-level isolation: Seatbelt on macOS, Bubblewrap / Landlock on Linux, AppContainer on Windows. Shell commands see a restricted filesystem view.
Tool Guard — a YAML rule engine whose ShellEvasionGuardian inspects every tool call before execution for command injection, path traversal, reverse shells, and obfuscation. Approval levels: STRICT / SMART / AUTO / OFF.
File Guard — blocks access to sensitive paths independently of Tool Guard; ~/.ssh and the secrets directory are protected by default.
Skill Scanner — scans skills before activation for prompt injection, hardcoded secrets, and exfiltration patterns. Block / warn / off, with a whitelist.
Access Policy — declarative allow / deny / ask rules at tool-level granularity, with source-aware matching.

Skill Scanner deserves a call-out. Community skill marketplaces are an obvious supply-chain attack surface, and QwenPaw ships scanning as part of the default install flow rather than a plugin.

One agent, every channel

Channel support is broad: DingTalk, Lark, WeChat, QQ, Discord, Telegram, and iMessage, plus the console, TUI, and desktop app — one instance, shared memory and sessions.

Loop Engineering and multi-agent

Loop Engineering provides templated agent loops — Coding Mode, Mission Mode — with composable approval gates, so a coding task's control flow differs from a research task's without rewriting the agent. Multi-agent support spawns independent agents with their own memory and skills, plus runtime sub-agents.

Getting Started

The fastest path, assuming Python 3.11–3.13:

pip install qwenpaw
qwenpaw init --defaults
qwenpaw app

Then open http://127.0.0.1:8088/ and configure a model in Settings → Models.

If you would rather not manage Python:

# macOS / Linux
curl -fsSL https://qwenpaw.agentscope.io/install.sh | bash

The installer pulls uv, creates a virtualenv, and installs everything including Node.js and frontend assets. (Piping a remote script to bash is worth the usual caution — read it first if the machine matters.)

Docker is the cleanest option for a homelab box:

docker pull agentscope/qwenpaw:latest
docker run -p 127.0.0.1:8088:8088 \
  -v qwenpaw-data:/app/working \
  -v qwenpaw-secrets:/app/working.secret \
  -v qwenpaw-backups:/app/working.backups \
  agentscope/qwenpaw:latest

Note the deliberate three-volume split: config/memory/skills, provider credentials, and backups are separated, so you can back up state without dragging API keys along. If you run Ollama on the host and QwenPaw in Docker, add --add-host=host.docker.internal:host-gateway and point the Base URL at http://host.docker.internal:11434.

Terminal users get a first-class TUI:

qwenpaw                     # chat with the active agent
qwenpaw tui --resume <id>   # resume a session
qwenpaw .                   # start in the current repo (Coding Mode)

It drives the same agent as the console — same memory, skills, MCP tools, sessions — with streaming replies, slash commands, and inline tool-permission prompts.

Who Should Use This — And Who Shouldn't

Good fit:

Homelab and self-hosting people who want an assistant that outlives any vendor
Privacy-driven users who need data to stay on their hardware — local models mean zero outbound calls
Anyone wanting an assistant reachable from Telegram or Discord without building the bridge
Teams evaluating agent security models; the five-layer design is worth studying regardless

Poor fit:

Anyone wanting a polished consumer app today. The desktop build is explicitly Beta, unnotarized on macOS (you will fight Gatekeeper), and first launch can take 10–60 seconds.
English-only users who need English-language community support (see below)
Low-spec hardware, if you plan to run local models — the 9B Flash model wants real RAM
People wanting a coding agent specifically — Coding Mode exists, but dedicated tools are further along on that axis.

Honest Limitations

The ecosystem is China-first. This is the most important thing a Western reader should know, and the README does not hide it: the default cloud provider is DashScope, one-click deploy is Alibaba Cloud ECS, models are distributed via ModelScope alongside Hugging Face, and the community channels lead with DingTalk and RedNote. Scanning the open issues sorted by reactions, most of the top feature requests are written in Chinese. Nothing here is broken for international users — Discord and Telegram channels work, OpenAI/Anthropic/Gemini/DeepSeek/OpenRouter providers are supported, docs exist in English, Chinese, Japanese, and Russian — but if you file an issue, expect the surrounding conversation to be bilingual at best.

597 open issues. For a six-month-old project moving this fast that is not alarming, but it is a real backlog. The maintainers have posted an explicit contribution policy about AI-generated issues and PRs, which tells you what the triage load looks like.

Release velocity is extreme. Five v2.2.0 betas landed between 2026-08-27 and 2026-08-31. Recent commits include fixes for hung MCP session RPCs, stale DingTalk stream connections, oversized tool results, and installer edge cases. Pin a stable tag for anything you depend on; latest is a moving target.

Telemetry is on by default with --defaults. It is anonymous and narrow — version, install method, OS, Python version, CPU architecture, GPU yes/no, sent once per version — and no files, credentials, or IP addresses are collected. But qwenpaw init --defaults accepts it automatically. Run qwenpaw init interactively if you want the prompt.

Upgrades from source need care. Major-version bumps require rebuilding the frontend, reinstalling the package, restarting, and hard-refreshing the browser cache. Use pip or Docker unless you contribute.

Comparison With Alternatives

	QwenPaw	Open WebUI	Ollama alone	Hosted assistants
Persistent memory	Three-layer + Markdown KB	Basic	None	Vendor-controlled
Chat channels	7+ (Telegram, Discord, …)	Web only	None	Vendor apps
Sandboxing	Kernel-level, 3 OSes	Limited	N/A	N/A
Scheduled tasks	Built-in cron + heartbeat	No	No	Varies
Local models	Bundled runtime + Flash	Via Ollama	Yes	No
License	Apache-2.0	BSD-3	MIT	Proprietary

The clearest way to place it: Open WebUI is a chat interface for your models; QwenPaw is an operating environment for your agent. If all you want is a nice window onto Ollama, Open WebUI is simpler and lighter. If you want memory that persists for a year, jobs that run at 6am, and an agent that pings your phone, QwenPaw is doing something Open WebUI does not attempt.

FAQ

Is QwenPaw free, and can I use it commercially?
Yes. It is Apache-2.0, which permits commercial use, modification, and redistribution. Running it costs nothing beyond hardware; the only spend is optional cloud model API usage, which you can skip entirely by using local models.

Do I need an API key to use QwenPaw?
No, if you use local models. QwenPaw Local (bundled llama.cpp), Ollama, or LM Studio all work without keys. You only need a key for cloud providers like DashScope, OpenAI, Anthropic, Gemini, DeepSeek, or OpenRouter — and the app will not chat until a valid key is set if you pick one of those.

Does QwenPaw send my data anywhere?
Not your content. Deploy locally and conversations, memory, and files stay on your machine. The only outbound telemetry is anonymous install metadata sent once per version, and it excludes files, credentials, and IP addresses. If you use a cloud model provider, prompts obviously go to that provider.

Do I need to speak Chinese to use it?
No. Documentation is available in English, Chinese, Japanese, and Russian, and international channels (Discord, Telegram) are supported. But the issue tracker and much of the community discussion are predominantly Chinese, so support conversations may be harder for English-only users.

What hardware do I need for local models?
The Flash series is deliberately small — 2B, 4B, and 9B, with Q4 and Q8 quantizations. The 2B Q4 will run on modest laptops; the 9B wants a machine with real RAM or a GPU. QwenPaw Local includes hardware-aware recommendations that pick a size for your machine. If you use Ollama, set the context length to at least 32k.

How does QwenPaw compare to running Ollama plus a script?
Ollama gives you inference. QwenPaw gives you the assistant around it: persistent memory, scheduling, chat-app channels, a skills/plugin system, MCP integration, multi-agent orchestration, and a five-layer security model. If your script has grown its own memory store and cron jobs, you are rebuilding QwenPaw.

Is it production-ready?
For personal and homelab use, yes — with a pinned version. For anything business-critical, treat it as fast-moving software: pin a stable release rather than latest, back up the data volumes, and read release notes before upgrading.

The Verdict

QwenPaw is the most architecturally serious open-source personal assistant available in September 2026. Scroll Context and the Markdown-based ReMe memory solve the long-horizon problem most agent projects hand-wave, and the five-layer security model is the only one in this category that looks designed by people who actually thought about a malicious skill.

The caveats are real but bounded: a China-centric ecosystem that costs English-only users some community access, a large issue backlog, and a release cadence that demands pinned versions. None of those are architectural.

If you want an assistant that is yours — one that remembers, runs on your schedule, and cannot be deprecated by a pricing change — install it with Docker, pin a stable tag, and give it a week.

Sources

agentscope-ai/QwenPaw on GitHub — README, license, star and fork counts (retrieved 2026-09-01)
QwenPaw official documentation — install, security, memory, and channel guides
QwenPaw release notes — v2.0.0 through v2.2.0-beta.5
ReMe (agentscope-ai/ReMe) — the memory engine behind the personal knowledge base

DEV Community: Andrew

FrontierAgent Review: Apodex's Open Agent Team Harness 2026

TL;DR

Why This Matters Now

What FrontierAgent Actually Is

Architecture: Loop, Observers, AgentBus

The Sandbox and Safety Model

Getting Started

Going fully local with Apodex-1.1-mini

Benchmark Evaluation

Community Reaction

Honest Limitations

Who Should Use FrontierAgent

FrontierAgent vs Alternatives

FAQ

Verdict

Sources

PRAXIST Review: Sapient's Autonomous R&D System (6.5K Stars)

TL;DR

Why This Matters Now

What PRAXIST Actually Is

Architecture: Generations, Lanes, and the Evidence Graph

The Benchmark Claims

Getting Started

Codex-native mode (no API key)

Agent-managed install

Takeover

Bundled Skills

Community Reaction

Honest Limitations

Who Should Use PRAXIST

PRAXIST vs Alternatives

FAQ

Is PRAXIST open source?

Do I need an API key?

What did PRAXIST score on MLE-bench?

Does PRAXIST work with Claude Code?

Does it run on macOS?

How is this different from Karpathy's AutoResearch?

Verdict

Codex with ChatGPT Review: ChatGPT Plans, Codex Executes

TL;DR

What Codex with ChatGPT actually is

Installation

Optional: a stable hostname

The C2C protocol in practice

The 9 read-only MCP tools

Security model: the best part of the project

Community reaction

Codex with ChatGPT vs the alternatives

Limitations

FAQ

Does Codex with ChatGPT work with ChatGPT Plus, or do I need Pro?

Can ChatGPT modify my files through the bridge?

Is my repository uploaded to OpenAI?

Why does it need Cloudflare?

Does it cost extra?

Can I use it without Computer Use?

Verdict

Sources

Reverify Review: Make Your AI Agent Prove Every Claim

TL;DR

The problem Reverify is built around

The verification loop in practice

A real hallucination, caught

The benchmark: 275 binaries, 0 false accepts

The ledger: facts that survive /clear

reverify rollover: the same idea for any agent CLI

Setting it up as an MCP server

Community and early feedback

Honest limitations

How it compares

FAQ

Is Reverify free?

Does it need an API key or a specific model?

How is this different from an LLM-as-judge guardrail?

Can I use it on source code, not binaries?

Bottom line

Sources

VoiceStudio Review 2026: Local ElevenLabs Alternative

The ledger: facts that survive `/clear`

`reverify rollover`: the same idea for any agent CLI