DEV Community: 十方空烬 · Ember ☄️

Open Source Radar · 2026-10-22: Skill pipelines and isolated agent workspaces

十方空烬 · Ember ☄️ — Thu, 22 Oct 2026 06:59:18 +0000

By Renchao Wu. Originally published on widechaos.cn.

1. wshobson/agents ⭐ 41,493 · Python

GitHub: https://github.com/wshobson/agents

In one line: One Markdown source of plugins, agents, skills and commands, adapted for seven coding tools.

What it is: The repository holds 94 plugins (92 local, 2 external entries) with 202 agents, 185 skills and 105 commands underneath, all written in Claude Code's plugin format. Installing into Codex, Cursor, OpenCode, Antigravity, Copilot or Pi does not copy files: adapters generate each target's format. 91 contributors, created in July 2025, last commit on 2026-10-17.

What stands out:

Generation and validation are part of the package. Beyond generation there is make validate STRICT=1, make garden, and a static scorer that runs without model calls, intended to check consistency across seven tools. I have not run those checks. Markdown plus install notes is enough to call something a skill collection; this adds generation, validation and a capability matrix on top.
Details forced by target limits. On the Codex route, generated copies split oversized skill bodies into reference files to fit an 8 KB budget; native installs read the original bodies.
Model aliases are written once and mapped per tool. Sources use opus, sonnet, haiku, fable and inherit; adapters resolve them for each harness, and some inherit entries get fixed defaults.
The evaluation section keeps its own caveats. Besides static checks there are LLM-judge and Monte Carlo layers, and the README says outright that both are experimental, not validated against human labels, and describe model assessments rather than proof that a task succeeds in a real project.

Compared with: The confirmable difference is having a generation layer, static validation and a per-tool capability matrix at the same time. I did not read first-hand material for other skill collections, so I make no claim about them; the dimensions to compare are those three, plus whether version tags exist for rollback.

Recent updates: No releases; the project follows main. On 2026-10-15 it merged five fixes in one day covering reflog expiry notes, Cypress and Playwright APIs, and monorepo management moved to Turborepo 2 with pnpm workspaces; on 10-17 it fixed doc generation overwriting an ADR README.

Who it's for: People who switch between two or more coding tools get the most out of it. If you use one tool and want a few skills, the skills-only installers (gh skill install or npx skills add) are simpler. MIT licensed; external plugins carry their own licenses. With no version tags, upgrading means tracking main.

My take: ⭐⭐⭐ The content can be picked over time; the pipeline idea is worth borrowing now.

Checked: README and recent commits. No releases to read. Not installed.

2. OrchestratorInc/agent-orchestrator ⭐ 13,466 · Go

GitHub: https://github.com/OrchestratorInc/agent-orchestrator

In one line: A local workbench for several coding agents, where each task gets its own workspace and the board follows real pull-request and CI state.

What it is: A desktop app plus a local daemon. One worker equals one task, one agent and one isolated workspace; Git-backed work gets its own branch and worktree. A project-level orchestrator is a persistent planning agent handling direction, priorities and sequence, while workers handle implementation, tests, commits and pull requests. 131 contributors, created in February 2026, v0.14.4 shipped on 10-21 alongside nightly builds, two of which were published the same day.

What stands out:

The board follows repository state. Working, Needs you, In review and Ready to merge come from session, pull-request, CI and review state. Needs you covers blocked sessions, missing input, failed CI, requested changes and lost signals.
Failures return to the agent that owns the work. CI errors and review comments can go back to the same session instead of a new chat that has to be re-briefed.
Isolation has a stated granularity. Temporary browser profiles are per worker; named profiles deliberately reuse cookies and storage. A worktree separates edits; it is not evidence of a security sandbox.
Telemetry boundaries are spelled out. The default collects an installation ID and GitHub username, plus a cloud user ID and that account's email if you sign in; the README says code, prompts, conversations and credentials are excluded, and the whole thing can be turned off.
Maturity needs a discount. The repository has 971 open issues and publishes both stable and nightly builds. Those counts alone do not establish reliability.

Compared with: Against "open a few agent terminals", it adds three structural pieces: branch-level isolation, a state machine driven by version-control facts, and a planning layer that holds project memory. For other board-style orchestrators I did not read first-hand material, so the comparison stays open: whether worktree isolation is enforced, whether state is derived from CI and pull requests, and whether failures can return to the original session.

Recent updates: v0.14.4 (2026-10-21) lets harnesses update while sessions run, recovers from usage limits and auto-resumes after a reset, and streams the embedded browser preview; on 10-22 it merged a native terminal integration for another agent.

Who it's for: Teams running three or more coding agents at once and losing track of branches and ownership. Apache-2.0; desktop builds cover macOS, Windows and Linux. I would trial it on non-critical work before depending on its recovery behavior.

My take: ⭐⭐ I like the state-driven board; I have not tested recovery or long-running stability.

Checked: README, release notes and recent commits. The desktop app was not installed.

3. trailhq/Trail-Code ⭐ 10,615 · TypeScript

GitHub: https://github.com/trailhq/Trail-Code

In one line: A local code map plus a commit-ready record of what the team has learned, both handed to coding agents.

What it is: Previously called graft. After the rename it has two layers. The map parses the repository with tree-sitter into files, functions and call relationships, with no model and no network, refreshing on uncommitted edits too. Learnings store what a session worked out and what the user corrected. 36 contributors, created in July 2026, 0.23.1 shipped on 10-21.

What stands out:

The split between layers is sharp. The map answers where things are; learnings answer why they are that way and how work gets done here. The README's claim is that a map alone still lets an agent undo a decision a teammate already made.
Learnings are routed by audience. The README places personal preferences in ~/.trail, outside repository commits; decisions about the code live in the repo's .trail/ and travel with it, readable by a teammate's agent before they install anything; a team workspace is marked "soon" and is not available yet.
Conflicts move earlier. Editing code that a teammate's open branch also changes triggers an immediate notice with whether the two clash; trail check flags "you are undoing someone's decision" before the pull request, quoting who decided it and why.
Initialisation reads your history. trail init reads your past sessions in that repo and turns things you repeated into learnings; with gh installed it also reads review comments on the last 50 merged pull requests, with secret redaction described by the project. It uses your own model login and quota rather than the project as a proxy. I have not audited redaction or data handling; local storage does not by itself mean that model requests stay on the machine.
The benchmark reports both cost and correctness. The project reports 162 runs across two repositories, three trials each: the push variant cuts cost from $0.0429 to $0.0292 (-32%), uncached input tokens from 8,070 to 4,650 (-42%), tool calls from 4.2 to 2.3 (-46%) and latency from 39.8 to 15.8 seconds (-60%), with correctness at 93% in both. The pull variant reaches 98% correctness and gives up speed. The project also reports a SWE-bench Verified run solving 33 of 50 real issues with the map and 27 without. I have not reproduced either benchmark.

Compared with: The distinctive choice is storing decisions separately from code structure and routing them by person versus repository. Whether other code-graph tools do the same is unverified here because I did not read their first-hand material; the dimensions are whether decisions and structure are kept apart, whether they are routed per person and per repo, and whether a check warns about overriding someone else's decision.

Recent updates: 0.23.1 (2026-10-21) fixed learnings only reaching the agent when a file was opened; on 10-22 it added shell parsing, command risk checks and new learning fields, extending review from code to commands; 0.23.0 on 10-15 stopped init from leaving an old directory behind.

Who it's for: Multi-person repositories using Claude Code, Cursor or Codex, where the value comes from not re-litigating teammates' decisions. For a solo project, the team-coordination features may matter less. MIT. With 0.23.x moving fast and 281 open issues, try it on one or two repositories first.

My take: ⭐⭐⭐ I would try it for the reviewable decision files before counting on token savings.

Checked: README including the benchmark section, release notes and recent commits. Not installed.

4. semantica-agi/semantica ⭐ 14,175 · Python

GitHub: https://github.com/semantica-agi/semantica

In one line: Enterprise data turned into an ontology-constrained knowledge graph, with every decision stored as a searchable, traceable object.

What it is: A graph-native context layer. It ingests multiple sources, chunks with entity awareness, extracts, builds a context graph and knowledge graph, then runs graph analytics and causal reasoning with W3C PROV-O provenance throughout. Ontologies cover OWL, SHACL and SKOS; reasoning covers forward chaining, Rete, Datalog and SPARQL, and neither graph construction nor reasoning requires an LLM. 138 contributors, created in June 2025, v0.7.0 shipped on 9-22.

What stands out:

A decision is a first-class object. Each decision is searchable, queryable by precedent and causally linked, rather than a line in a log.
Determinism is both the pitch and the constraint. Construction, reasoning and provenance run without a model; LLMs are optional and vendor-neutral. The price is that complex meaning has to be written as rules or ontology first.
Storage is swappable. RDF backends include Oxigraph, Blazegraph, Jena and RDF4J; property-graph backends include Neo4j, FalkorDB, AGE and Neptune, which the project describes as interchangeable without code changes; I have not tested backend parity.
The explainability boundary is stated precisely. It explains only what is outside the model: the context fed in, the decision produced, its provenance, relationships, applied policies and execution trail. It states that it neither exposes nor reconstructs the model's internal reasoning.
Supply chain work is concrete. The project says releases since v0.6.8 carry SLSA build provenance and Sigstore signatures, with .sigstore.json bundles next to the packages. I did not verify those signatures.
Performance figures carry their own caveats. On a 118,000-node graph from v0.5.0, node search went from 24 ms to 0.004 ms (a claimed 6,000x); the deduplication and candidate-generation numbers are noted as historical CHANGELOG measurements rather than automated test assertions.

Compared with: Against Graphiti, whose README I also read, the emphasis differs. Graphiti stresses facts changing over time, incremental updates without recomputation and hybrid retrieval; Semantica stresses ontology constraints, rule-based reasoning, decision objects and compliance exports (PROV-O, SHACL, OWL, RDF). Those are different documented emphases. A provenance trail records inputs and actions; it does not prove that a decision was correct. Production fit depends on retrieval and audit requirements; I did not test either on the same data and make no superiority claim.

Recent updates: v0.7.0 (2026-09-22) cut direct dependencies from 44 to 22 and moved torch, spacy and faiss into optional extras; v0.6.7 added LangChain integration, a SAP OData ingestor, Markdown round-trip persistence and a rule-driven assert/retract reasoning layer; on 10-21 it limited the image parser's formats and sizes and bumped dependencies for security advisories.

Who it's for: Regulated teams that must answer why a system decided something, and enterprises that want graph and provenance self-hosted instead of in a SaaS. MIT, Python 3.10+. The cost is ontology modelling and an RDF learning curve; a lighter install does not mean light usage.

My take: ⭐⭐ Correct direction, heavy engineering; borrow the decision-as-object pattern first.

Checked: README including the boundary and performance sections, release notes and recent commits. Not installed.

5. vllm-project/vllm ⭐ 94,954 · Python

GitHub: https://github.com/vllm-project/vllm

In one line: An open-source LLM inference and serving engine that exposes an OpenAI-compatible endpoint.

What it is: An inference engine that started at Berkeley's Sky Computing Lab and is now maintained by a community that has 3,835 contributors across the repository's history. PagedAttention manages KV memory, paired with continuous batching, chunked prefill, prefix caching and several quantization families. The documentation lists over 200 model architectures and multiple hardware backends. Support must be checked for the chosen model, backend and release. v0.32.0 alone carries 814 commits from 363 contributors, 121 of them new.

What stands out:

More than one API surface. The same process serves an OpenAI-compatible API, an Anthropic Messages API and gRPC; with --api-server-count above one, connections go to the least-loaded API worker.
Low-precision KV expands on specific hardware. NVFP4 KV covers SM8x, SM12x and SM90, and MiniMax-M3 sparse attention on SM100. In the release notes, GLM-5.x defaults to an FP8 KV cache on SM100, halving KV memory per rank, with the pull request's benchmark showing 2.3-5.5% more throughput at a 7-11% cost in time to first token.
Startup time is squeezed too. vllm download-kernels installs precompiled FlashInfer kernels, and vllm preload --preload-autotune keeps the autotune table warm across restarts.
Short-request concurrency has a number. With --api-server-count raised, short requests (Qwen3-0.6B, 32 input and 1 output token) served 43-85% more requests per second in the pull request's benchmark.
Breaking changes are listed plainly. v0.32.0 drops Python 3.10, restricts default CORS origins and removes cascade attention, all of which must be read before upgrading.

Compared with: What the first-hand material supports is breadth: three API surfaces, 200-plus architectures, five or more quantization families and a multi-vendor backend matrix in one engine. I did not read first-hand material for SGLang or TensorRT-LLM and make no superiority claim; the dimensions are throughput and time to first token on the same hardware and model, prefix-cache hit rate, coverage of structured output and tool-call parsing, and how disruptive upgrades are.

Recent updates: v0.32.0 (2026-10-18) adds POST /v1/systemone for structured choice and scoring questions, enabled by default; a generic hf tool and reasoning parser that read a checkpoint's own response template; Model Runner V2 gains a GPU n-gram speculator, Elastic EP and pipeline parallelism; security fixes address three published advisories covering chat-template resource exhaustion, tokenizer bounds and peer-to-peer socket exhaustion.

Who it's for: Teams that want to self-host inference without writing a serving layer. Apache-2.0. Check that the chosen backend and device memory can support the model and workload. Release cadence is fast, so read the breaking changes first. It covers the model side only; ASR, TTS and network latency sit outside it.

My take: ⭐⭐⭐ The easiest part is getting it running; the hard part is choosing a version and a quantization scheme.

Checked: README, the v0.32.0 release notes and recent commits. Not deployed.

At a glance

Project	What it is	Most distinctive	Who it's for	Depth
wshobson/agents	Cross-tool plugin and skill marketplace	One Markdown source generates seven tool formats, with static validation	People switching between coding tools	⭐⭐⭐
agent-orchestrator	Local orchestration bench for many agents	Board state derived from pull-request, CI and review facts	Teams running three or more coding agents	⭐⭐
Trail-Code	Context layer for coding agents	Learnings split between personal and repository, committed with the code	Multi-person repos losing hard-won context	⭐⭐⭐
semantica	Graph-native context and decision provenance	Decisions as first-class objects; construction and reasoning need no model	Regulated teams needing audit exports	⭐⭐
vllm	LLM inference and serving engine	Low-precision KV and startup work advancing together, multiple API surfaces	Teams self-hosting inference	⭐⭐⭐

This week's notes

A skill collection also needs maintenance machinery. In wshobson/agents, generation, static validation and a capability matrix give maintainers something concrete to check when a target tool changes. Those mechanisms need maintenance too.
Agent-orchestrator makes ownership easier to inspect. Separate worktrees, a board derived from CI, and failures routed back to the owning session address the two usual accidents: two agents editing one place, and nobody knowing which session to return to.
Trail-Code reports a cost/correctness trade-off. Its reported push results cut cost by 32% at equal correctness; the reported pull variant reaches 98% correctness and gives up speed. Showing the trade-off is more useful than reporting only the best number.
Audit and cost are being engineered at the same time. One line of work turns decisions into traceable objects; another keeps pushing KV precision and startup time down. These are separate requirements. A useful evaluation would measure serving cost alongside the completeness of the external audit trail; one does not establish the other.

Open Source Radar · 2026-10-21: Skills start getting governed like software packages

十方空烬 · Ember ☄️ — Wed, 21 Oct 2026 06:57:22 +0000

Open Source Radar · 2026-10-21 · By Renchao Wu

Each day I pick five projects rising on GitHub, 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-21. Feature, security and benchmark descriptions below reflect the linked project documentation; I have not independently validated those claims.

One caveat about today's method: both GitHub Trending scrapes (weekly and daily) timed out, so all five entries came from topic search. That means the "rising this week" signal is missing today; I ranked by repository age, last push and average stars per day instead. I come back to this at the end.

1. NVIDIA/skills ⭐ 3,669 · Python

GitHub: https://github.com/NVIDIA/skills

