Open Source Radar · 2026-10-26: When another agent is worth opening

By Renchao Wu. Originally published on widechaos.cn.

Each day I pick five projects that are rising on GitHub this week, mostly AI agents and developer tools. I read each project's README, release notes and recent commits; I did not install them unless an entry says so. Stars and other numbers are from GitHub as of 2026-10-26.

The common thread this week is maintenance of the tools themselves: memory and review gates for coding agents, an org chart for a skill pack, patch management inside a deployment panel, and regression tests for prompts.

1. JetBrains/thinkrail ⭐ 1,945 · TypeScript

GitHub: https://github.com/JetBrains/thinkrail

In one line: A JetBrains incubator project that wraps the pi coding agent in a real IDE, using git worktree workspaces and treating SPEC.md files as the documented project specification.

What it is: Three layers in one app. Isolation: every task gets its own git worktree branch, so task working trees are separated. This is not a process or shared-service security boundary. Knowledge: a connected graph of SPEC.md files sits beside the code. Interface: models, skills, compaction, cost and session state all come from pi rather than being re-implemented. The code splits into packages/server (a Bun HTTP+WS host, one in-process pi session per chat), packages/contracts (a typed, versioned protocol) and apps/web (React 19, shipped independently). Created 2026-07-08; v0.2.0 shipped on 2026-10-18 (not a prerelease), with nightlies up to v0.3.0-nightly.6.

What stands out:

• Every module carries a SPEC.md, and people and the agent read the same file. The agent reads, searches and maintains it through dedicated spec_* tools; the method requires that a change moving a boundary, contract or decision updates the spec in the same change. Intent gets a home outside the session that both a person and the agent can go back to; whether it really survives depends on that rule being followed.
• MCP approval is split by read-only status, not by server. Servers come from pi's mcp.json; a call to an endpoint not marked read-only is asked about in chat, a server a repository defines stays off until you approve it, and OAuth servers sign in from settings. The docs describe call-level approval based on read-only metadata; I have not audited that metadata or enforcement.
• Cost and authority are per session. Several sessions run at once in one workspace, each with its own model and live token and cost readout. You can steer a running turn, queue a follow-up, delegate to subagents, and work a shared plan both sides can edit, with each finished step committed and reviewed on its own.
• Analytics exist, and the boundary is documented. Launches, chat creation, message sends, provider connections and error reports are sent by default, tied to a random installation ID. The README says these exclude prompts, code, files, credentials and account identity; I have not independently audited the telemetry; extra usage sharing is opt-in and --no-analytics turns it off for a run.

Compared with: Gentle-AI (entry 3 below) sits at another layer. It only configures agents you already use, and says plainly that it never installs an agent for you and does not own your editor. ThinkRail is the host itself, which is what lets it make the isolation unit a worktree and the protocol its own versioned package. The cost is that its ceiling is set by pi's interface, while the other project buys coverage with 17 agent integrations.

Recent updates: v0.3.0-nightly.6 (2026-10-25) is almost entirely reliability work: terminal recordings persist only after a printed marker arrives, the reading anchor is corrected once after a fold change only once the virtualised list has measured it, and the Windows installer tests warm PowerShell first. Before that, nightly.4 put Remote and Pull request in the topbar with the branch's next step and moved GitHub review details into it; nightly.3 compiled the CLI binary with JSC bytecode and extracted the file and diff renderers into a separate package.

Who it's for: People with several repositories who want to run a few coding agents in parallel, and who can live with a 0.x version and an analytics stream they can switch off. A worktree isolates the working tree only: browser sessions, ports and shared services stay shared. The desktop build is Apple Silicon only on macOS, so Intel machines have to build from source.

My take: ⭐⭐. It treats context as a file-structure problem rather than a prompting problem, which is the part I buy. Too early to be a daily driver.

Checked: read the README, the last five releases and the last eight commits; not installed.

2. AgriciDaniel/claude-seo ⭐ 21,125 · Python