In one line: NVIDIA turned its SDK documentation into 415 installable agent skills, each with a signature, a capability card and an evaluation dataset.

What it is: A catalog that only distributes. Skill bodies live in each product's own repository; an automated pipeline mirrors them here daily, grouped across 56 products (CUDA-X, cuOpt, BioNeMo, DeepStream, Holoscan, Omniverse, Nemotron and others), and a CLI installs them into Claude Code, Codex, Cursor, Kiro and similar coding agents. The repository has no GitHub releases; it iterates on main with a daily sync.

What stands out:

The admission bar lives in the pipeline, not in a document. For a skill to appear under skills/, it must carry three artifacts at once: skill.oms.sig (a detached signature verifiable against nv-agent-root-cert.pem at the repo root), skill-card.md (identity and governance card), and a Tier-3 evaluation dataset. Anything missing is dropped at sync time. That is much harder than asking contributors to submit good skills.
What you install can be verified independently. The model-signing tool verifies a skill directory and confirms the content has not changed since NVIDIA signed it, a provenance check that does not by itself establish correctness or safety.
Benchmark reports ship with the skills. When an evaluation run produces BENCHMARK.md, it is published alongside the skill, so readers see measured uplift instead of a recommendation.
Product teams register in a manifest. One YAML per product under components.d/; plugins.d/ packages bundles, and two marketplace metadata files target different clients.
The format is public. A directory with SKILL.md plus YAML frontmatter (required name and description), loaded by progressive disclosure: metadata at startup, full instructions on activation — the Agent Skills specification.

Compared with: The mechanisms worth comparing are the admission gate and its artifacts: a signature, capability card and evaluation set, plus published benchmark reports where available. I only read this repository, not the admission rules of other collections, so I am not claiming the others lack this.

Recent updates: On 2026-10-21 the sync commit pulled in the CDF family (AnomalyGen, Augmentation, Auto-Labeling, Curation) and the Holoscan SDK, and regenerated metadata.json, skills.sh.json, benchmarks.json and versions.json. The same day pinned the Physical AI component to paidf-26.10. The commit density shows a pipeline running daily.

Who it's for: People using coding agents for CUDA, simulation, robotics or RAG work: a skill supplies instructions for using the corresponding SDK; credentials, tools and permissions still need to be configured separately. Two caveats: the licensing is split (Apache-2.0 for source, CC-BY-4.0 for docs and skills), and skills are mirrored, so upstream changes overwrite local copies — plan on periodic npx skills update, which also flags skills that were merged or removed upstream.

My take: ⭐⭐. Useful as a catalog, but the real value is the governance structure. If you maintain a skill library, the four gates (signature, capability card, evaluation set, drop-on-missing) are worth copying.

Checked: read the README, repository structure, the contents API (415 skill directories) and recent commits; did not install any skill and did not run the signature verification.

2. smol-machines/smolvm ⭐ 6,779 · Rust

GitHub: https://github.com/smol-machines/smolvm

In one line: A microVM packaged as a library you can embed, with the ability to checkpoint a running machine and branch it into copies that keep running.

What it is: A virtual machine runtime that ships as a library. The VMM is libkrun, the guest kernel comes from libkrunfw, and the host side uses Hypervisor.framework on macOS, KVM on Linux, or the Windows Hypervisor Platform. Images are OCI, so compatible images from Docker Hub or ghcr.io can be used without a Docker daemon, and the SDKs run in the caller's process with no separate service. The version is v1.30.1, with three releases in two days (v1.29.1 on 10-16, v1.30.0 and v1.30.1 on 10-17) and more than 100 release records on GitHub.

What stands out:

Branching is the core abstraction, not a side effect of snapshots. A checkpoint captures memory, CPU state and disks. machine branch --from agent yields a copy-on-write child of a live machine that continues from the same instant, and --from <checkpoint> --at '~N' rewinds to an earlier generation. For "one starting point, three paths", that beats running three times.
The defaults are priced to be cheap. Its own table claims "under 200 ms to agent ready"; defaults are 4 vCPUs and 8 GiB, memory is elastic through virtio balloon, and idle vCPUs sleep in the hypervisor. Those are project-reported figures; I did not measure them.
Artifacts travel. A configured machine packs into a single .smolmachine file, can be pushed to any OCI registry, or run as a self-contained executable. The README states a checkpoint taken on an arm64 Mac resumes on arm64 Linux.
Networking is off by default. Egress requires an explicit flag, then per-host, per-pattern or per-CIDR allow rules that can be added and removed on a running machine; a grant applies to the next connection, and revoking a host also clears the addresses it learned.
Credentials can stay out of the guest. With --credential, the guest sees a placeholder and the runtime substitutes the real value on outbound requests, according to the documented credential-proxy design. I did not test whether a guest could recover credentials or use them outside the intended request path.

Compared with: The README carries a comparison table, and the mechanism-level differences are checkable: containers are namespaces over a shared kernel, while this gives each workload its own guest kernel; it is a library rather than a daemon, whereas Firecracker is a process plus jailer; and it supports native macOS and an in-process SDK, two columns where the table lists Firecracker as unsupported. One honest note: it does not win on boot time. The table lists under 200 ms for itself and under 125 ms for Firecracker, so its advantage is platform coverage and embeddability. The table is the project's own and I did not independently verify the Firecracker or Kata figures.

Recent updates: v1.30.1 (10-17) exposes the engine's CLI commands as a library module, avoids redundant disk staging when pause/resume inputs fit in a memory filesystem, and widens the image-pull window for machine creation past five minutes. v1.30.0 pulls large registry blobs in parallel ranged parts. Commits on 10-21, not yet released, handle branch children outgrowing host RAM with OOM victim ordering and a memory-pressure guard. The work is clearly on the hard edges of real multi-branch workloads.

Who it's for: Teams that need to run untrusted agent code. Requirements are KVM on Linux or Apple Silicon on macOS; macOS Intel has no published release build and is marked untested, and GPU acceleration is unavailable on Windows. Know what it is not: it provides a boundary, not a policy. Every mounted directory, allowed host and forwarded secret becomes something the workload can use.

My take: ⭐⭐⭐. "A sandbox you can branch" is more useful than any single feature, because experiments can start from the same VM state. Branching does not undo external side effects.

Checked: read the README, three releases and recent commits; did not install it or boot any machine.

3. pydantic/pydantic-ai ⭐ 20,758 · Python

GitHub: https://github.com/pydantic/pydantic-ai

In one line: The Pydantic team's Python agent SDK, where tools, dependencies and outputs are all typed, and one agent definition runs as a CLI, a web app, a live voice session or a background job.

What it is: A library for defining agents plus a set of sibling components: a harness of capabilities for long-running work, an evaluation package, a typed graph for control flow, a model-pricing package, and a sandboxed Python interpreter for model-written code. The core abstraction is an agent plus capabilities, where a capability bundles tools, instructions, hooks and model settings into one reusable unit; the bundled coding and research agents are compositions of capabilities. The version is v2.58.0, with more than 300 releases on GitHub and both the v1 and v2 lines maintained in parallel (v1.107.8 and v2.58.0 shipped the same day, 10-20).

What stands out:

Types reach the tool boundary. Structured outputs, typed dependency injection, typed tool signatures: your editor and type checker know what an agent returns, which can expose annotated interface mismatches during development. Runtime validation and authorization still need separate checks.
One definition, many interfaces. CLI, built-in web chat, realtime voice, UI event streams, editor-agent protocol and headless CI runs all come from the same agent object, although type checking covers only the paths and annotations actually checked.
Tools can be called mid-sentence in a live voice session. You push microphone audio, play streamed audio back and receive transcripts while the model calls your functions during the conversation. Backends cover OpenAI Realtime, Gemini Live, Azure and xAI Grok Voice.
Durable execution across eight engines. Temporal, DBOS, Prefect, Restate, AWS Lambda, Airflow, Absurd and pgtask, the first five co-maintained with the vendor teams; agents survive restarts, run for days, and support deferred tool calls that wait for human approval.
Evaluations grade tool trajectories. Not just final outputs: evaluation covers the sequence of tool calls, over datasets in code or a sample of live traffic.
A medium-severity security fix landed the same day. The advisory is specific: provider-native MCP configuration could write MCP server URLs, authorization tokens and custom headers into OpenTelemetry request traces even with include_content=False, and a URL-based MCP capability could leak a credential embedded in the URL-derived identifier. Fixed in v2.58.0 and v1.107.8.

Compared with: Its typed interfaces build on an existing validation ecosystem: Pydantic says its validation library is already the validation layer inside the OpenAI SDK, the Anthropic SDK, Google ADK and LangChain, so this path grows out of dependencies that already exist. The README points to a comparison page covering LangChain, Google ADK, the Claude Agent SDK and about ten others; I did not open that page and check it line by line, so what follows describes its mechanisms, not a ranking.

Recent updates: Beyond the security fix, the 10-21 commits tighten boundaries: the tool-call limit is checked before each nested CodeMode call instead of once per turn; the trajectory judge's steering note is bound to its own frame with a reference, so forged feedback tags no longer apply; and grok-4.7 was added to the xAI model table.

Who it's for: Python teams building voice or long-running agents that need evaluation. Two practical notes: 1,564 open issues signal a large surface area, and with v1 and v2 in parallel you should confirm which line your dependencies support before adopting.

My take: ⭐⭐⭐. If your voice pipeline is Python, the combination of in-call tool use, typed boundaries and trajectory evaluation is a skeleton you can build on directly.

Checked: read the README, two releases, the security advisory summary and recent commits; did not install it or run any example.

4. kuafuai/andee ⭐ 1,690 · Kotlin

GitHub: https://github.com/kuafuai/andee

In one line: Install one APK and it uses your phone with a thumb: it reads the accessibility tree and screenshots, and taps grid cells instead of computing coordinates.

What it is: An Android app with no conventional interface. The entry point is an accessibility service, results are drawn in a floating overlay, and its face is a floating ball. The agent loop runs on the phone by default against any OpenAI-compatible endpoint, or the brain can move to a remote host and connect back over a tool-schema contract, so either half can be replaced. It reached 1,690 stars in about a month, with 43k+ lines of Kotlin written first-party and a deliberate refusal to use Compose, a dependency-injection framework or coroutines: overlays cannot host Compose, there is only one service so injection is by hand, and concurrency uses handlers plus dedicated executors.

What stands out:

Screen reading degrades in two steps. Normally it reads the screen as an indented element outline, one line per element with a tappable id; for self-drawn surfaces such as mini-programs, web views and games it falls back to a screenshot overlaid with an 8×12 labelled grid. It taps by "which cell, which third of the cell" rather than computing coordinates, on the argument that general models read grids well and do coordinate maths badly; when a target is tight it zooms in and draws a red crosshair before committing. A fourth tap on the same spot is refused, so a confused model has to stop and ask.
Typing goes through the keyboard's own path. On Android 13 and later it writes into the focused field through the accessibility service's text-commit channel, so the user's own input method stays active.
A password can be used but not read. The vault is encrypted with Keystore AES-GCM on the device; the model can list accounts and have a password typed into the focused field, but no tool returns it, not even masked.
A stranger's notification cannot reach the vault. Turns started by a notification are marked untrusted, and the dispatcher refuses the vault prefix and scene create/enter/delete outright — refused in the dispatcher rather than argued about in the prompt.
It closes its own loops. When a conversation goes quiet it sends itself a turn, reads back alone, closes out promises it made, and ends empty-handed rather than inventing a memory.
The author documents what it cannot do. The security policy lists five known limitations. The heaviest: the on-device WebSocket server listens on 0.0.0.0:9008 and accepts any client without a credential check, so any host that can reach the device on the same network can drive it, read the screen and use saved credentials; the document tells you to assume full control of the device. It also states plainly that there is no sandbox, that checks on risky actions are instructions to the model rather than enforcement, and that mechanical refusal is a narrow exception.

Compared with: Android automation usually takes one of two routes, ADB scripting or accessibility plus coordinate tapping. The mechanism differences here are concrete and point at named files: grid tapping replaces coordinate maths, dispatcher-level refusal is unaffected by prompt text (though it covers only a few paths), and the brain can be separated from the body so a new device is a new port rather than a rewrite. I only read this project, not the code of comparable tools, so I am not asserting what they lack.

Recent updates: v0.5.2 (10-19) fixed aiming on apps that hide their element tree. Its release notes give the numbers: commenting on a WeChat Moments post went from 64 steps and 341 seconds to 20 steps and 58 seconds, sent on the first tap. The author notes both fixes were not new capabilities but stopped wasted turns, found by measuring rather than reading code. v0.5.1 fixed two silent failures: the nightly review dying with the process, and a Xiaomi-family device's power policy killing it in the background with no visible explanation. One candid detail: the attached APK is a debug build, because the release build type has no signing config and the repository has no keystore.

Who it's for: People building on-device Android agents who accept the permission model. Three boundaries to know: an accessibility service plus a floating overlay is one of the broadest grants on Android; it can send messages in your name and it can spend money (the project says there is no payment tool and none is needed, because it taps); and the license is Apache-2.0 with additional conditions — no multi-tenant SaaS, no white-labelling that removes the branding, no embedding in another product without written authorization — so the complete repository terms need review for the intended use.

My take: ⭐⭐. The idea, a resident self rather than a feature set, is more interesting than the feature list, but this version's security boundaries are not yet where daily use would need them.

Checked: read the README, the five known limitations in the security policy, the license terms and three releases; did not install the APK or run it on a phone.

5. EverMind-AI/Raven ⭐ 5,532 · Python

GitHub: https://github.com/EverMind-AI/Raven

In one line: A host agent arranges several specialist agents into an execution graph, while a curator rewrites each one's strategy and must pass verification before installing the change.

What it is: A multi-agent runtime. Given a goal, the host agent decomposes it, matches subtasks to specialists, coordinates dependencies and integrates results. Four agents are built in (research, coding, design, on-call), and third-party agents connect through an editor-agent protocol, a CLI or OpenAI-compatible APIs. Memory and context come from a sibling long-term memory runtime, and skill retrieval goes through its own layer. The technical report is on arXiv (2609.33439), and its abstract makes the argument: as harness complexity grows and harnesses bind too tightly to one domain, the question shifts from building a stronger harness for one domain to automatically constructing specialised harnesses, improving them through experience, and orchestrating them across domains, treating each model–harness pair as a composable unit of intelligence.

What stands out:

The agent loop is split into four replaceable seats. Memory (what a turn gets to see), planning (how to approach the work), capability (which tools an iteration exposes) and action (what to do next and how to judge it before it runs). The curator rewrites those four: sometimes a setting, sometimes a small piece of judgement code written for that agent.
Changes pass a gate, and belong to one agent only. Nothing is installed before it is verified, and a failed check sends it back. A round's signals normally arrive with the reference answer stripped out, which limits how directly the answer is exposed. The curator is marked experimental and ships with the repository rather than the installed package.
The config tool keeps its manners. It reads any setting without asking, asks before every write, and never takes a key through the conversation.
Orchestration is a dependency graph. v0.2.5 added conditional branches inside workflows and delegation to remote agents on registered machines, using that machine's agent capabilities and working environment for the subtask.
A persona is the first thing it builds. Describe the assistant you want and the curator assembles one: a lead role that talks to you plus specialists drawn from agents you already have, with your requirements landing in that assistant's harness — its division of work, the tools it may reach for, the checks it must pass.

Compared with: The difference is who rewrites the harness. Here the rewrite right sits with a separate curator, limited to one agent's four strategy seats and gated by evaluation before install. Those are concrete mechanisms to compare with another runtime. I did not check whether other agent runtimes also allow runtime rewriting, so I am not claiming this is unique.

Recent updates: v0.2.5 (10-20) strengthened multi-agent coding, added remote agent execution on registered machines, conditional branches in workflow graphs, improved native Windows support, and opened the trajectory view to everyone. v0.2.4 (10-03) added the config tool and new approval keybindings. v0.2.3 (09-27) made the bare command open a browser page. The project labels itself pre-alpha at the top of its README, and says interfaces and configuration will change quickly.