GitHub: https://github.com/AgriciDaniel/claude-seo

In one line: An SEO audit plugin that runs inside Claude Code, built from 26 sub-skills and 19 specialist agents, up to 17 of them auditing one site in parallel.

What it is: It splits what an SEO consultant checks into skill groups — technical SEO across nine categories, content and E-E-A-T, schema and AI search, local, links and commerce — with 30 commands in six groups hanging off them. A full site audit fans out up to 17 agents and returns Markdown reports that can be turned into PDF. Created 2026-02-07; the five most recent releases, latest v2.5.0 on 2026-10-22.

What stands out:

• Models are assigned by whether a step needs judgement, and the bill is stated. Five of the 19 agents run on Opus (content, AI search, topic clustering, search experience, change monitoring) and the rest on Sonnet. The README says outright that a full audit uses more of your Claude plan than a single-page check, and any agent's model can be changed in agents/.
• Findings are intended to include verification steps. Recommendations state what they rest on, what they depend on, and how you will verify them. Reports land as Markdown, PDF and JSON on your machine, and /seo drift uses SQLite snapshots to compare audits over time.
• It classifies the business before it checks. SaaS, local, e-commerce, publisher or agency first, then the checklist adapts. JavaScript sites are rendered in a headless browser first, so a single-page app is audited on the rendered DOM, which does not by itself verify every browser interaction or crawler-visible response.
• The CVE check is read-only and does not probe. The server stack CVE exposure check added in v2.5.0 infers the stack from normal response headers (X-Powered-By, a PHP session cookie, WordPress signals) according to the release notes: no fuzzing, no exploit payloads, and it asks whether you own the site before requesting any other path.
• The public and paid versions are separate. MIT covers the public plugin; the same author ships a private version to a paid community with earlier access to new features.

Compared with: The project's own FAQ draws the line — crawlers like Screaming Frog crawl faster and deeper, and large SEO suites have their own backlink databases, while this one explains what it finds, sorts by impact, goes deeper on AI search and answers follow-up questions in plain language, and it suggests using both. What is verifiable is the shape of the output: a one-off list versus a repeatable baseline, where every recommendation has a verification step and each audit has a SQLite snapshot to compare against.

Recent updates: v2.5.0 (2026-10-22) follows a security and accuracy audit. The release notes raise the Python floor to 3.11, add the server stack CVE check with a PHP remote-code-execution advisory as its basis, and restore Claude Desktop installs. The last three releases landed within two weeks of each other, and at least two of them follow platform changes.

Who it's for: SEO agencies that want weekly rather than quarterly audits per client, in-house teams at SaaS, publishing and e-commerce companies, and freelancers evaluating an audit workflow before writing a proposal. Its scores still need validation against the intended use. It needs Python 3.11+, and the pages it analyses are sent to Claude as part of the request — the README's privacy section says so directly.

My take: ⭐⭐. The engineering discipline here is unusual: every recommendation has a verification step and the reports rerun. The value still depends on being in SEO. If you are not, what transfers is how it organises skills and agents, not its checklist.

Checked: read the README and the last five releases; the 1,077-test badge and the "10.8K clicks in 12 weeks" figure are the project's own claims, not reproduced; not installed.

3. Gentleman-Programming/gentle-ai ⭐ 8,017 · Go

GitHub: https://github.com/Gentleman-Programming/gentle-ai

In one line: Gives 17 coding agents — Claude Code, Codex, Cursor, Gemini CLI and others — three things: memory across sessions, a workflow that sizes itself to risk, and a review gate whose evidence belongs to a frozen version.

What it is: A single Go binary that behaves like a configurator. Run it, pick agents, components and a persona, and it writes a shared workflow into each agent's own native configuration. Every configuration file is snapshotted before a write, and a deny-list blocks ~/.ssh, .env and credential files. It says plainly that it does not install agents and does not write into Pi's prompt files without permission. Created 2026-02-27; latest v4.2.0 on 2026-10-15.

What stands out:

• When to spawn a subagent is written as numbers you can argue with. Four triggers: exploration (understanding needs more than about three calls or 10k tokens, or more than five sequential lookups), parallel writers (two or more independent units with disjoint edit surfaces, roughly 100+ changed lines each), context backstop, and independent verifier (data, security, shared contracts, concurrency, delivery, or no test that would catch a regression). If none holds, the parent works inline; file count, task size and model price alone never decide the route.
• Review depth comes from a frozen candidate, not from the model's self-assessment. The change is frozen to a lineage, revision and target before anything reads it, and risk tiering sets the depth: a structural readback for passive, one focused lens for medium, the four lenses of Risk, Resilience, Readability and Reliability for high. At most one bounded correction is allowed, and one exact acknowledgement closes it. Commit, push and release stay human decisions.
• "What is the next valid step" is handed back to a binary. gentle-ai reads the change state from files on disk and returns exactly one of four public states: Working, Checking, Ready, or Needs your decision. The author's reasoning is blunt: a model that guesses the next step guesses differently tomorrow and differently again for your teammate.
• Task size is decided by recoverability from the diff. Small tasks run inline with no task document; work only becomes large when it cannot be resumed from the diff — several sessions, external waits, or requirements too long to survive compaction. The feature document of a large task holds your spec verbatim, and every handoff points at it instead of paraphrasing it.
• Eight small components ship with it: a skills library loaded when a task matches, optional Context7 MCP, a read-only CodeGraph symbol map, the security deny-list, config backups before every write, a read-only gentle-ai doctor, personas and themes, and per-agent model assignment.

Compared with: It publishes results as a table and puts the caveats next to the table: the author's own local benchmark, hidden acceptance suites, one run per cell (n=1), cost as API-equivalent. A three-line bug in one function went from 335 s, 56 turns and $0.339 to 77 s, 10 turns and $0.105 inline; a bug rooted in shared logic from 479 s and $0.361 to 276 s and $0.207 with one explorer; a 73-line spec with 26 hidden checks failed 13 checks with paraphrased handoffs and was still at 23 of 26 after two feedback rounds, then passed when the spec was passed by reference. The author also compares against the same model in Codex CLI with blind review. The reported large-task duration is 17.5 to 17.9 minutes versus 6.1, a gap the README labels open work. With one run per cell, I would not infer a general acceptance rate or quality ranking. I have not run any of it.

Recent updates: v4.2.0 (2026-10-15) moves Pi's routing block into the provider contract at 1.4.0, byte-identical golden checksums for the other runtimes, and commits work in reviewable slices of about 400 changed lines while keeping small tasks inline. v4.0.0 (2026-10-01) was breaking: the previous methodology retired in favour of ODD, and the module path moved to /v4.

Who it's for: Teams with a settled coding agent and a recurring tax of re-explaining the same decisions, and anyone studying explicit review gates. Their effectiveness still depends on the checks and their implementation. Note that it configures rather than installs, that the version is still moving fast, and the trademark notice: MIT covers the code and does not permit implying endorsement.

My take: ⭐⭐⭐. The one I read most closely of these five. It turns two vague questions — when a parallel session is worth opening, and which layer a review should look at — into thresholds, a state machine and a frozen object.

Checked: read the README and the last five releases; the benchmark table is the project's own claim, not reproduced; not installed.

4. coollabsio/coolify ⭐ 64,540 · PHP

GitHub: https://github.com/coollabsio/coolify

In one line: A self-hosted PaaS that manages servers over SSH alone, deploying applications, databases and more than 360 one-click services, with rollback, backups, patching and an MCP endpoint.

What it is: A Laravel project created 2021-01-25. Sources cover GitHub, GitLab, Bitbucket and Gitea; builds run through Nixpacks, Railpack, Dockerfile, Docker Compose or a prebuilt image. The managed unit is a server plus its resources, so multiple servers, container networks, reverse proxies, health checks and certificates all sit in one panel. Latest v4.5.0 on 2026-10-23. The model is free self-hosting plus a paid Cloud; the README's donation section states there is no feature behind the paywall.