Who it's for: People researching harness self-evolution, or experimenting with replaceable strategies in their own agent systems. Three realities to accept up front: pre-alpha; a 255 MB repository that is a large engineering effort; and effect numbers in the README (172 training runs cutting a validation metric by 5.8%, an out-of-bounds fraction in a dam-break simulation going from 1 to 1.36e-10, a finite-element bisection bracket narrowing from 1800–2000 kN to 3.125 kN) that all come from the project's own reports and charts. I reproduced none of them.

My take: ⭐⭐. Copy the structure — four seats, a verification gate, stripped reference answers — not the conclusions.

Checked: read the README, the arXiv abstract, three releases and recent commits; did not install it or reproduce any benchmark.

At a glance

Project	What it is	Most distinctive bit	Who it's for	Worth digging in
NVIDIA/skills	Agent skill catalog	Signature, capability card and evaluation set as an admission gate	People using coding agents for CUDA, simulation, robotics	⭐⭐
smolvm	microVM sandbox	A live machine branches into copy-on-write children	Teams running untrusted agent code	⭐⭐⭐
pydantic-ai	Python agent SDK	Types to the tool boundary, tools callable mid-conversation	Python teams building voice and long-running agents	⭐⭐⭐
andee	On-device phone agent	Taps grid cells, not coordinates; brain separable from body	Android agent builders who accept broad permissions	⭐⭐
Raven	Multi-agent orchestration	Self-rewrites must pass verification before install	People researching harness self-evolution	⭐⭐

This week's notes

Skill governance is starting to look like package management. Signatures, capability cards, evaluation sets, drop-on-missing — that machinery belongs to package managers and supply-chain security, and it is now being applied to "how an agent should use this SDK". Skills are turning from prompt fragments into artifacts with versions, provenance and evaluations.
Isolation is moving down to a single execution. On one side, each workload gets its own kernel and a running machine can branch from its current state. On the other, "untrusted sources cannot touch sensitive resources" becomes a refusal inside the dispatcher. Both put the boundary in a code path instead of trusting the model — but the maturity gap is wide: smolvm documents a VM boundary that I have not tested, while andee's own security policy says its mechanical refusal covers only a few paths.
Voice pipelines need checks beyond conversation quality. Typed interfaces and trajectory evaluations provide ways to test action selection; neither is proof that the pipeline will reject every wrong action. The reported MCP tracing advisory is a concrete reason to check affected versions and redaction behaviour, including when content capture is disabled.
"Let the agent rewrite itself" is acquiring an auditable shape, but it is early. Splitting strategy into four seats, requiring verification before install, stripping reference answers from signals: that is a process you can discuss and reproduce. The price is that the project labels itself pre-alpha and every effect number is self-reported. At this stage it is worth reading the design and keeping the reported results separate from independent reproduction.

Doze Sort: let a local model file the notes, and keep the originals

十方空烬 · Ember ☄️ — Tue, 20 Oct 2026 11:01:52 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

I built Doze Sort for a small pile of notes with filenames like note-03.md. Opening each file to decide where it belongs is the part I wanted to hand off.

The app uses an open-weight model to compare the contents with topic descriptions. It makes a plan first. After I inspect that plan, one batch action creates copies in the proposed folders. A low score or close result goes to _review. Exact byte duplicates point to one canonical copy.

I chose to keep the original pile. That means this is an organized working copy, not a tool that empties a messy folder. It also means a bad category does not lose the source note. Undo moves the completed run into recovery and retains its files.

The intended user is someone with a small English Markdown or text inbox who wants help filing it. The browser demo is restricted to the fictional files included in the repository; the CLI accepts an inbox and topics chosen by the person running it. It never scans other folders in the background.

I started this new project and repository on October 20, inside this week's entry period. The sorter, copy/recovery logic, UI and example notes are new. I reused an installed personal Python environment and cached model weights.

Demo

Watch the 35-second walkthrough using GitHub's Download raw file button. I assembled it from real captured browser states; it is not a continuous recording.

The demo has three actions: make a plan, create organized copies, and undo the run. The actual test produced 12 unique copies from 14 files. Two duplicate originals referenced canonical copies, and two uncertain copies went into _review. Undo retained the run in recovery with zero files deleted.

The local app runs on the laptop at a loopback address. The README includes setup and offline startup instructions. I checked the 375px layout with no horizontal overflow. The browser demo does not let a visitor upload files or supply arbitrary paths.

Code

MIT source, original notes, tests and recorded results

The examples cover cooking, gardening and travel. They are fictional original material. No client or employer files, credentials, dependencies or model weights are committed.

How I Built It

all-MiniLM-L6-v2 is the content classifier. It has Apache-2.0 open weights, and I pinned its revision. Sentence Transformers runs it on CPU, producing normalized 384-dimensional embeddings for each note and topic description.

Cosine similarity chooses a topic only when the top score is at least 0.30 and the top-two gap is at least 0.06. Those thresholds are heuristics, not probabilities. The model can still miss a mixed-topic note. Deduplication is separate: only identical SHA-256 bytes count as duplicates. Similar meanings never cause notes to be merged.

The copy engine checks the source filenames and hashes again before applying a plan. A changed inbox needs a fresh plan. It writes into a staging directory before exposing the completed run. Reapplying the same plan stops without making another copy. Undo checks for edited or unexpected output files and leaves the run in place if it finds them.

Seven behavior and integration tests passed, including stale input, original byte preservation, duplicate references, replay prevention, edited or extra output, symlinks, path checks, token rejection and recoverable undo. These checks assume a stable local filesystem; I have not built a service for hostile concurrent writers. A failed filesystem operation may leave a staging directory for manual inspection.

I ran cached inference with offline flags. Unsupported files are skipped, while empty text, non-UTF-8 content and notes above the model token limit are rejected. Only visible top-level .md and .txt files are processed, with no recursion. Plans contain local paths and excerpts, so a person using private notes should keep the plan private too.

Why Does Open Innovation Matter?

After caching the weights, I can classify notes without an internet connection or a per-file API charge. The text stays on the computer running the model. The app's page loads local assets and has no analytics, remote fonts or background folder watcher.

The policy is inspectable as well. I can change the topic descriptions or the score threshold and run the same example inbox again. A different embedding model could replace MiniLM. The exact-duplicate and recovery logic would remain available to inspect independently of that choice.

Open weights make this useful on a small local workflow, although installation, model storage and running the laptop still have costs.

The Lazy Payoff

I used the included 14-file fictional inbox to run the full plan, copy and undo sequence this week. All 14 original files remained byte-identical, the recovered run was preserved, and no files were deleted. One action produced the categorized snapshot instead of filing each note separately.

The complete diagnostic report records 13 of 14 intended outcomes. The failure is a note about baking, herb pots and a train: the model chose cooking when I wanted it held for review. I kept that result. Inspecting the plan still matters, and the CLI lets me change a wrong proposal to _review before applying it.

Warm planning had a median of 14.92 ms across five runs, excluding model loading. First planning took 25.40 ms and copying took 1.87 ms. These are local machine timings on a tiny author-written set. I did not measure a human filing session, test a real personal inbox or conduct an external user study, so I cannot claim a number of minutes saved.

The tested convenience is a batch plan with recoverable output. Choosing useful topics, handling bad suggestions and managing stored snapshots remain my responsibility.

Open Source Radar · 2026-10-20: The agent stack starts keeping its own books

十方空烬 · Ember ☄️ — Tue, 20 Oct 2026 06:55:53 +0000

Open Source Radar · 2026-10-20 · By Renchao Wu

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-20. Features and results below are described by the linked projects; I have not independently tested their performance, billing or security claims.

1. headroomlabs-ai/headroom ⭐ 76,334 · Python

GitHub: https://github.com/headroomlabs-ai/headroom

In one line: It compresses tool outputs, logs, files and retrieved chunks before they reach the model, with the aim of reducing input size while retaining what the task needs.

What it is: A context compression layer with three doors: a library (compress(messages)), a local proxy on port 8787 that needs no code changes in any language, and an MCP server exposing headroom_compress, headroom_retrieve and headroom_stats. The repo opened in January 2026 and now has 76,334 stars, 337 contributors and 174 releases; the version is 0.41.0, roughly one minor per week.

What stands out:

It routes by content type instead of cutting everything the same way. A router classifies the input as JSON, source code or prose, then hands it to a JSON compressor, an AST-based code compressor, or a small open model for text. Results depend on repetition: in the project's own benchmark, code search went from 17,199 to 13,597 tokens (21% saved), an SRE incident debug from 55,957 to 24,340 (57%), codebase exploration from 58,801 to 33,895 (42%), GitHub issue triage from 46,067 to 32,429 (30%). Repetitive JSON arrays and logs clear 90%; prose barely compresses, which the docs say outright.
The original remains retrievable. Originals are cached locally and fetched back through headroom_retrieve when the model needs detail. In the SRE scenario the FATAL line survives byte for byte, a useful example that does not establish answer equivalence for every workload.
It flags changes that could invalidate a cached prefix. One component flags volatile content that would bust a provider's cached prefix, and only flags it, never rewrites the prompt. Plenty of compression schemes save input tokens and then lose more to cache misses.
It trims output too. The project also targets avoidable output, including "Great, let me…" openers and code printed straight back. Two switches handle it: a terse-instruction appended to the end of the system prompt (at the end, to preserve the existing prefix where possible) and lower reasoning effort on turns that merely resume after a file read or a passing test.
There is anonymous telemetry, and it can be turned off with HEADROOM_TELEMETRY=off.

Compared with: Microsoft's LLMLingua (6,760 stars) is a compression algorithm and library for prompts and KV cache, claiming up to 20x; it focuses on compression methods. Headroom bundles routing, retrievability, cache alignment and a savings ledger, and can sit in front of an existing agent as a proxy. For built-in auto-compaction in coding assistants, retrieval and transcript retention vary by assistant; check both on the version in use.

Recent updates: v0.41.0 (2026-10-13) added a Google Antigravity IDE integration, the OpenCode 2.x plugin API and a spend/savings dashboard for the Rust proxy. On 10-16 came per-request counterfactual savings records and the telemetry off switch. On 10-17 turn-level rewriting was extended from the Anthropic path to OpenAI Responses over both HTTP and WebSocket.

Who it's for: Anyone feeding large JSON, logs or retrieval results to a model, especially people building their own agent. Two caveats: by default it also registers a code-navigation MCP server, so read the flags if you only want compression; and be careful compressing numeric data, since saved tokens must not cost you the ability to re-check a conclusion.

My take: ⭐⭐⭐ The proxy interface is worth evaluating when several applications need the same compression and accounting controls.

Checked: read the README, the v0.41.0 release notes and recent commits, reviewed the project's four-scenario benchmark and accuracy table, did not install.

2. mastra-ai/mastra ⭐ 28,929 · TypeScript

GitHub: https://github.com/mastra-ai/mastra

In one line: A TypeScript framework for agent applications that ships workflows, suspend-and-resume, memory, evals and tracing in one set of packages.

What it is: A Y Combinator W25 company's framework, opened in August 2024, now 28,929 stars, 700 contributors and 129 releases, with 1.32 million weekly npm downloads for the core package. The layers are clear: agents, a graph-based workflow engine (.then(), .branch(), .parallel()), execution state in storage, memory and retrieval, evals and observability, plus unified routing for 40+ model providers and MCP server authoring. It embeds in Next.js or Node, or runs as a standalone server.

What stands out:

Suspend and resume live in storage, not in an in-memory callback. Execution state is written to storage and can resume days later. Release 1.78.0 fixed a run of durability defects: a .foreach() failure now fails the run properly instead of hanging or corrupting output, resume after a crash preserves suspended data, and invalid resume data raises a dedicated error without consuming the suspended run. Those defects are useful regression cases to inspect before deployment; their fixes alone do not establish production readiness.
Multi-tenant identity is part of the agent. Agent.scopes (<type>:<value>) can come per call, from agent config, or from trusted middleware, and all three are merged; memory can derive resource and thread from resource: and thread: scopes, with conflicts returning HTTP 400. Serving several users from one agent makes this layer unavoidable.
Traces aggregate instead of merely listing. POST /observability/traces/aggregate groups by dimensions, with client and React entry points; list endpoints return only input and output previews, computed at write time, so browsing does not read full payloads.
Signals queue, they do not interrupt. Agent.queueSignal() places a typed signal behind the active run without degrading it into a plain user message.
The licence is open core. The repository root is Apache 2.0, but enterprise features under ee/ have separate source-available terms. Check whether the features you need sit behind that line.

Compared with: LangGraph (43,542 stars) describes itself as a low-level orchestration framework for building stateful agents, with a different packaging and orchestration approach; Mastra starts from TypeScript and bundles server, storage, React client, evals and tracing into one line. Vercel's AI SDK (27,407 stars) sits lower — how to call a model, how to stream — and Mastra adds workflows, memory, evals and multi-tenancy on top. For an SDK comparison I would separately check supported model providers, durable state and tracing integration.

Recent updates: @mastra/core 1.78.0 (2026-10-16) introduced multi-tenant scopes, trace aggregation and signal queueing; the same release deprecated two preview APIs and removed the Factory session modes, so expect API movement in the 1.x line. On 10-20 came fixes for keeping earlier tool calls across durable retries and for applying payload transforms to streamed tool calls.

Who it's for: TypeScript teams shipping agent applications that need approval steps, multi-tenancy and post-hoc inspection. For single-turn question answering it is too much framework.

My take: ⭐⭐⭐ Storage-backed resumption, identity scopes and trace aggregation are the parts I would inspect first.

Checked: read the README, the 1.78.0 release notes and recent commits, compared the root and enterprise licences, looked up weekly npm downloads, did not install.

3. monid-ai/monid ⭐ 5,402 · TypeScript

GitHub: https://github.com/monid-ai/monid

In one line: It turns each vendor API into a declarative connector so an agent reaches tools through one address, with billing settled per call.

What it is: It calls itself OpenRouter for agent tools. The repository is not the hosted service but the connector layer plus engine: one directory per provider declaring identity, how auth is injected and how usage is billed; each endpoint declaring its path, input schema and timeouts. Opened on 2026-08-26, it has 5,402 stars and 10 contributors, with 34 providers in connectors/ while the README claims 2,000+ tools across 72+ providers on the platform. The open repository and the platform catalogue are different counts, so do not mix them.

What stands out:

The billing model is a connector field. It can be a flat charge per call, a charge per returned result, or a rate per unit such as a thousand characters or a second of video. The engine settles on the raw response envelope, before any output mapping, so what is billed is what came back over the wire. The documentation describes zero settlement for vendor errors and specified no-result outcomes such as unmatched companies or unresolved people; I did not verify billing against the hosted service. Whether a failed call costs money now has a default answer, and that matters more than tool count.
The endpoint is chosen at call time. discover ranks the whole catalogue against the job and returns each candidate with its price, live health and observed p50 and p95 latency, plus hints for a cheaper or better fit. discover and inspect are free; only run is billed.
No per-vendor execution path. A provider declares auth and billing; an endpoint declares method, path, schema and timeouts. The README puts it plainly: no client, no adaptor, no per-provider execution path. A coding agent that can read API docs can write a connector.
Contract and tooling are separated on purpose. Schema and compiler are declared contract, loaded without overrides by a module that never reads environment variables, because bundle bytes must be a pure function of repository content; a single connector function is capped at 32,768 bytes of source.

Compared with: Composio (30,646 stars) solves connecting, authorizing and running in a sandbox, with 1,000+ toolkits and tool search; Monid solves which vendor this call should take, at what price, and who eats the failure. The former is an integration asset, the latter a set of comparable endpoints carrying price and health. Against OpenRouter, it moves routing from models to tools. The cost is that the platform is theirs: the README is written for platform access, has no self-hosting section, and the open code is the connectors and engine rather than a complete service you can stand up.

Recent updates: catalog-v0.0.4 (2026-09-30) was the third catalogue release; on 10-15 eighteen Apify actors landed in one connector; the dataforseo connector arrived in batches (2 of 5) on 09-28; on 10-16 the project was still polishing the process around contributors emailing after opening a pull request.