What stands out:

• Rollback has two layers, and the second one matches real incidents. One is rollback to a retained application image. Image rollback does not by itself reverse database migrations or external side effects. The new one in v4.5.0 rolls back to a Docker registry image from a recent deployment, which fits the case where CI pushes the image and only environment variables were changed in the panel.
• Patching is treated as a first-class operation. The same release adds server patching in beta: automatic security updates per server, reboot and risky-package warnings, and patch status in the server list.
• It backs itself up before it upgrades. v4.5.0 backs up the Coolify database automatically before an update. A backup is useful only if it can be restored; I have not tested restore coverage or application-data consistency.
• It leaves a door for agents. The same release adds MCP tools to manage resources, alongside a file browser, passkey sign-in, and a Smart scan that detects the build pack, Dockerfiles and environment variables of a new Git project.
• Observability reaches the fleet. A fleet Metrics page has server and container tables, trend charts and one-click enablement; server pages chart disk, network and load; logs can be drained to AWS CloudWatch.

Compared with: Dokploy sits in the same category, and I read both READMEs. The differences that hold up: Coolify leads with a catalogue of more than 360 one-click services, four entry points (panel, API, CLI, MCP) and per-server patching; Dokploy lists multi-node scaling through Docker Swarm and log and metric shipping to a dozen-odd backends including Loki, Prometheus, Datadog and New Relic as first-class features. Both are free to self-host with a paid Cloud, both use Traefik, both run Docker Compose. What is left is the cost of configuration and recovery — how nodes get added, when patch windows land, which backup you restore from — and that has to be measured on your own machines.

Recent updates: v4.5.0 (2026-10-23) lists more than 30 items: Gitea App sources, server patching, fleet Metrics, a Canvas dashboard, file browser, passkeys, maintenance mode and custom error pages, Cloudflare tunnels, a pre-update backup, GitLab system hook deploys, MCP resource management, cache flush for Redis-family databases, and an interactive docker attach console. Four patch releases also landed on 2026-10-21, so the release cadence is high.

Who it's for: People with one or a few VPS instances who do not want a Vercel bill or platform lock-in, and small teams needing an internal deployment control plane. Caveats: the panel is itself a single point of failure, and self-hosting means patching and backups remain your responsibility — the tool only hands you the means.

My take: ⭐⭐⭐. Feature density and maintenance activity are both there. The real barrier is not installation but whether you have the operational discipline to use its rollback and patching.

Checked: read the README and the last five releases, plus Dokploy's README for comparison; no server was deployed.

5. promptfoo/promptfoo ⭐ 26,428 · TypeScript

GitHub: https://github.com/promptfoo/promptfoo

In one line: Treats prompts, agents and RAG systems as code: declarative test cases, automated evals, red-team scanning, side-by-side model comparison and CI integration.

What it is: A TypeScript CLI and library created 2023-04-28. Test cases and assertions are declared in YAML; promptfoo eval runs them and promptfoo view shows the matrix. Four capability areas: evals, red teaming and vulnerability scanning with generated reports, model comparison across OpenAI, Anthropic, Azure, Bedrock, Ollama and others, and checks inside CI/CD plus pull-request code scanning. Latest 0.125.1 on 2026-10-25.

What stands out:

• The governance changed; the licence did not. The README states at the top that the project is now part of OpenAI and remains open source and MIT licensed; the LICENSE file at the repository root is the standard MIT text.
• It tests assertions, not impressions. 0.125.0 added rouge-l and rouge-s summary assertions and optional Unicode normalisation for equals and contains, which makes text-normalisation policy configurable. Whether normalisation is appropriate depends on the task and the distinctions its assertions need to preserve.
• Repeatability is treated as a metric. The same release reports stability across repeated tests and discloses which rows in the eval summary were cache hits. Without that disclosure, a speedup may just be a cache.
• The safety side has its own switches. 0.125.0 added a safe mode that disables inline JavaScript execution; that setting alone is not a complete sandbox, and made the Claude Agent and Codex SDKs opt-in as a breaking change — it does not connect those runtimes for you by default.
• Comparison is a first-class feature. One set of cases runs against several providers and the matrix lines them up, which is a better answer to "does switching models cost quality" than reading a leaderboard.

Compared with: Together with gentle-ai above, these are the two ends of an evidence chain: one places a change inside a process, the other scores a set of inputs across models. A regression suite earns its place by rerunning: change one prompt and the same cases run again, with results you can compare. What makes this valuable is that cases, assertions, caching and stability become a reusable asset.

One line is easy to misread, so precisely: the README says evals run 100% locally and prompts never leave your machine. The evaluation runner can operate locally; each test request still goes to the configured model endpoint. Check provider, telemetry and optional sharing settings before using sensitive cases.

Recent updates: 0.125.0 (2026-10-23) carries two breaking changes (jks-js becomes an optional peer dependency, and the Claude Agent and Codex SDKs become opt-in) plus safe mode, cache-hit disclosure, stability across repeated tests, rouge-l and rouge-s, filtering trace spans by attributes and Unicode normalisation; 0.125.1 (2026-10-25) is a small fix. 0.124.0 (2026-10-06) was a large feature release.

Who it's for: Teams whose prompts, agents or RAG are already live and who want to ship a change only after testing it, plus teams choosing between providers. Caveats: it needs a Node environment, it is 0.x with breaking changes landing in minor versions, and the test cases themselves need maintenance: they have to run alongside your changes, or the next change has no baseline to compare against.

My take: ⭐⭐⭐. The value of this category is not feature count but whether the same cases can be run again and compared; this one makes that the default.

Checked: read the README and the last five releases; not installed, no eval run.

At a glance

Project	What it is	Most distinctive	Who it's for	Worth a deeper look
thinkrail	Coding agent wrapped in an IDE	Spec graph as truth, one worktree per task	People running agents across several repos	⭐⭐
claude-seo	SEO audit skill pack	26 skills and 19 agents, each with a model tier	SEO agencies and e-commerce teams	⭐⭐
gentle-ai	Memory, workflow and review shell for agents	Delegation as thresholds, next step decided by a binary	Teams with a settled coding agent	⭐⭐⭐
coolify	Self-hosted PaaS	Patching, self-backup and registry rollback in the panel	Small teams with a VPS	⭐⭐⭐
promptfoo	Evals and red teaming	Cases, assertions, caching and stability that rerun	Teams shipping LLM applications	⭐⭐⭐

This week's notes

• Whether to open more sessions moved from instinct to thresholds you can argue about. Gentle-AI offers thresholds: about three calls, 10k tokens, 100+ lines, four triggers. ThinkRail offers another route — one isolated worktree per task, with agents still running in parallel, with separate working trees; ports, browser sessions and other shared resources still need coordination. Both admit the same thing: parallelism is not free, and the reason has to be stateable.

• Skill packs are growing an org chart, not just a process description. The 19 agents in claude-seo each have a role, a model tier and a trigger command, and up to 17 run at once. That shifts the maintenance cost from writing to following: at least two of its last five releases track platform changes — a Python end of life, a search algorithm update, a security advisory.

• Infrastructure products are leaving doors open for agents. Coolify shipped MCP resource management, per-server patching, a pre-update backup and registry rollback in one release. MCP adds an interface for machines to call, and patching, self-backup and registry rollback fill the gaps hand-rolled deploy scripts leave.

• When a finished product is acquired, the licence file is still in place. After joining OpenAI, promptfoo's LICENSE at the repository root is still the standard MIT text and its release cadence did not slow. For a team that puts it in a gate, that licence and the releases after it are what you can check.