Who it's for: People wiring many third-party data sources into an agent who want to compare cost at call time. With two or three internal endpoints, a gateway is overhead.

My take: ⭐⭐⭐ The per-call settlement idea is worth copying even if the platform is not.

Checked: read the README including connector authoring and config contract, the catalogue releases and recent commits, counted providers in connectors/, did not install.

4. dyad-sh/dyad ⭐ 21,994 · TypeScript

GitHub: https://github.com/dyad-sh/dyad

In one line: A desktop AI app builder that runs locally, with your own keys, a live preview, and one-click pushes to a repository and a host.

It is: An Electron desktop application: describe an app, generate it, run it on your machine, sync to GitHub or GitLab, deploy to Cloudflare or Coolify. Opened in April 2025, it has 21,994 stars, 36 contributors and 150 releases. Its own positioning is blunt: like Lovable, v0 or Bolt, but running right on your machine.

What stands out:

Local-first is a constraint, not just a slogan. Files and previews are managed on the machine and the user supplies model credentials. Local execution does not establish that model requests or credentials never reach a configured provider. The price is that it must execute code a model wrote, so execution isolation needs review. The 10-19 worker-thread change should not be treated as a security boundary by itself.
The deployment surface is broad. The source shows Cloudflare deploy, Coolify deploy and setup, Neon and Supabase admin, and GitHub operations as first-class modules. v1.20.0 added GitLab publishing, including self-hosted instances with Coolify deploys, the most substantial feature in that release.
Sync reports what it pushed. A new commit makes GitHub sync show each sync's actual contents instead of a success tick.
The licence is mixed. Everything outside src/pro is Apache 2.0; src/pro has separate Functional Source License 1.1 terms. Review the relevant files and their terms for the intended use. Commercial features live in that directory, so check the fence before adopting.
Maintenance load is visible. 351 open issues, 36 contributors carrying 150 releases, and a noticeable share of recent commits from bots. These are maintenance signals to inspect, not installation or reliability results from this review.

Compared with: Dyad puts editing, preview and deployment controls on the desktop. Its model data path depends on the selected provider; the README's “running right on your machine” wording does not establish local inference. I would compare its preview-and-deploy workflow with an IDE coding agent such as Cline (70,576 stars), then check whether each fits a new app or an existing repository. Generation quality still depends on the model in use.

Recent updates: v1.20.0 (2026-10-19) added GitLab publishing, a recent-deployments list on the Cloudflare card and GitHub sync reporting. On 10-16 Cloudflare deploys learned to convert plain Vite apps to Nitro; a Windows-specific fix named the .cmd shim when wrapping pnpm.

Who it's for: People who want desktop management of a small app, with an explicit review of what the configured model and deployment providers receive. For a long-lived product, weigh the mixed licence and the maintenance pace first.

My take: ⭐⭐ Worth one try, not worth building infrastructure on.

Checked: read the README and licence files, the v1.20.0 release notes, recent commits and installer download counts, and looked at the source tree, did not install.

5. withmarbleapp/os-taxonomy ⭐ 6,237 · JavaScript

GitHub: https://github.com/withmarbleapp/os-taxonomy

In one line: An open curriculum graph for primary education: 1,591 micro-topics and 3,225 prerequisite edges, each topic stating what counts as mastery.

What it is: A pure data repository, six JSON files under data/, no runtime and no dependencies. Nodes are micro-topics, the smallest teachable idea; edges say topic X depends on prerequisite Y, each tagged hard or soft with a one-line reason. It also ships alignment to national curriculum standards, 176 parent-facing domain summaries and roughly 24 MB of teaching research. Opened in July 2026, it has 6,237 stars and 1,017 forks but only 3 contributors and no releases: high attention, low collaboration.

What stands out:

Each topic carries its own acceptance test. Beyond name and description, a topic has observable evidence of mastery (for example, distinguishing complete sentences from fragments), a natural-language prompt you could ask a child, and a type: conceptual, procedural, representational, language or meta. That is what separates it from a flat standards list.
Edges carry strength and reasons. With direction and justification you can compute what a learner still lacks before a topic, and invert it to see what mastering a topic unlocks.
Gaps are explicit fields. Teaching research covers 547 science and 504 mathematics topics; the remaining 540 have none, listed in a coverage field, and the README says absence is not a judgement about whether a topic can be taught.
It admits the content was model-written and the sources were not re-checked. Research records were written by a model, learning guidance was checked by a separate factual critic and sampled by a second model; verified: true is explicitly declared not to be a new evidence rating, sources were not re-fetched, and activities are research-informed proposals rather than empirically validated interventions.
The licence is layered and distinguishes a derivative database from a produced work. The database and relationships use ODbL 1.0; authored text uses CC BY-SA 4.0; third-party standards keep their upstream licences, with restricted passages replaced by codes only.

Compared with: OpenSALT (45 stars, a PHP standards-alignment tool) is software for managing standard-to-competency mappings, and you supply the data; this repository hands over the graph with prerequisites, mastery evidence and teaching research, ready for path computation. Against a standards document or a plain topic list, what it adds is edges and evidence: a list tells you what exists, this tells you what to learn first and how good is good enough.

Recent updates: No releases; it iterates on the main branch. On 10-19 three classes of data bug were fixed in a row: prerequisites whose age preceded the topic depending on them (#35), orphaned science clusters plus domain reference validation (#32), and realigning teaching research after chart topics were split (#31). The split-out pie-chart topic adapts existing research rather than a fresh literature review, and every reused source-verification flag is false.

Who it's for: People building education products, curriculum sequencing or learning-path recommendations, and anyone who wants a sample of how to annotate evidence in a knowledge graph. It is data, not software; do not expect an API or a UI.

My take: ⭐⭐⭐ Half the value is the graph; the other half is how plainly it states what was never checked.

Checked: read the full README including data fields, research methodology and licence layers, the manifest and validation script notes, and recent commits; did not download the data or run validation.

At a glance

Project	What it is	Most distinctive	Who it's for	Worth a deep dive
headroom	Context compression layer	Reversible compression, cache-safe, with a savings ledger	People building agents who feed them big JSON and logs	⭐⭐⭐
mastra	TypeScript agent framework	Resume backed by storage; multi-tenancy and trace aggregation built in	TypeScript teams shipping to production	⭐⭐⭐
monid	Agent tool gateway	Billing model declared per tool; endpoint picked by price and latency	People wiring many third-party data sources	⭐⭐⭐
dyad	Local AI app builder	Desktop editing and preview, configurable model and deployment providers	People who want a small app that runs and deploys	⭐⭐
os-taxonomy	Open curriculum graph	Mastery evidence per topic; gaps and unverified sources in fields	Education products and knowledge-graph work	⭐⭐⭐

This week's notes

Context saving has moved from a trick to a layer. Headroom ships a minor every week with 337 contributors, which makes its maintenance activity worth looking at; it makes four things default — what to compress, how to get it back, how not to break the cache, and how much was saved. When judging an agent stack now, ask whether it has this layer rather than how clever its prompts are.
Durability and identity handling deserve a closer look. One Mastra release is mostly tenant isolation, durable retries, crash recovery and trace aggregation: nothing anyone demos, everything production asks for.
The tool layer has started keeping accounts. Monid makes zero settlement on failure, per-result billing and price comparison at call time part of the protocol. Comparable billing rules are useful alongside tool coverage.
Honesty about a knowledge base can be a field. os-taxonomy says outright that a model wrote the content, sources were not re-checked, and verified is not a rating. That is more instructive than stamping everything as verified.
Local-first products are open-sourcing the price too. Dyad puts its sandbox, mixed licence and 351 open issues on the table. Copy the experience and you inherit the risk.

Open Source Radar · 2026-10-19: Agents start proving what they did

十方空烬 · Ember ☄️ — Mon, 19 Oct 2026 06:52:50 +0000

Open Source Radar · 2026-10-19 · By Renchao Wu

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-19. Feature and benchmark descriptions reflect the linked project documentation; I have not independently tested their performance or security claims.

1. apache/maka ⭐ 5,847 · TypeScript

GitHub: https://github.com/apache/maka

In one line: A local agent workspace that writes every model call, tool call and permission decision to an append-only log, with the desktop app, the terminal and the evaluator all reading that log.

What it is: An Apache incubating project that reached 5,847 stars and 146 contributors in five months. The core is a Runtime Host: each state root has exactly one execution and write authority, and the Electron desktop app, TUI, CLI, bots and evaluation client all cross the same protocol boundary. Data stays in local SQLite. The evaluation work is published task by task: the project reports that on all 89 Terminal-Bench 2.1 tasks with the same DeepSeek V4 Flash model, Maka passed 61/89 (68.54%) and OpenCode passed 49/89 (55.06%); 16 tasks passed only under Maka and 4 only under OpenCode, with an exact McNemar test at p=0.0118.

What stands out:

The log is the source of truth, not an audit trail bolted on later. The UI, the next prompt and crash recovery are all projections of RuntimeEvents. Context pruning changes what the provider sees, never the history. Old tool output can leave the prompt without leaving the log.
It accounts for "ran out of budget" separately from "could not do it." In the same report, 15/89 Maka cells hit budget exhaustion (16.85%) against 24/89 for OpenCode (26.97%). Most benchmarks count a timeout as a plain failure; this split is closer to real operations.
Cost is measured per pass, not per run. $0.031718 versus $0.031712, a 0.02% difference, and the report states plainly that this is a single-run point estimate, not a test of equivalence. I would read the task-level results before using the aggregate to choose a runtime.
Multiple machines do not merge execution authority. Peer Mesh handles membership and connections, a Rust native addon handles direct peers, and each state root still has one writer.
Local-first has a stated price. API keys sit in a local plaintext file protected only by the OS account, and older JSONL transcripts are not imported after an upgrade, so an upgraded workspace can show empty threads.

Compared with: For this comparison, I would start with Maka’s published per-task CSV, paired test and cost model. Its event-first architecture is useful to examine alongside the workflow definitions in LangGraph or Temporal; these are different design choices, not evidence that other runtimes lack auditability.

Recent updates: 0.2.1-dev.91 (2026-10-18, nightly). Commits on 10-19 include prepare 0.2.2 and correct source packaging (#6148) plus two UI fixes: a race between session settings and sending (#6150), and preserving running tool state on reconnect (#6145). The formal Apache release is still 0.2.0, and the nightly is explicitly marked as not approved by a release vote.

Who it's for: Teams building their own agent runtime who care whether a run can be replayed afterwards, and anyone doing compliance review that needs execution traces. Expect version churn during incubation, and keep nightly builds out of production.

My take: ⭐⭐⭐. The feature list is not the point; the event log and the published evaluation are worth reading the architecture doc for.

Checked: read the README, ARCHITECTURE.md, the Terminal-Bench report under docs/eval, releases and recent commits. Not installed.

2. zvec-ai/zvec-grep ⭐ 4,118 · Rust

GitHub: https://github.com/zvec-ai/zvec-grep

In one line: Ripgrep, BM25 and vector search behind one local MCP interface, so an agent finds evidence with fewer calls.

What it is: The command is zg, the index lives in .zvec-grep/ under the project root, humans use the CLI and agents use MCP. Embeddings run locally by default; remote embeddings receive data only with explicit permission. The vector engine underneath is Alibaba's zvec. Three months brought 4,118 stars and 15 contributors, with only two formal releases (v0.1.5 and v0.2.0) while the main branch moves much faster.

What stands out:

Lexical and vector queries share one interface. One MCP call can carry both fts and vector inputs: exact identifiers go through lexical matching, vague descriptions go through embeddings, and the results are fused and ranked.
Code gets structure. The index keeps symbols, signatures and breadcrumbs; change #181 on 10-19 adds symbol metadata and file-graph contracts, aiming to make cross-file call chains searchable objects rather than text chunks.
The benchmark measures context saved. SWE-QA20 uses 20 fixed questions across 11 repositories pinned to commits, with hybrid, fts and vector arms repeated five times each for 300 calls; there are also BEIR with 75,128 documents, DuRetrieval with 100,001 passages, and Quarry with 20 repositories in eight languages. Metrics are Hit@1/5/10, MRR and nDCG, plus output size and latency.
CI compares retrieval quality. Every pull request runs a base / head / delta comparison and posts it back as a PR comment, so retrieval regressions surface before merge.
Slow version numbers, moving interfaces. v0.2.0 calls itself the first full public preview, so read the breaking changes before upgrading.

Compared with: ripgrep offers lexical and regex matching only; zvec-grep adds ranked lexical and vector retrieval with a project-local index. For alternatives such as claude-context or an IDE index, I would check the configured embedding provider, data path and index visibility separately. The difference here is two fusible arms plus an index that lives inside the project, where it can be inspected, deleted or rebuilt.

Recent updates: v0.2.0 (2026-08-27) brought hybrid retrieval, structure-aware indexing, managed agent integrations, local and remote embeddings, and incremental updates. 10-15 added Pi agent support (#250); 10-19 added symbol metadata (#181) and fixed an EPIPE when stdout closes early (#241).

Who it's for: Teams whose code and documents sit in the same tree and whose agents keep failing to find things, and anyone who wants data to stay on the machine. Apache-2.0, Node 22 or newer.

My take: ⭐⭐⭐. I would start an evaluation with one subdirectory, then check the retrieval results and indexing cost before expanding to an entire workspace.

Checked: read the README, benchmarks/README, releases and recent commits. Not installed.

3. simstudioai/sim ⭐ 29,836 · TypeScript

GitHub: https://github.com/simstudioai/sim

In one line: A visual platform that puts agents, workflows, tables, files and knowledge bases into one workspace, hosted or self-hosted.

What it is: Chat on the left, a workflow editor on the right, and shared tables, files and knowledge underneath. The README claims 270+ integrations, 5,400+ actions and 520+ triggers. The repository dates to 2025-01, with 53 contributors and more than 100 releases, including three versions in four days. The stack is Next.js, Bun, PostgreSQL, Drizzle and ReactFlow, with E2B for remote code execution, isolated-vm for isolated execution and Trigger.dev for background jobs.

What stands out:

The product unit is a workspace, not a single flow. Tables are a built-in database, files are storage shared by the team and every agent, and knowledge bases are synced documents; one permission model covers all of them.
Self-hosting is a first-class path. npx sim-setup creates a deployment directory, generates secrets, provisions the database and starts images, with doctor, config and add <capability> alongside; email, storage, sandbox, jobs, cache and knowledge can be enabled separately.
Most of v0.9.26 is security work. It removes a client route that let a run's actor rewrite its own log and cost (#9183), revokes sessions and OAuth grants on password reset (#9178), pins Salesforce instance URLs to Salesforce domains and guards custom-field egress (#9177), and ends OAuth grants when SCIM changes an address (#9181). These changes concern tenant-facing access boundaries; the release notes alone do not establish deployment scale or security.
The desktop app reuses the same backend. The macOS 12+ client can point at a self-hosted deployment instead of running a second runtime.
Self-hosting is not light. The docs require Node 20+ and Docker, and local development notes call for 12GB of memory or more.

Compared with: Sim’s built-in tables, files and knowledge bases are the features I would compare against n8n, Dify or Langflow. Shared storage and permission boundaries need checking in each deployment; an integration count alone says little about whether a workflow fits.

Recent updates: v0.9.26 (2026-10-17) lets Chat read and write Project files (#9034), adds Microsoft Sentinel ingestion (#9162), expands Databricks API coverage (#9163) and adds core Oracle Fusion financial operations (#9165); computer use rolls out per organization (#9182).

Who it's for: Teams stringing several SaaS tools into agent workflows while requiring data to stay in their own database. Budget for self-hosting operations, and expect uneven depth across 270 integrations.

My take: ⭐⭐. Worth reading for the capability plug-in model and the log permissions design; moving the whole platform in is heavy.

Checked: read the README, the v0.9.24 to v0.9.26 release notes and recent commits. Not deployed.

4. QwenLM/qwen-code ⭐ 28,567 · TypeScript

GitHub: https://github.com/QwenLM/qwen-code

In one line: An open-source coding agent for the terminal with documented entry points for IDEs, desktop, the web and four chat platforms.

What it is: qwen is the main entry point, with SubAgents, Agent Teams, dynamic workflows, Auto-Memory, Auto-Skills, hooks, MCP, Plan Mode, LSP, a sandbox, Git worktrees and computer use. There are also VS Code, Zed and JetBrains plugins, a desktop app, a qwen serve web UI, TypeScript, Python and Java SDKs, and a headless mode. The repository dates to 2025-06, with 420 contributors and more than 100 releases.

What stands out:

Multiple models head to head on one task. Agent Arena runs the same task across several models; that makes model comparison an explicit workflow to inspect.
The daemon is a service, not another terminal. qwen serve turns the agent into a multi-client execution body over HTTP and SSE (ACP), so the CLI, IDE, web UI and chat channels share one session.
Chat channels live in the main repository. Telegram, DingTalk, WeChat and Feishu, started with qwen channel start; the skeleton from inbound message to agent reply is already there.
SWE-bench is reported as a range, not a peak. Seven versions on the same Qwen 3.7 Max model, 500 tasks and three trials per version average 76.40% to 77.80%. Stable across versions, with no single best score to advertise.
Protocols are not locked in. OpenAI, Anthropic, Gemini and Qwen protocols, plus third-party providers and local models through Ollama or vLLM, switchable at runtime.

Compared with: For embedding in another system, I would compare Qwen Code’s three SDKs, daemon protocol and channel support with the interfaces exposed by Claude Code, Gemini CLI, OpenCode and Cline. A shared feature name does not establish behavioural parity.

Recent updates: v0.25.3-preview.0 (2026-10-16) is mostly stability work: journal-only settlement of interrupted turns (#14160), stopping each child's running turn when a subagent closes (#14218), and a restart-proof runtime drain (#13986). 10-19 added warming workspace-isolated workers when an empty session is created (#14599), a configuration template for the managed distribution (#14631), and private file turns through the hosted harness (#14487).

Who it's for: Teams that want an open-model coding agent without a single-protocol lock-in, and developers embedding coding ability into their own product. Apache-2.0, Node 22 or newer. Expect fast iteration on preview builds.

My take: ⭐⭐⭐. The valuable part is turning the agent into a service, not the terminal UI.

Checked: read the README, the v0.25.3-preview.0 and nightly release notes, and recent commits. Not installed.

5. makecindy/cindy ⭐ 3,193 · TypeScript

GitHub: https://github.com/makecindy/cindy

In one line: An open-source agent client that puts Claude Code, Codex and other harnesses into one companion across desktop, mobile and chat.

What it is: The repository holds only the client: an Electron desktop app, an Expo / React Native mobile app and shared packages; the backend lives in a private repository. The first harnesses are Claude Code and Codex, and models and harnesses mix freely, with a mid-task switch that keeps the workspace, memory, skills and tools intact; one task can be planned, executed in parallel and reviewed by different harness and model combinations. The repository dates to 2026-07, with 142 contributors, 68 releases and version numbers still in 0.1.x.

What stands out:

Memory sits above the harness. Switching harness, switching models or compressing context does not lose it, and since v0.1.111 changing the primary computer migrates conversations, attachments, to-dos and routines.
Steps only the owner can do go back to the owner. Logins, passwords and verification codes become a card on the owner's device, and the task continues after it is filled in; the project says card contents stay on the device and are excluded from model input, records and push notifications. I did not verify that data path.
Chat bots can be your own. Telegram, Feishu, WeCom, DingTalk and Discord, with one companion on several platforms; direct messages enter the main task while group chats and stranger DMs get separate sessions, and external members are limited to guest permissions with no command execution.
A program-level heartbeat. It finds tasks that are stuck, waiting for confirmation, failing or hitting a quota, and the workbench splits into "waiting on you" and "in progress."
1,755 open issues against 3,193 stars is a high ratio, which could be open triage or could be noise; with a closed backend, check the maintenance rhythm before adopting.

Compared with: Cindy’s documented combination is local execution, swappable harnesses and continuous memory across entry points. I would compare those behaviours directly with a single-harness client or a hosted service, including what still depends on its closed backend.

Recent updates: v0.1.111-beta (2026-10-19) makes the companion follow the account, adds bring-your-own chat bots, the program-level heartbeat and MCP Apps interactive cards; v0.1.110 (10-16) adds on-device voiceprints and one primary computer per companion; v0.1.109 (10-15) turns logins and verification codes into device cards.

Who it's for: People already using Claude Code or Codex who want the same persona to continue on mobile and in chat. Apache-2.0 covers the client only; server-backed capabilities require the official service or your own model keys.

My take: ⭐⭐. The interaction and permission design is worth borrowing; the product itself is still early.

Checked: read the README, the v0.1.109 to v0.1.111 release notes and recent commits. Not installed.

At a glance

Project	Category	Most distinctive	Who it's for	Worth a deep read
maka	Agent runtime	Append-only event log behind every surface	Teams auditing and replaying agent runs	⭐⭐⭐
zvec-grep	Workspace search	Ripgrep, BM25 and vectors in one fused interface	Mixed code and docs, slow agent search	⭐⭐⭐
sim	Agent workspace	Tables, files, knowledge and flows in one place	Many SaaS tools, data must stay home	⭐⭐
qwen-code	Coding agent	Daemon plus SDKs turn the agent into a service	Embedding coding into your own product	⭐⭐⭐
cindy	Agent client	Swappable harnesses with continuous memory	Individuals already on Claude Code or Codex	⭐⭐

This week's notes

Task-level evidence makes a runtime easier to assess. Maka ships per-task A/B results, a paired test and cost per pass in the repository, which is more convincing than another post claiming a benchmark lead. When evaluating an agent framework, ask whether it will publish per-task results.
Retrieval is becoming agent infrastructure. zg benchmarks tool calls and input tokens rather than a few points of recall. Retrieval quality, output size and latency need to be measured together. A smaller result is useful only if it still contains the evidence the task needs.
Coding agents are splitting into two shapes. qwen-code goes daemon, SDK and four chat channels, becoming a service other systems call; cindy goes multi-harness across desktop, mobile and chat, becoming a person's permanent entry point. They expose different entry points for the same underlying coding work.
Security fixes in a same-day release say more about a project's stage than new features do. Most of Sim v0.9.26 is OAuth revocation, SCIM changes, log write permissions and egress restrictions, which are concrete boundaries to include in a deployment review. The number of security fixes alone cannot establish production readiness.

Open Source Radar · 2026-10-18: The Agent Operations Layer, Not the Model

十方空烬 · Ember ☄️ — Sun, 18 Oct 2026 06:56:13 +0000

Open Source Radar · 2026-10-18 · By Renchao Wu

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-18. Feature descriptions below reflect the linked project documentation; I have not independently tested their security or performance claims.

None of today's five projects is a model. Each one handles a different part of running an agent: remembering, running long, managing skills, holding permissions, and staying visible.

1. akitaonrails/ai-memory ⭐ 9,999 · Rust

GitHub: https://github.com/akitaonrails/ai-memory

In one line: Long-term memory for coding agents, stored as a git-backed markdown wiki shared by more than twenty agent runtimes.

What it is: Close one agent mid-task, open another in the same directory, and the new one has no idea what you tried or which approach failed. This single Rust binary fills that gap: lifecycle hooks capture sessions silently, session end compiles them into wiki pages, the next session gets a bounded brief, and unfinished work is handed over as a typed record. The repo was created in May 2026 and reached 9,999 stars, 725 forks and 150 contributors in five months. The release count is truncated at GitHub's 100-per-page limit; the last three days alone shipped v3.0.1, v3.1.0 and v3.1.1.

What stands out:

Markdown is the source of truth; the index is disposable. Pages are plain .md: grep them, open them in Obsidian, edit by hand, rsync them. SQLite is a derived index that can always be rebuilt, and there is no vector store to maintain. The useful property is that the source pages remain inspectable even if an index must be rebuilt; plain text alone does not prevent corruption.
A handoff can be claimed exactly once. Handoffs are not free text but typed records with an owner, invalidated after one claim. That mechanism is intended to prevent two workers from claiming the same handoff; it does not guarantee that all downstream work is performed exactly once. Most memory tools have no such concurrency primitive.
The default path makes zero LLM calls, including aging. Capture, search, injection and handoff need no API key. Per-tier decay curves, access-weighted retention (opening, searching or linking to a page counts as use), compression of cold notes into durable facts, near-duplicate merging and contradiction flagging are all deterministic. Rewrite-and-drop operations are off by default, nothing is hard-deleted, and restore-page brings old versions back.
The recall numbers are self-measured and labelled as not comparable. On LongMemEval-S (470 questions), hit@5 was 0.666 zero-LLM and 0.815 with local embeddings on the 2.6 line; with the 3.0 observation stream on, it rose to 0.951 zero-LLM and 0.945 with local embeddings. The README also states that Mem0 and Zep publish end-to-end QA accuracy, which is a different measurement.
Team features are not a paid tier. Multi-user auth, per-person attribution and an audit log are built in. The project reports a measured write ceiling of roughly 700 operations per second; I did not reproduce it.

Compared with: Mem0 and LangMem extract atomic facts per turn and leave opaque fact rows behind; Zep and Graphiti offer typed edges over time but require a graph database and an LLM in the loop; basic-memory also treats markdown as truth but has no automatic capture, cross-agent handoff or multi-user sharing. The split is not the retrieval algorithm. It is who owns the artifact and whether a human can edit it.

Recent updates: v3.1.1 (2026-10-17) stopped lint findings from counting expired pages and aligned curator TTL behaviour with the docs; v3.1.0 (10-16) and v3.0.1 (10-15) were consecutive patches on the 3.x line. The latest commit merged PR #1390 at 19:50 UTC on 10-17.

Who it's for: People running two or three coding agents at once, or resuming the same work on another machine. Two caveats: support for some runtimes is MCP-only, with no hook capture, so they can read but not record automatically; native Windows remains experimental, and WSL2 is the safer path.

My take: ⭐⭐⭐. Unusually restrained for a memory tool: no API spend by default, rewrites gated behind an eval before they can become default, and deleted pages recoverable. The two mechanisms worth copying are claim-once handoffs and access-weighted retention.

Checked: read the README, release list, recent commits and its own benchmark documents; did not install it.

2. AMAP-ML/LongHorizon-Harness ⭐ 1,750 · Python

GitHub: https://github.com/AMAP-ML/LongHorizon-Harness

In one line: An execution loop wrapped around an existing coding agent that splits long work into bounded rounds, each run in a fresh context and independently verified before it counts.

What it is: A long-horizon shell for CLI agents such as Claude Code, Codex and OpenCode. Give it a goal once, and it repeats four steps: cut the next bounded step, perform it on a desktop app or in the terminal, check the real artifact (files, UI, logs, tests), and record only what passed as progress. After a context refresh, a failed action or a rejected deliverable, the next round restarts from the original goal plus the last verified checkpoint. The academic side is hot, with arXiv 2608.01964 and a number-one spot on the Hugging Face Daily Papers weekly ranking on 2026-08-06. The engineering side has cooled: all eight releases landed between 14 and 20 August, with no new commits through 18 October.

What stands out:

Three roles are boundaries, not three agents growing their own copies of the task. The Manager rebuilds state each round from the original goal, verified progress and failure evidence. The Executor gets a fresh context and does one step. The Auditor independently inspects real files and interfaces instead of trusting the Executor's claim. Anything that fails verification is demoted to evidence and not counted as progress. That rule makes an unsupported completion claim easier to catch.
Fresh context is a design choice, not a side effect. The Executor carries no conversation history from the previous round, only the rebuilt state. Long tasks usually die of context rot; this design reopens the context and lets state files carry memory.
Same backbone, same model, different harness, large gap. The paper reports a comparison using Qwen 3.7-Plus as the backbone and Claude Code as the execution backend: WeaveBench (114 tasks) pass rate went from 51.8 to 80.7; OSWorld 2.0 (108 tasks) binary completion went from 2.8 to 8.3, a threefold gain; Terminal-Bench 2.1 success went from 69.7 to 77.2 while using 24% fewer tokens.
Each role can use a different model and permission scope. Manager, Executor and Auditor can be assigned separate backends and models, with read and write ranges narrowed per role. Separate role models and permissions provide explicit cost and access controls.
A finished run is not a dead end. v0.1.7 turned completed runs into continuable conversations, with messages sent mid-round claimed by the next round. A stop request escalates to a force stop only when a worker ignores it.

Compared with: OpenHands and similar platforms take over the agent along with the loop; this one keeps the model and CLI you already use and only owns the loop, so a broken layer can be swapped alone. Compared with the sub-agents built into Claude Code, verification is a separate role instead of self-review, and state lives on disk, so it survives across processes and days. Compared with AutoGPT-style self-loops, it adds a read-only Auditor and the hard rule that unverified work is not progress.

Recent updates: v0.1.7 (2026-08-20) lets a finished run continue as a conversation from its existing round ledger, adds --reasoning-effort per role, fails a round rather than the whole run when only a guard fails (#28), and recovers from an isolated EBADF in control-bus reads (#33). v0.1.6 (08-17) added OpenCode and one more CLI backend adapter.

Who it's for: Anyone who needs an agent to work for hours and still be able to say exactly how far it got. Two caveats: the repo has had no commits for two months, so long-term maintenance is a risk, and the README states it has only been tested on macOS, with Windows support included but not thoroughly tested.

My take: ⭐⭐⭐. It turns "long tasks" from a prompt problem into a state-machine problem, and backs it with a same-backend comparison. Even without installing it, the division of responsibilities across the three roles is worth copying.

Checked: read the README, all eight release notes, recent commits and the paper link; did not install it.

3. MadsLorentzen/ai-job-search ⭐ 50,666 · Python

GitHub: https://github.com/MadsLorentzen/ai-job-search

In one line: A skill library that turns a coding agent into a job-application pipeline: scrape postings, score fit on five dimensions, tailor the CV and cover letter, then have a second agent criticise the drafts.

What it is: An end-to-end workflow you fork, fill with a profile and run. It ships 12 slash commands (/setup, /scrape, /rank, /apply, /interview, /outcome and others) plus six job-portal skill directories. The author is a geophysicist by training who lost his position in late 2025 and used this workflow for his own search: 69 tailored applications, 20 first interviews, one signed contract, and a start as an AI engineer in June 2026. The repo is only 4,679 KB, with 10 releases and 78 contributors. The weight is in the process and text contracts, not in code volume.

What stands out:

Each skill is a self-contained directory with a hard contract. SKILL.md carries an enabled: flag, a search / detail CLI and --format json|table|plain output, plus its own tests. /scrape auto-discovers any skill that follows the contract, with no registry; /add-portal generates new ones.
CI lints the skills themselves. A lint_skills.py script checks consistency across skills, commands and settings.json. Skills are artifacts managed like code, not scattered prompts.
The drafter and the reviewer have separate contexts. After the drafting agent finishes, a reviewer with a fresh context researches the company and critiques the drafts. Drafts arrive inline rather than being re-read from files, and every claim must map back to the profile, so skills and experience cannot be invented.
Job postings are treated as untrusted input. The workflow does not follow instructions embedded in a posting and does not fetch links from its body, and it says plainly that this is instruction-level defence rather than a sandbox. A security statement written this way is more useful than one claiming hardening.
The fork privacy trap is placed where it cannot be missed. A fork of a public repo is always public, while setup writes your name, contact details and salary expectations into tracked files. For personal use, the advice is a private repo with the original as upstream.

Compared with: Resume SaaS products such as Rezi and Teal handle layout and keywords, not search, fit scoring or feedback after applying. Prompt collections offer phrasing with no executable entry point and no tests. This sits in between: capabilities with CLI boundaries, enabled flags and CI, producing local LaTeX files. The cost is a hard dependency on a toolchain with no free tier.

Recent updates: v1.7.2 (2026-09-29) was about making documented checks actually run: compiled PDFs are measured rather than eyeballed, portal CLIs stop trusting digits in a URL, and Python tools handle non-ASCII input. An earlier v1.7.0 fixed a real privacy leak, where gh repo fork --clone set the upstream repo as default and automation then filed issues upstream.

Who it's for: People job hunting who will maintain their own profile, and anyone writing skill libraries for an agent, since the directory structure and review protocol transfer directly. Note the paid Claude Code subscription and the LaTeX toolchain, and that the portal skills target the Danish market.

My take: ⭐⭐. As a job tool it is niche; as a sample of how to organise a skill library it is valuable. Contract, switch, tests and lint, all four present.

Checked: read the README, release notes and recent commits, and counted the command and skill directories; did not install it.

4. NVIDIA/NemoClaw ⭐ 22,764 · TypeScript

GitHub: https://github.com/NVIDIA/NemoClaw

In one line: A vendor reference stack for running off-the-shelf agent runtimes inside sandboxes, covering inference routing, network egress, credentials and state lifecycle.

What it is: NVIDIA's answer to "how do I run someone else's agent safely". It does not implement an agent. It supports three runtimes (OpenClaw by default), installs them with configuration, tools and credentials into OpenShell sandboxes, and wraps the result in a versioned blueprint. A host CLI handles install, readiness checks, onboarding and daily operations; the gateway handles sandbox lifecycle, credentials, network policy, inference routing and approved egress. The repo is about 476 MB with 185 contributors, 797 open issues and pull-request numbers already past #13377. But it has been an early preview since 2026-03-16, the documentation is only at v0.0.135, and the single GitHub release is a CI toolchain snapshot from 1 October, not a product version.

What stands out:

Four protection layers, with an explicit split between hot-reloadable and locked. Network blocks unauthorised egress and reloads at runtime; inference reroutes model calls to controlled backends and also reloads; filesystem makes system paths read-only, opens only /sandbox and /tmp, and is locked at sandbox creation; process blocks privilege escalation and dangerous syscalls, also locked. Which layer can change and which requires a rebuild matters more than the protection itself.
An unauthorised request becomes a human approval. When an agent reaches an unapproved host, the gateway blocks it and surfaces the request in the terminal interface for an operator to approve. Approved endpoints persist only within the current sandbox instance and are not written back to the baseline policy file, so a temporary exception does not become a permanent backdoor.
Credentials are scoped handles, not raw keys. Configuration stores references. Switching an inference provider stores a handle, and a rebuild refreshes it only when the endpoint and credential key match the current binding; user-managed credentials are left alone.
Failures must be explained by the agent. The runtime context tells agents to try allowed network and filesystem actions first, then report whether policy denial, DNS, timeout, TLS or file access caused the failure. That distinction is what makes debugging and auditing possible.
An install path written for an agent to read. A starter prompt lets a local coding agent walk a human through setup: one question at a time, commands only with approval, secrets kept out of the chat.

Compared with: Code-execution sandboxes such as E2B and Daytona sandbox "running a piece of code"; this sandboxes a whole agent runtime, with inference, MCP credentials, egress and state inside the boundary. Compared with wrapping an agent in Docker yourself, the difference is not the container but the policy lifecycle: a baseline policy, in-instance temporary approvals, and the line between hot reload and locked configuration. Most DIY setups have none of that. The cost is binding to NVIDIA's OpenShell and to DGX or WSL hosts.

Recent updates: v0.0.135 (2026-10-15) strengthened credential handling, sandbox recovery and failure diagnostics; managed tool gateways moved to a dedicated provider profile with an opaque broker token, verified before creation or reuse (#13102); inference rejects non-canonical URLs that resolve to NVIDIA's own endpoint (#12925); new sandboxes default to progressive tool disclosure (#13173).

Who it's for: Teams that deploy third-party agents at scale and must explain the boundary to security or compliance. It is still alpha, and the README says maintainers respond on a best-effort basis with no promised timelines. The hardware requirements are also high.

My take: ⭐⭐. It is not something most people should install, but the four-layer split and the rule that temporary approvals stay out of the baseline make a good self-check list for any agent system.

Checked: read the README, NVIDIA's architecture and release-notes pages and recent commits; did not install it.

5. penso/herdr-gpui ⭐ 1,476 · Rust

GitHub: https://github.com/penso/herdr-gpui

In one line: A third-party native desktop client for an agent runtime, putting workspaces, worktrees, per-agent status and terminals on one screen.

What it is: Herdr is a runtime that keeps coding agents alive (herdrdev/herdr, 44,531 stars, Apache-2.0), with agents running in a daemon that survives closing a window. This repo is a third-party GUI for it, and the author states plainly that it is unaffiliated with the official project. The client does not install or start the daemon; it only views and operates. It was created on 2026-09-20, shipped 41 releases in a month (10-13, 10-14 and 10-16 back to back) and has 53 contributors.

What stands out:

It does not emulate a terminal; it paints cells. It connects to the daemon's client socket, receives the terminal grid and draws it, split panes included. Solid box-drawing characters, block elements and four powerline separators are drawn on the cell grid with edges aligned to device pixels, so a full-cell border is not clipped by line spacing. Painting instead of embedding means the same session can be rendered by several front ends at once.
One task, one worktree, as the default posture. The sidebar lists worktrees per repository, with right-click actions to create, rename, fan out or close, and a one-click removal after the pull request merges.
Teleport moves a worktree to another machine. The project describes moving commits, uncommitted changes, tabs, splits, running programs and agent sessions together. I did not test whether a running process continues or is reconstructed on the destination. tmux alone does not provide that worktree-transfer workflow.
Review notes go straight back into the session. Open a diff, leave line comments, send them to the agent; in a browser tab you can select an element, annotate it and send it back. The human-looks-at-result loop is built into the interface.
Status is a first-class object. Each agent carries a status dot: idle, working, waiting for you. Needing a human triggers system notifications, sounds and a Dock badge, and the status bar shows remaining plan quota for the AI services in use.
Performance has a reproducible contract. A synthetic fixture with 160x50 cells, 40 workspaces and 40 agents drives real mouse events through the framework's event dispatch, with a configurable p95 budget (250 ms by default in release builds, calibrated to 30 ms on the author's machine).

Compared with: tmux and zellij manage terminal sessions and do not know which pane holds which agent or who it is waiting for; terminals embedded in editors run commands but leave worktrees and status for you to track. The sibling herdr-web-ui (1,153 stars) wins on remote reach through browser and phone, while this client wins on native rendering and desktop interaction. The real distance comes from the combination: native rendering, worktrees as first-class objects, and cross-machine teleport.

Recent updates: v20261016.1 (2026-10-16) added network latency and loss to the status bar and made sidebar devices draggable; v20261014.1 (10-15) let a tab torn out of a window become a new window, moved panes to another device, and rendered markdown in browser tabs; v20261013.1 (10-13) removed worktrees after merge, teleported worktrees between cloud devices and added a CLI to control the running app.

Who it's for: People running a dozen agent sessions, mostly on macOS. It requires an existing Herdr daemon; the Linux packages and Windows build are marked experimental, and macOS needs 14.2 or newer.

My take: ⭐⭐. Without the daemon it is not installable for most people, but one-task-one-worktree, status dots and review-to-session are the three ideas worth taking, more than the rendering tricks.

Checked: read the README, the in-repo performance report, all 41 release notes and recent commits; did not install it.

At a glance

Project	What it is	Most distinctive	Who it's for	Worth a deep look
ai-memory	Long-term memory for coding agents	Markdown as truth, claim-once handoffs	People running several agents or switching machines	⭐⭐⭐
LongHorizon-Harness	Long-horizon execution loop	An independent Auditor, unverified work is not progress	People whose agents must work for hours	⭐⭐⭐
ai-job-search	Job-search skill library	Skills with CLI contracts, tests and CI lint	Skill-library authors, job seekers	⭐⭐
NemoClaw	Agent sandbox reference stack	Four layers, hot-reload vs locked	Teams that must document an agent boundary	⭐⭐
herdr-gpui	Agent session desktop client	Worktrees as objects, cross-machine teleport	Multi-session users on macOS	⭐⭐

This week's notes

Today's five selections focus on the agent operations layer. Not one of the five is a model: memory, loop, skills, sandbox, session interface. Together they cover an agent from remembering to staying visible. These are useful comparison points even when two products use the same model.
The memory argument has shifted to who owns the file. Whether a human can grep it, edit it, and recover it after deletion matters more for long-term use than a retrieval score. The project's reported 0.951 hit@5 is evidence for its own retrieval setup, rather than proof that every memory workflow can dispense with model calls.
The ceiling on long tasks is who verifies. Same backend, same model, only the loop changed, and the pass rate moved from 51.8 to 80.7. That reported comparison gives a reason to test independent verification while keeping the model fixed.
Skill libraries are acquiring engineering constraints. A switch, a CLI contract, tests and CI: once those four are present, a skill becomes a module. Without them, any number of skills is still a pile of prompts.

Open Source Radar · 2026-10-17: Vendors start shipping agent skills

十方空烬 · Ember ☄️ — Sun, 18 Oct 2026 06:55:22 +0000

Open Source Radar · 2026-10-17 · By Renchao Wu

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-17. Feature descriptions below reflect the linked project documentation; I have not independently tested their security or performance claims.

1. android/skills ⭐ 8,132 · Kotlin

GitHub: https://github.com/android/skills

In one line: Google's official library of 30 skill files covering the places where models fumble Android engineering work, ready to drop into a coding agent.

What it is: A versioned, dated skill artifact. The body is Markdown, spread across 18 domains — build, performance, camera, Play publishing, Wear, TV, automotive, testing and more. The Kotlin label comes from the build scripts, not from the skills themselves. The repo was created on 2026-03-16 and had shipped 27 releases by 10-14, with the last commit on 10-16, eight contributors and 37 open issues.

What stands out:

Topics are chosen by evaluation, not by author interest. The README says it focuses on use cases and workflows where evaluations show LLMs underperform, and explicitly deprioritizes what models already do well (the example given is basic Jetpack Compose best practices). That is the bar for entry: every skill has to say where the model went wrong and what changes if you follow it.
The skills carry version detection. Take r8-analyzer: the body first checks the AGP and R8 versions — AGP ≥ 9.3.0 goes through a Gradle task, R8 ≥ 9.3.7-dev goes quantitative, everything else falls back to heuristics. Commands that must actually run are marked MUST, with scripts and references alongside. This is the branch structure of an executable program, not a prompt.
One copy of the content, three kinds of agent. Claude Code, Codex and Gemini each get their own distribution descriptor, while the content is maintained once instead of rewritten per vendor.
Official identity, closed to outside contributions. The README states that public contributions are not accepted at this time and only issues are taken. Authority comes from Google's backing rather than the crowd; the cost is that coverage can only follow the official toolchain.

Compared with: The two direct comparisons are Anthropic's anthropics/skills and the community-collected awesome-claude-skills. The first teaches how to write skills — methodology and general samples; the second is large and uneven in quality. Two distinctions here: vertical depth, with specific failure points (redundant R8 keep rules, edge-to-edge adaptation, Media3 Cast integration, Leanback migration to Compose TV) each written up as a procedure; and selection discipline, where evaluation results rather than popularity decide what gets written.

Recent updates: v1.0.15 (2026-10-14) bulk-updated skill content and bumped the plugin version; v1.0.14 (10-12) changed plugin configuration. Lately a release every two days suggests the distribution layer is still being trialed. Release bodies are a single version line; the substance is in the commits.

Who it's for: Teams writing Android, and anyone doing Android work with a coding agent. The domain is Android only — other stacks get nothing here. Not accepting outside contributions means an uncovered failure point can only become an issue while you wait. Skills are written against toolchain versions, so a major upgrade means checking them again.

My take: ⭐⭐⭐. The content only helps Android, but "let evaluations decide which skill to write" transfers to any skill library.

Checked: read the README, release list and recent commits; did not install.

2. melgarafael/DeskcommCRM ⭐ 4,646 · TypeScript

GitHub: https://github.com/melgarafael/DeskcommCRM

In one line: A self-hosted AI sales and support system that puts a WhatsApp inbox, a CRM pipeline and an AI agent with RAG and memory into one application.

What it is: A business system that turns "how an AI agent gets managed" into product features. Next.js 16 plus Supabase (Postgres, Auth, Storage, Realtime, pgvector), with two WhatsApp channels: a QR-scan gateway or Meta's official Cloud API. Created 2026-04-28, with 161 contributors and 109 releases — a new version every other day; 315 open issues, and recent commits are almost all merged PRs, so the outside contribution flow is steady. The README says it runs in clinics, real-estate agencies, paid-knowledge businesses and retail stores.

What stands out:

Governance lives in the feature layer. Per-tenant RAG, the AI as a "first-class assignee" (it can be dispatched work, handed off and counted), an audit trail when the AI hands a conversation to a human, a per-organization spend cap, and a built-in MCP server. Those four answer who catches it when the AI errs, how much it costs, and whether data leaks across tenants.
Self-improvement comes with a human gate. Resolved conversations become new knowledge; the agent proposes improvements to itself; applying one makes a new version, but a human must approve it. The backend also shows whether the agent is getting better or worse, and where it goes wrong.
Multi-tenancy is a hard constraint. Every tenant-aware table has RLS, and isolation tests act as a CI gate. The project documents an append-only audit log with five-year retention and anonymization where possible. I did not assess its legal compliance.
It acknowledges the risk controls. The QR channel has throttling, jitter and time windows, and the interface translates "why am I rate-limited" into plain language. The official channel goes through Meta Cloud API with approved templates.
The cost model is honest. Self-hosted, no monthly fee, no locked features; revenue comes from VPS affiliate links and installation services, not licenses. That is why it does not have to cripple features to sell a tier.

Compared with: The open-source comparison that matters is Chatwoot — also self-hosted, also WhatsApp, also a multi-channel inbox. Chatwoot's core is an inbox for humans plus automation rules, with AI attached through bots and webhooks. Here the agent is the seat itself, with RAG, skills, memory, spend caps and handoff auditing: the system still works without AI, and with AI present the AI is a first-class citizen. The other split is MCP, which opens CRM capabilities to the outside agent ecosystem instead of locking them into a proprietary plugin marketplace. Its own benchmarks, Kommo, Octadesk and Intercom, are commercial SaaS and not open-source comparisons.

Recent updates: v1.84.0 (10-16) covered billing and plans: once billing is enabled you must name a default signup plan, or the Google sign-in entry disappears, signups without a plan are rejected, and the tenant provisioning endpoint returns 409. A plan with a zero-day free trial sends new businesses straight into a suspended state. v1.83.0 (10-16) merged inbox multi-select and bulk operations into a single route, after users complained about toggling things on and off. The repo also carries a spec document for an external agent governance contract, so the open interface is written down rather than merely promised.

Who it's for: Small and mid-size teams that want to self-host sales and support on WhatsApp and have someone to maintain a VPS and Supabase. The QR channel is an unofficial gateway, so account risk is yours. The interface is in Portuguese, and the compliance boxes are cut for LGPD — another region means redoing them. What is really worth taking is the acceptance checklist for those four layers of governance, not the business code.

My take: ⭐⭐⭐. Anyone can wire up RAG; not many make handoff auditing, spend caps and tenant isolation default behavior.

Checked: read the README, release notes and recent commits; did not deploy.

3. storytold/artcraft ⭐ 30,757 · Rust

GitHub: https://github.com/storytold/artcraft

In one line: An AI image IDE for artists, designers and film people: block out the scene, camera and pose in 2D/3D first, then pick a model to render stills or video.

What it is: A desktop application built around "build the shot before generating", which calls itself The IDE for artists — canvas and scene on the left, model picker on the right. Windows and macOS have official builds; on Linux you compile it yourself. Created 2022-03-31, with 28 releases and 436 open issues, but only three contributors: a very small core team making a lot of noise. The repo is 1.31 GB, most of it sample media. Recent commits cluster on 10-10 to 10-11, rewriting the desktop client in pure Rust.

What stands out:

Blocking the shot before generating is the line between it and prompt tools. Image to Location places characters into reusable environments with multiple cameras in the same room; 3D Image Compositing layers background, foreground and props by depth; Character Posing sets the pose before the camera; Kitbashing assembles 3D assets to get occlusion right.
Character consistency is a first-class requirement. Character Identity Transfer uses a posed mannequin to drive a character's position and posture. The hardest part of serial content is the same person staying the same person across frames; here it is a feature, not a prompt trick.
Models change, workflow does not. 62 models in five classes: 16 image, 25 video, 5 music, 11 3D mesh, and 5 world and Gaussian splatting, covering FLUX, Seedream, Kling, Veo, Sora, Suno, Hunyuan 3D and other major families. Re-render the same scene with another model, and composition is decoupled from the model — that is the confidence behind calling itself an IDE.
The license is moving wider. On 10-10 it went from a single license to MIT or Apache-2.0, and the same day shipped artcraft-native, a pure-Rust (egui) desktop client. Loosening a license usually means wanting to be embedded and redistributed.

Compared with: ComfyUI centres on a node graph; ArtCraft puts a saved 3D scene, camera and pose in the foreground. That is the workflow distinction I am interested in, rather than a claim that a ComfyUI extension cannot support scenes. Here camera, occlusion and pose are savable scene objects, and changing the camera is changing a parameter. Krea and Runway go the other way: cloud-integrated but tied to their own models. The split in one line: ComfyUI orchestrates a compute graph, ArtCraft orchestrates a photo studio.

Recent updates: 10-11 made the generation backend selectable per provider (Midjourney or fal); 10-10 added audio, in-app playback, animation preview and character references, and shipped the pure-Rust desktop client, starting with image and video. The official v0.41.0 (09-26) release body is only download instructions; the substance is in the commits.

Who it's for: People producing serial visuals where the same character and scene recur across images. Three obstacles: it is a desktop app, so Linux needs a build; most models are paid APIs and the aggregation layer runs through its own service; a three-person core team means the roadmap can turn at any time. Go in knowing you want reproducible composition.

My take: ⭐⭐⭐. Model aggregation stopped being a differentiator long ago; locking down camera and composition is. It turns that into reusable scene files.

Checked: read the README, release notes and recent commits; did not install.

4. fuxicodex/Fuxi ⭐ 3,340 · Python

GitHub: https://github.com/fuxicodex/Fuxi

In one line: A terminal AI coding agent whose pitch is cost-aware routing across providers and automatic failover.

What it is: Boundaries first: the source is closed, and the repo holds only documentation, an installer and scripts — which is why GitHub labels it Python while the product is a single static Go binary. The LICENSE says Proprietary. Three contributors, four releases, zero open issues, a 7,959 KB repo: the shape of a product launch rather than a community effort. It claims that roughly two million lines of code were all written in-house, which cannot be verified from this repo. The form factor follows Claude Code and Codex CLI: zero runtime dependencies, mandatory account login, and you can bring your own key.

What stands out:

Routing sits in the kernel. Choosing among providers by cost, switching automatically on failure, and pooling multiple keys all live in the product rather than in wrapper scripts. Three commits in October worked this area: multiple keys per provider, key selection by fallback model, and configurable routing and fallback strength.
Overages are made visible. The documentation describes an explicit notice when quota exhaustion rolls into extra usage.
Permissions are explicit tiers. default, plan and bypassPermissions; even the widest tier still blocks extreme commands like rm -rf /, and root and sudo are refused outright on Linux and macOS.
The privacy statement is specific. No code or session collection by default; with your own key, requests go straight to the provider; conversations upload only when the switch is explicitly turned on; credentials stay local.

Compared with: Claude Code, Codex CLI, OpenCode and Aider. Two splits: routing, where most terminal agents let you pick one model and run it to the end while this puts cost-based selection, failover and key pools in the kernel — real money for high-frequency long tasks; and distribution, a single binary with no runtime. Aider and OpenCode make their source available for changes. Fuxi does not expose its implementation in this repository, which limits this comparison to its documented behaviour. So its distinctiveness is at the product level, not something to borrow at the engineering level.

Recent updates: v0.1.8 (09-22) unified the rate-limit banner, moved the plugin marketplace to an official GCS mirror, and optimized long-session scrolling; 09-29 migrated the marketplace to the .fuxi-plugin format. The version is still 0.1.x, and 1.0 has not arrived.

Who it's for: People running frequent long tasks who care about token cost and do not want to install a runtime. If closed source, mandatory accounts or needing to modify source bother you, stay away. To study its routing design you can only infer from docs and commit messages.

My take: ⭐⭐. The routing is worth learning from, but with no line of code visible, what you learn is design only.

Checked: read the README, release notes and recent commits; did not install (the source is closed).

5. hmjz100/LinkSwift ⭐ 23,870 · JavaScript

GitHub: https://github.com/hmjz100/LinkSwift

In one line: A userscript that pulls real direct download links out of nine cloud-drive web pages and pushes them to Aria2, IDM and similar downloaders in one click.

What it is: A single-file browser userscript that handles only the "get the link" layer, leaving the download to a proper downloader. With a script manager installed, cloud-drive pages grow a download assistant: copy the direct link, export a cURL or aria2 command, or push straight to a configured downloader. Created 2022-08-10, with 64 releases and 38 open issues, but only six contributors — effectively a single maintainer. Almost every release follows a front-end redesign of the drives; the changelog is full of "adapted to the new page" and "fixed the button disappearing after the redesign".

What stands out:

Nine drives, one UI. Baidu, Alibaba, China Mobile, Tianyi, Xunlei, Guangya, Quark, UC and 123 — different page structures, auth schemes and link signing, flattened into a single button. Every additional drive is another adaptation to maintain indefinitely.
Downloading can start right after the link. Built-in push to Aria2 RPC (with multiple server switching), IDM, ABDM and BitComet, plus command-line export to run on a server. That is the difference between it and scripts that only copy a link.
The compliance line is drawn hard. Two IMPORTANT paragraphs in the README: it calls only the public APIs of each drive, does not promise or implement any speed-limit bypass, and explicitly objects to being marketed as an accelerator. Most peers in this category pull stars with speed-limit cracking; this one gives up that selling point on purpose.
It tidies the page too. Removes promo slots, unifies the theme color, adds dark mode with Dark Reader support. Pure download scripts usually skip this, and the gap shows.

Compared with: It descends from an earlier Chinese cloud-drive direct-link assistant, and against that upstream it widened from a few drives to nine, from a single IDM target to four kinds of downloader, and added page cleanup plus four years of continuous adaptation. Motrix and similar tools are the downloader that takes over after the link — upstream and downstream, not competitors. The real split is stance: plenty of drive accelerators sell speed-limit cracking, while this one uses public APIs only and publicly disclaims any acceleration.

Recent updates: stable v1.1.3 (2026-02-18) added IDM client settings and adapted Baidu's share page; v1.1.4 beta (09-09) added Guangya, adapted the 123 redesign, introduced eslint, and fixed the Xunlei popup and a false ABDM push failure; 09-10 fixed a memory leak in theme-color switching. The beta has sat for over a month without promotion, and stable has not moved.

Who it's for: People who need to pull large cloud-drive files onto a NAS or server without installing a client. Two boundaries: the repository uses AGPL-3.0; and it survives by matching the front-end DOM, so a redesign silences it — treat it as a manual tool and never put it on a critical path in automation.

My take: ⭐⭐⭐. Dirty work with a clean stance — refusing the speed-limit-cracking business is worth more than supporting a few more drives.

Checked: read the README, changelog and release notes; did not install the script.

At a glance

Project	What it is	Most distinctive	Who it's for	Worth a deep look
android/skills	Vendor-official skill library	Evaluations decide which skills get written	Teams writing Android	⭐⭐⭐
DeskcommCRM	Self-hosted sales and support system	Handoff auditing, spend caps, tenant isolation	Small teams selling on WhatsApp	⭐⭐⭐
artcraft	AI image IDE	Block a 3D scene and camera before generating	Creators making serial visuals	⭐⭐⭐
Fuxi	Terminal coding agent (closed source)	Cost-based routing with automatic failover	People who watch token cost	⭐⭐
LinkSwift	Cloud-drive direct-link script	Nine drives behind one button	People pulling large files to a NAS	⭐⭐⭐

This week's notes

Skill libraries are getting version numbers, so check which toolchain version one targets before you pick it. Skills used to be scattered notes; now they have versions and maintenance dates. Content written against a toolchain version can become stale after an upgrade, and being able to ask "which version is this written for" matters more than the number of skills.
Star counts have shifted from an open-source signal to an exposure signal. To judge whether a repo is worth reading, contributor count, open issues, repo size and LICENSE are four more honest numbers than stars: a real project cannot hide its code volume or outside commits, and a docs-only repo cannot either. Check the LICENSE and the size first, then the stars.
For generative tools the competition has moved from "more models" to "controllability". Aggregating dozens of models is table stakes; fixing composition, camera and character is the difference, and whether a result is reproducible decides if the output is a work or a lucky draw.
Two projects today trade doing a little less for trust. The download script publicly denies that it accelerates anything, and the CRM makes AI spend caps and handoff auditing the default. Fewer features and clearly stated boundaries make it easier to put something into production.

My LoRA improved routing and made JSON less reliable

十方空烬 · Ember ☄️ — Thu, 15 Oct 2026 10:50:57 +0000

By Renchao Wu

My small routing model became much better at returning the expected fields after fine-tuning. It also became slightly worse at returning valid JSON.

On 576 held-out synthetic requests, strict all-field accuracy rose from 7.6% to 47.2%. JSON validity fell from 98.6% to 95.5%. The same adapter that improved the headline score introduced more responses a strict parser could not read.

I published the MLX adapter and reproduction package, the synthetic dataset, and a Kaggle notebook for checking the frozen outputs. The useful result is the tradeoff, together with the evidence needed to inspect it.

The task: turn a request into a small routing decision

The experiment uses Qwen2.5-0.5B-Instruct to handle English, Chinese, and mixed-language requests. The output contract covers notes, scheduling, calculations, requests needing clarification, and unsupported requests.

A response must satisfy several checks. It must parse as strict JSON, match the permitted schema, choose the correct route, and contain exactly the expected field values. Passing one check does not imply passing the next. A parser can accept an invented route; a schema validator can accept a correctly typed but wrong value.

The schema is present in the prompt for both the base model and the adapter. Neither arm gets credit for guessing a hidden interface.

This is a personal synthetic experiment. Its templates share vocabulary across splits, and their language variants were written by one author. It does not measure open-domain assistant quality or production routing reliability.

A family split was not enough

My first version split template families before expanding language variants. That avoided putting a direct translation of the same example in both training and test, but it left another problem: related families could still describe almost the same situation.

A complete scheduling request and its missing-time sibling belong together. Different family IDs do not make them independent scenarios.

For v2, I bound 77 families into 23 explicit scenario clusters, including paraphrases and complete/missing-information siblings. I split those clusters before expanding English, Chinese, and mixed variants. The resulting splits contain 1,026 training rows, 291 validation rows, and 576 test rows. The test covers 23 families in seven held-out clusters.

Those clusters are a documented judgment, not proof of semantic independence. I froze the manifest before the v2 run and kept v1 as a separate history. The v1 and v2 test scores are not comparable. The split changes and audit are recorded in the public review.

One consequence mattered a lot: the entire percent_of scenario landed in test. The training set never taught the model that operation. Calculation results therefore include an out-of-training probe, rather than an ordinary sample of familiar calculations.

The result depends on what gets counted

The frozen v2 test produced these rounded percentages:

Check	Base model	LoRA adapter
Strict JSON	98.6%	95.5%
Schema-valid	40.6%	95.0%
Correct route	35.6%	72.2%
Strict all-field match	7.6%	47.2%
Cross-language equal and correct	2.6%	43.1%

The base model usually produced parseable JSON, but often used fields or routes outside the contract. The adapter learned much more of the interface and selected the right route more often. That gain coexisted with a regression in parseability.

Strict all-field match requires schema-valid, type-checked output and exact expected values. The scorer rejects duplicate keys, nonfinite values, Markdown fences, and extra text. It also rejects Python's tempting shortcuts: true does not count as integer 1, and 3.0 does not satisfy an integer-only field.

The frozen scorer keeps operand order as part of the gold contract. A separate commutative_ok metric exists for diagnosis; it does not silently replace the headline score. In this v2 run, it did not rescue any swap-only failures.

Validation strict accuracy was almost flat: 25.4% for the base and 25.8% for the adapter. The large test gain was concentrated in notes and scheduling. Treating the 47.2% aggregate as a general improvement would hide that unevenness.

The failures changed the next experiment

The adapter's strict calculation score was zero. For held-out percentage requests, it produced familiar operations such as div or add. It had learned useful routing patterns without acquiring the missing operation through this training set.

Clarification and rejection were also weak. Their route accuracies were about 24% and 47%. An underspecified request was still often treated as an action to execute. In a real system, that behavior would matter even if an aggregate score looked encouraging.

I initially described all 26 invalid adapter outputs as coming from the unseen operation. A later question prompted a recount of the original frozen predictions. That explanation was too broad. The corrected breakdown is:

Gold task	Invalid JSON outputs
Calculation using `percent_of`	13
Percentage request missing a number; clarification required	10
Underspecified note request; clarification required	3

The final group included repeated keys or truncation. No other test families produced invalid JSON. The language counts were eight English, nine Chinese, and nine mixed.

That correction matters to diagnosis. Adding training examples for an unseen operation would not, by itself, explain the underspecified-note failures. I would test missing-information handling separately and examine the repeated-key outputs before deciding what to change.

The corrected repository-root review is the source for this breakdown. The existing experiment.zip and Kaggle frozen package still contain the earlier review text. Their outputs, weights, and aggregate scores have not changed. This was a recount, not another training run.

What actually ran

Training ran locally on Apple silicon with MLX. The published adapter is in MLX-LM format; it is neither a standalone model nor a PEFT adapter.

The base is Qwen/Qwen2.5-0.5B-Instruct, fixed at revision 7ae557604adf67be50417f59c2c2f167def9a775. The run used LoRA rank 8, scale 20, 16 layers, learning rate 1e-4, batch size 1, and 1,500 iterations. The seed was 42. I used the final checkpoint as declared, rather than selecting it against the test results.

Evaluation loaded the saved adapter in fresh processes. Both arms used greedy decoding with the same prompt and a 96-token output limit. A second training run with the same seed produced a bit-identical adapter; evaluation was not repeated. That checks repeatability under this setup, not robustness across seeds or environments.

There are only seven test clusters. The published family-bootstrap intervals for strict accuracy are wide: roughly 1–16% for the base and 28–67% for the adapter. The 576 rows include language triples and related examples; they are not 576 independent real-world situations.

Two different ways to reproduce it

If you want to inspect scoring without running a model, use the Kaggle frozen-output notebook. It loads saved predictions, checks the frozen artifacts, and recalculates scores on CPU. Its successful cloud run is evidence for that scoring path. It does not establish cloud training or inference performance.

To rerun training on compatible Apple silicon, follow the model repository instructions. After downloading the repository and extracting its experiment.zip at the repository root:

unzip experiment.zip
cd reproduction
bash scripts/run_all.sh

The script installs pinned dependencies, downloads the fixed base revision, regenerates data, checks the scorer, trains, reloads the adapter, and evaluates both arms. New run outputs remain separate from the published frozen outputs. Runtime and memory will depend on the machine.

Code, data, and adapter are published under Apache-2.0 with license and notice files. The base weights are not redistributed. Read the corrected root review alongside the historical package before interpreting failure attribution.

What I would change next

I would keep this test frozen and build a separate experiment around the weaknesses it exposed: missing-information requests, unsupported requests, and operations absent from training. I would also compare ordinary decoding with a constrained-output path on the same requests, reporting format compliance and field correctness separately.

Those experiments have not run. They would answer different questions from this release.

For this run, the adapter was better at the declared routing contract overall, still failed every strict held-out calculation, and made valid JSON less dependable. I would want all three facts in front of me before deciding whether to put it behind an API.

Brief Ledger: check the extra ask before writing the extra copy

十方空烬 · Ember ☄️ — Wed, 14 Oct 2026 07:56:43 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

A copywriting brief includes three welcome emails. The next request asks for five onboarding emails. The wording has changed, and so has the amount of work.

I built Brief Ledger to make that comparison easier. It runs locally and puts a new request beside the nearest agreed deliverable, with the original wording still visible. In this example, it matches the onboarding request to the welcome sequence and shows that the requested total is two emails above the agreed total. The writer then chooses a decision and adds a review note.

The intended customer is an independent English-language copywriter handling fixed briefs and repeated revision requests. I would test a one-time local installation and workflow setup service around the tool. That is my business hypothesis. I have no paying customer, no measured time saving and no external user test yet. The current app is free and has no payment flow.

I started this new project and repository on October 13, inside the second week's entry period. I reused an installed Python environment and cached model weights. The application, fictional brief and diagnostic cases are new for this week.

Demo

Watch the 35-second walkthrough using GitHub's Download raw file button. It shows real captured browser states, assembled into a video rather than a continuous recording.

The flow is deliberately small: enter agreed deliverables, enter new requests, compare, then review the evidence. Quantities are separate manual fields. A requested total of five against three agreed means two more. The tool does not read numbers out of prose or add separate requests together.

The example also asks for a warmer landing page and a video edit. The landing-page request finds related source text but still needs a person to check revision conditions. The video request has no clear match. Neither result approves work automatically.

I can leave a row unresolved, ask for clarification, keep it in the agreed scope or quote it separately. Prepare review notes produces a complete copyable text with those decisions and the original evidence. The actual example output includes unresolved rows. An optional Markdown download is present; download completion was not verified in my development browser, so I tested and retained the visible copyable output.

The README explains local installation. There is no hosted inference service. I checked the interface at a 375px viewport, with no horizontal overflow.

Code

MIT-licensed source, tests and results

The examples are fictional original material. The repository contains no client files, model weights, credentials or input history.

How I Built It

I used all-MiniLM-L6-v2, an Apache-2.0 open-weight embedding model, through Sentence Transformers on CPU. Its revision is pinned. Normalized 384-dimensional vectors rank each request against the agreed descriptions.

A score below 0.40 produces “No clear match.” A top-two gap below 0.08 produces “Ambiguous match.” These are heuristics, not probabilities. Quantity differences appear only when the match is clear and the units agree. A human still checks the original wording and any exclusions.

Seven tests passed, covering quantity changes, different units, ambiguous duplicates, unrelated requests, evidence preservation, invalid input and local HTTP guards. I ran inference from the model cache with offline flags enabled.

My 12 author-written diagnostic cases produced ten intended outcomes, including the two unrelated requests. Among ten related requests, eight received the intended match after the threshold. A simple token Jaccard baseline also ranked eight of ten first. This small set does not establish that the model is generally better than keywords.

The two failures matter. One request for a web page ranked email copy first, but the small score gap marked it ambiguous. Another intended landing-page request fell below the threshold. I left both in the report. Warm local analysis had a median of 6.83 ms, excluding model loading; this is a developer diagnostic, not an independent benchmark.

The Python server binds to loopback and does not log request bodies. The page uses local assets and no browser storage. Refreshing loses the workspace; copied or downloaded notes remain wherever the user keeps them. The model supports English descriptions here, and nearest-row matching cannot resolve a request that spans several deliverables. Brief Ledger is a review worksheet, not contract interpretation.

Why Does Open Innovation Matter?

A freelancer can cache the weights, disconnect and still compare a brief. Client text does not need to go to an inference provider, and each comparison has no API charge. Those properties fit a small installation-and-support service with predictable running costs. A laptop, setup time and the initial model download are still required.

The open code also exposes a decision that is easy to hide: when should a weak match stop being a suggestion? I can inspect the threshold, replace the model and rerun the same cases. The original brief and failed cases remain available while I make that choice.

My next validation would be watching a consenting copywriter use the tool on a brief they choose, then asking whether this comparison saves enough effort to pay for local setup. I have not done that test yet.

Pocket Field: one local AI card, then a little time outside

十方空烬 · Ember ☄️ — Tue, 06 Oct 2026 10:30:47 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

I wanted a small outdoor invitation, not another feed to scroll. Pocket Field turns a sentence like “I want to hear the rustling and chirping around me” into a short activity card: sit outside, listen for three kinds of sounds, and draw their directions on paper.

It is for someone who has a few minutes and wants help choosing how to spend them outside. I can choose a time budget, a setting such as a balcony or park, and whether to walk or stay in one spot. The app gives me one card. I can save it as text, print it, or remember its three steps and close the screen. The “I'm heading outside” button removes the planner and leaves only the card.

The AI is the selection engine. An open-weight sentence embedding model understands a request beyond exact keywords, while hard filters keep the selected card within the chosen time, movement and setting. The instructions themselves are a small, editable catalog of original activities. I did not need a language model inventing a trail or guessing the weather.

I started this new project on October 6, inside the first week's entry period. Earlier environment preparation was only installation and a model smoke check; it was not this entry.

Demo

Download the video walkthrough using GitHub’s Download raw file button. It shows real captured screen states: the planner, a matching card, the responsive mobile layout and the simplified card view. It is a screen-state walkthrough, not an outdoor-use recording.

See the actual downloaded text card. The laptop app runs locally; installation and offline-start instructions are in the README. The responsive layout also works at a mobile-sized browser viewport, but the loopback server is only reachable on the computer running it. I take the saved or printed card outside rather than hosting my inputs remotely.

I have tested the local matching flow, rejection cases, mobile layout and text download. I have not field-tested it outdoors yet, and I do not claim the optional outdoor-testing bonus. Print CSS is included; automated print-preview verification was inconclusive.

Code

The MIT-licensed source includes the activity catalog, local server, browser interface, frozen dependencies, diagnostic queries and results. No weights, credentials or user input history are committed.

How I Built It

I used sentence-transformers/all-MiniLM-L6-v2, an Apache-2.0 open-weight model, through Sentence Transformers on CPU. The revision is pinned in the code. It embeds a request and 16 activity descriptions into normalized 384-dimensional vectors; cosine similarity ranks the activities that survive the hard filters.

For example, “rustling and chirping” should find the sound-map card even though those exact words are absent from its description. A five-minute budget with easy walking on a balcony yields no card, instead of silently relaxing the constraints. Unrelated input such as a SQL-index request is also rejected in the recorded checks. The low-score threshold is a heuristic, not a probability of correctness.

Eight integration tests passed, covering matching, constraints, malformed requests and browser-origin/Host rejection. On eight author-written diagnostic queries, the intended card ranked first in 8/8 cases and within the first three in 8/8. Median warm local request time was 4.86 ms on the development laptop. The complete diagnostic output contains every query and result. This is a small developer check, not an independent benchmark; startup and downloads are excluded from the timing.

The server uses Python's standard library and binds to loopback. The page has no external fonts, scripts or analytics. After caching the model, I ran it with offline mode enabled. Requests stay in memory for inference and are not stored or sent to an external API. No account, API key, paid service or GPS permission is needed.

The limits are deliberate: English input, a small catalog, no route guidance and no claims about species, health or weather. A local semantic matcher can still misunderstand an unsupported request. The next useful test is taking a card outside and seeing whether its steps are easy to remember.

Why Does Open Innovation Matter?

For this project, openness lets the screen stop being a dependency. I can cache the weights, disconnect from the internet and still choose a card. A closed API would add a server connection and put the request into someone else's infrastructure; this workflow does not need either.

Openness also makes the recommendation inspectable. I can read the exact card the model is ranking, change its wording, or add a seated alternative. A contributor can replace the model and rerun the included diagnostic queries, rather than trusting an opaque service or repeating my performance numbers.

I want the useful output to fit on a scrap of paper. The model makes that first choice easier; the rest of the experience belongs outside.

Shelf Friend helps my friend compare supermarket prices and product care

十方空烬 · Ember ☄️ — Fri, 02 Oct 2026 06:39:11 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

A friend needs help while shopping at a supermarket: compare prices, understand how a kitchen or household item should be used, and weigh its advantages against the maintenance it brings home.

I built Shelf Friend, a small Chinese-language web app with two connected decisions: what costs less per usable unit, and what fits the intended use? My friend stays anonymous. I have not yet collected their feedback, so the results below are my implementation checks, not a claimed user study.

The calculator takes prices from the shelf, net quantity and pack count. The AI retrieves a relevant use guide or buying checklist from a small, visible corpus. A cheaper pan may still be a poor purchase if its weight, stove compatibility or care routine does not fit the person buying it.

Demo

Open the live demo — no account or API key needed.

Try this short walkthrough:

Click 试试演示价格 (“Try demo prices”). The fictional rice offers are 2 kg for 2.50 OMR and 500 g for 0.75 OMR. They become 1.25 and 1.50 OMR/kg; the first is 16.7% cheaper per kg. These are demonstration prices, not retailer quotes.
Click 铸铁锅保养 (“Cast-iron care”). The browser downloads the model on first use, then retrieves a guide scoped to Lodge's seasoned cast iron, with a source link and a maintenance tradeoff.
Try 保鲜盒怎么用 (“Food-container use”) or ask in English, “How should I clean and oil a cast iron skillet?” The interface and guides are Chinese, but query matching is multilingual.

Code

Public repository · MIT application code and original checklists.

I started this project and its repository on October 2, 2026, inside the weekend challenge window. It is separate from my weekly challenge work and uses no employer resources.

How I Built It

The AI core is Transformers.js running the quantized ONNX conversion of the open-weight multilingual MiniLM model. A web worker embeds the question and the guide descriptions, then ranks them by cosine similarity. This is model inference, not a keyword lookup. The app displays only the highest-ranking guide above its threshold, or says the corpus has no sufficiently relevant content. Similarity is labelled as similarity, not a probability or factual-accuracy score.

The eight-guide corpus covers cookware, pantry packaging, cleaners, food containers, small appliances, tissue multipacks and batteries. Most entries are my original buying checklists. The cast-iron entry is a concise, linked summary of Lodge's care instructions, with its scope explicit. Unknown product specifications are left unknown.

Price arithmetic is deterministic JavaScript. It normalizes grams/kilograms and millilitres/litres, accounts for multipacks, and rejects comparisons between mass, volume and count. The model never calculates the winning price.

In Edge, I checked Chinese cast-iron, bulk-rice and food-container queries, an English cast-iron query, and an unrelated football question that returned no guide. I also checked the public deployment, a small-phone layout and landscape layout. Automated tests cover unit conversion, incompatible quantities, invalid inputs, zero prices, ties and similarity arithmetic. These checks are limited; I have not benchmarked retrieval accuracy or tested every phone.

The first model download is about 118 MB. It took 13.3 seconds in my public-demo test; one later query completed in about 0.1 seconds. That is one browser observation, not a speed promise. I would load it before entering a supermarket with weak reception. Caches may help later use, but I do not promise offline availability on every device.

Why Does Open Innovation Matter?

Open weights make the semantic search usable inside the shopper's own browser. I can inspect and change the corpus, pin the model revision, and keep shopping questions away from a remote inference service. I do not need a subscription, an API secret on the page, or a server that stores my friend's questions. Initial runtime and model downloads still contact public CDNs and produce ordinary request metadata.

The base model and Transformers.js use Apache-2.0 licenses. Their open distribution made this small, reproducible deployment possible. The application and checklists can be inspected and improved independently of the model.

This first version supports manual shelf-price comparison and a small guide library. It does not scrape live retailer prices, recognize product photos or barcodes, certify materials, or invent a product manual. My next useful step is to let my friend try it on a real shopping trip, then use their feedback to decide which products and instructions to add.

VoiceStack Atlas: version-aware speech deployment with Astro and Sanity

十方空烬 · Ember ☄️ — Thu, 01 Oct 2026 18:46:35 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.

What I Built

I built VoiceStack Atlas, a deployment planner that keeps old speech-tool documentation in its own era. It asks for a runtime profile, reads structured compatibility rules from Sanity, and returns decisions tied to original, commit-pinned sources.

The interesting case is CUDA 12 with cuDNN 8. A generic “GPU requirements” search can surface different documentation eras. The current faster-whisper README documents a specific CTranslate2 workaround; the v1.0.0 README describes a different CUDA stack. I model the condition and documentation status separately, so a historical fact cannot become today's installation instruction.

The same distinction applies to audio: built-in file decoding does not mean an 8 kHz NumPy array will be resampled. The planner separates those paths and reminds the caller that transcription starts when the segment generator is iterated.

Demo

Open the project.

Try CUDA 12 / cuDNN 8 / Raw NumPy array, then change CUDA to 13. The second profile should ask for more evidence rather than inventing an installation command. Switch to CPU and file input to see GPU requirements disappear.

The deployed Astro app reads the public Sanity dataset without a login or browser token. I verified the current CUDA 12 / cuDNN 8 / array profile, the unsupported CUDA 13 profile, and CPU / file input against real Content Lake documents.

Open the full-size screenshot.

Code

Source code and reproducible checks.

Original compatibility annotations, constraints, interface, and evaluation are my work. Public faster-whisper documentation and source code are credited and preserved under their upstream MIT license. No employer code, recordings, datasets, or credentials are used.

My Build Process

I started by asking for conditions, conclusions, actions, and provenance to be separate fields. A polished answer is not useful if it mixes a release-era requirement with a current requirement.

I used the Codex desktop IDE to build a narrow planner and source validation first, then an Astro interface. The build instructions evolved from a real Context-connected agent to a directly verifiable structured-content app. This is a summary of the iteration, not a verbatim prompt transcript: separate conditions from conclusions; preserve literal evidence from pinned files; refuse unsupported profiles; and verify Sanity reads before publishing. An early assumption about the historical README failed its literal evidence check. I corrected the annotation against the actual pinned file. That failure shaped the design: source checks are part of the workflow, not a decorative citation after the answer.

I initially attempted Path One with a Sanity Context Knowledge Base. Public website ingestion succeeded, but the completed build exposed no readable entries, and endpoint creation returned a not-found page. I did not present the offline planner as a working MCP agent. I prepared a direct Content Lake version in Astro instead, because its structured decision model is valuable without a live model loop. The Context harness remains experimental code, not a claimed completed agent.

The second correction was operational. I created source and compatibility-rule documents in a personal public Content Lake dataset, added a native source reference, and configured credential-free browser reads. An import token stays in a local ignored environment file. The frontend has no token and fetches the live rules on each resolution. I checked three profiles against the live dataset before switching the public deployment from the earlier offline prototype.

I kept the decision engine deterministic: a runtime profile must satisfy every applicable condition, and historical records only appear in a separate context section. This makes the result traceable and gives unsupported combinations a useful failure state. I did not use App SDK or Workflows; the scope is an Astro frontend over structured Sanity content.

How I Used Sanity

The Content Lake model has two document types. source stores repository, ref, commit, original URL, and license. compatibilityRule stores when, status, claim, action, and a native sourceRef reference to the pinned source document. Conditions combine device, CUDA major, cuDNN major, and audio input format. The historical/current status is independent of those conditions.

The Astro frontend reads those documents through public GROQ queries and applies all conditions together. It displays an error when Sanity is unavailable; no cached compatibility answer is silently substituted. Tokens used for import stay on the server side and are never shipped to the browser.

Sanity Project Details

Project ID: jud8maoc. Dataset: production.

Public source corpus.

Inspect the public dataset. It contains four source documents and eight original compatibility rules. No credentials are required.

For example, a rule combines device: cuda, cuda: 12, and cudnn: 8, with status: current, an evidence literal, an action, and sourceRef pointing to a commit-pinned document. A source reference is shared provenance; the historical/current field controls whether the rule can drive a current decision.

Validation and Limits

Local checks cover current versus historical dependency selection, missing versions, unsupported combinations, CPU separation, file versus array handling, and missing or unknown citations. Each curated evidence literal was checked against its pinned upstream file.

I have not run GPU inference or claimed speed, memory, or speech accuracy results. This tool is a deployment planning aid, not proof that a dependency stack works on every machine. The Context prototype has not passed a real retrieval run, and is not the finished submission.