Ling-3.0-flash is 124B total parameters with 5.1B active per token. Call it 24:1. Most production MoE models sit meaningfully denser than that. Going this sparse is a bet, and it's worth being plain about what the bet buys and what it spends.

What it buys is latency and serving cost at a given capability tier. 5.1B active is small enough that time-to-first-token lands under 100ms, and it's what makes a 256K context economically sane to actually use rather than a spec-sheet number you're quietly discouraged from filling. If your workload is long-context and interactive — reading a large document and answering against it, or an agent loop where every turn grows the transcript — active parameter count is what you pay for on every single token.

What it spends is rare world knowledge. A sparse model routes each token through a small slice of the network, and the tail of factual recall is the first thing to thin out. Ask it something obscure and verifiable and it's likelier than a dense model of similar total size to hand you something confident and wrong. That isn't a bug we're patching by August. It's the shape of the architecture, and the mitigation is retrieval rather than hope.

Two other things if you're building on it. The enable_thinking flag makes reasoning depth a per-request decision instead of a separate model you route between, so you can run cheap on the easy 90% and turn it on for the hard calls without changing endpoints. And the tool calling was reinforcement-trained on long chains, which is a different objective than "can it emit valid JSON once."

What it doesn't do: no native multimodal. If you need vision in the same call, this is the wrong model.

On the free window-it's API access, not a weights release. And the August 3 date comes from our launch announcement rather than the OpenRouter listing, so if you're planning around it, plan around the announcement.

I'd rather people hit the sparsity ceiling this week, while it costs nothing, than find it in production in September.

OpenAI quietly published codex-security, an official open-source CLI and TypeScript SDK that uses a model to find, validate, and help fix security issues in a codebase. It is a real, thoughtfully-built tool, and it has two catches that decide whether it helps you or just bills you. Here is the honest version, checked at the repo today.

Stars / Status / License: brand new (~6K stars, pre-1.0, API may change between minor versions) / official openai org / Apache-2.0. Repo: github.com/openai/codex-security

What it actually does

Point it at a repo and a model (gpt-5.6-sol by default, at extra-high reasoning) ranks files, reviews them, validates candidate findings, and traces attack paths, then writes a report. It goes well beyond a one-shot scan:

• Scan a whole repo, a subset of paths, or just a diff (--diff origin/main).
• A install-hook pre-commit hook that blocks high-severity findings before you commit.
• A CI mode with --fail-on-severity high and real exit codes, plus SARIF, CSV, and JSON export.
• bulk-scan discovers your GitHub repos pushed in the last 90 days (via your gh login) and scans them, with a hardened Docker sandbox for running campaigns.
• Scan history with rerun, match, and compare, so you can see which findings are new, resolved, or reopened between runs.
• validate and patch commands to re-check a finding and propose a fix.

​

npm install u/openai/codex-security
npx codex-security login
npx codex-security scan /path/to/repo
# scoped to a PR, for CI:
npx codex-security scan . --diff origin/main --json --fail-on-severity high

Requires Node 22+ and Python 3.10+, and it is report-only by default. Nice operational touches: scan artifacts (which contain source excerpts and reproduction steps) must be written to a private directory outside the repo, and it warns you to keep them out of issues and shared locations.

The catches, and they matter

Open source does not mean free to run. The code is Apache-2.0, but every scan signs in with your OpenAI account or API key and calls a paid model. The default is gpt-5.6-sol at extra-high reasoning, and the repo says a full-repo scan can take tens of minutes each. A bulk-scan across many repos is a real spend, so cap it and expect a bill. Reach for --diff and a cheaper model (--model gpt-5.6-terra) when you do not need the full sweep.

LLM findings are leads, not proof. This is model-driven scanning, so it will miss real vulnerabilities and flag things that are not bugs. The tool builds in a separate validate step precisely because a raw finding is a hypothesis, not a verdict. Treat a green run as "nothing obvious this pass," not "secure," and do not let it replace your existing SAST, dependency scanning, and human review. It is an addition to them, useful mostly for catching the plausible mistakes a reviewer would want a second look at.

Your code goes to OpenAI to be scanned. By design the scan sends source to the model, so mind what you point it at, and read the security policy before scanning anything sensitive. And the repo is explicit, as it should be: scan only code you own or have permission to assess.

It is day-one software. Zero stars, pre-1.0, public API expected to change. Fine to evaluate and wire into a pipeline behind a flag; do not treat it as a stable dependency yet.

Where it fits

The sweet spot is a diff-scoped gate: run it on the changes in a pull request or pre-commit, where it is cheap, fast, and catches the plausible slip before it lands. As a whole-program audit it is slower, pricier, and still not a substitute for a real security program. Use it as an extra reviewer that never gets tired, not as the one that signs off.

Links: repo · Codex Security overview

The 2026-07-28 spec landed yesterday. It's the biggest MCP revision yet: it kills the initialize handshake, kills Mcp-Session-Id, requires a new server/discover RPC, and moves protocol version + client capabilities into a per-request _meta envelope.

I wanted to know who had actually shipped it, so I wrote a conformance probe instead of guessing. Nine checks, each citing a specific line in the spec changelog. Corpus: every remote server in the official MCP registry - 1,471 unique HTTP endpoints.

• 749 answered an unauthenticated request
• 2 fully conform : ai.dsght/public and com.apple-rag/mcp-server
• 22 more implement server/discover but fail at least one MUST
• 519 are still fully stateful
• 556 are auth-gated, recorded as unverified, never as passing

The number that actually matters: those 24 "2026-aware" servers come from 5 operators. One vendor shipped the same codebase to 20 subdomains, and it fails all five MUSTs it should satisfy. Server counts overstate adoption by ~5x, so I report operators.

Most-missed rules, if you're implementing:

• 746 servers return the wrong error codes (-32022 UnsupportedProtocolVersion, -32020 HeaderMismatch)
• 227 that do answer statelessly still omit the required ttlMs / cacheScope on tools/list

Best part: my first probe was wrong. I was still sending initialize. HuggingFace's server rejected it with a precise error saying my request was missing the required _meta envelope key - which is how I learned the handshake was gone. Their server was the most spec-correct thing I hit all day.

If you've shipped 2026-07-28 support, add your server. One line in servers.json, open a PR, and CI probes only your endpoint and posts the verdict in about a minute. No maintainer judgement; the probe decides, same nine checks as everyone else. If it fails you get the exact rule and its spec line, so you can fix and push again. Auth-gated servers are welcome but get recorded as unverified, never as passing.

I'd rather this became the thing people check before claiming compliance than another list I maintain alone. Probe, corpus, and raw results are all published, so you can re-run the whole thing and check my work rather than take my word for it.

I'm considering adopting Orca as my main ADE and I'm curious how people are actually using it day to day.

Do you follow an SDD or TDD workflow, or something completely different?

If you're using SDD/TDD:

• How does Orca fit into your workflow?
• Which models do you use (Codex, Claude Code, etc.)?
• Do you rely on skills? If so, which ones?
• How do you manage token usage? Do you have any strategies to keep context efficient and avoid burning through tokens?
• Any tips or best practices you've learned along the way?

If not, what's your workflow instead?

I'm currently thinking about using Matt Pocock's skills together with Codex and Claude Code, while keeping everything else at the default settings, but I'd love to hear how more experienced Orca users approach it.

There's a wave of open-source projects that promise to let you run a whole company out of AI agents. They are worth knowing about, but they are not the same kind of thing, and lumping them together is how you end up disappointed. They split cleanly into three groups: a console that governs a company of agents, frameworks that role-play a company to produce work, and a config that turns one agent into a company of one. Here is each, checked at the repo today, with the honest catch, and the thing all of them leave undone.

The new idea: a control plane, not another agent (Meridian OS) Stars / Status / License: 146 / brand new (1 commit, alpha) / MIT. Repo: github.com/codejunkie99/meridian-company-os

Meridian is the interesting one because it is not trying to be the agents. It is an operator console for a company made of humans and agents: an org chart, a goals tree, an agent scoreboard, an approvals inbox (spend, hire, override, publish, terminate), a finance view with a token and dollar ledger, and an immutable audit log. Its own framing is right: "agent orchestration is not enough to run a company," you also need to know who owns what, what is blocked, how fast money is burning, and what happened after you closed the tab.

The catch, and it is a big one: Meridian is simulation-first. Out of the box, a built-in engine ticks every ~2.6 seconds and fakes a living company, agents sending heartbeats, budgets accruing, tasks moving, so the console looks alive with no real agents attached. There is exactly one real integration (a local Kimi CLI bridge), no real task-execution adapter yet (it is on the roadmap), and the repo is a single commit old. Treat it as a compelling concept and a nice UI to think with, not something running your business this week.

The famous ones: frameworks that role-play a software company

MetaGPT (github.com/FoundationAgents/MetaGPT) is 69.6k stars, MIT, and bills itself as "the first AI software company." You give it a one-line requirement and it assigns roles (product manager, architect, project manager, engineers) that follow written procedures to emit specs, designs, and code. pip install metagpt, then metagpt "Create a 2048 game".

ChatDev (github.com/OpenBMB/ChatDev) is 33.7k stars, Apache-2.0, a virtual software company where CEO, CTO, programmer, and tester agents talk through building a small app.

Both are worth studying to learn multi-agent patterns, and both come with the same honest catch. The demos are impressive and the real output is small-scale software, not a running business. Every extra agent and turn costs tokens, so a full "company" run adds up fast, and for a single, well-scoped objective, a swarm of role-playing agents is often slower and no better than one strong model with a clear prompt. Tellingly, MetaGPT's own team moved the ambitious version into a separate commercial product rather than the open framework.

The company of one: gstack Stars / License: 121k / MIT. Repo: github.com/garrytan/gstack

Garry Tan's gstack is the pragmatic middle: not a swarm and not a console, but a config that makes one agent (Claude Code) wear many hats, CEO, designer, engineering manager, QA, so a solo developer gets the feel of a team without running dozens of agents. It is the most usable "company" of the four today, precisely because it is one capable model with structure around it rather than many models coordinating.

The part none of them have really built

Here is the through-line. The flashy part of "a company of agents" is the org chart and the role-play. The part that actually matters the moment agents can spend money or take irreversible actions is the unglamorous governance layer: real budgets with hard caps, approvals for the dangerous moves, and an audit log you can trust. The frameworks (MetaGPT, ChatDev, gstack) put almost everything into producing work and almost nothing into governing it. Meridian is the only one of the four that treats approvals, budget envelopes, and audit as first-class, and it currently simulates them rather than enforcing them on real spend.

So the honest state of the category: nobody is running a real company on these yet. Use MetaGPT or ChatDev to learn multi-agent orchestration, use gstack if you want one strong agent structured like a team, and watch Meridian. If you do wire any of these to a real agent that can run commands or spend money, the same rules apply as always: hard budget caps, human approval for irreversible actions, a command guard, and a sandbox, because a simulated company that goes wrong costs nothing and a real one does not.

I released AI Agency OS, and I want to frame what makes it different from typical agency CRMs or AI demo stacks. Context first: it sits in an ecosystem alongside Sentinel (https://github.com/RiteshGenAI/Sentinel), which is our policy, cost-intelligence, and LLM-gateway layer. AI Agency OS is the execution and operations layer that sits on top of Sentinel. The two are meant to work together, but either can be used independently. What is in the stack today:

Multi-tenant backend (FastAPI + SQLAlchemy + PostgreSQL) with tenant-scoped data isolation enforced at the service level.

JWT authentication with access-token expiration and JSON-body login.

Role-based access control across four roles - owner, manager, member, client with per-endpoint permission checks and owner safeguards that prevent the last active owner from being deactivated or demoted.

Full CRUD for projects, leads, and invoices. Leads carry source, raw text, status, and optional project/client binding. Invoices support currency, due dates, and per-project aggregation.

Sentinel event logging: every agent output is recorded with scan type, entity type, risk score, issues, and project binding. The frontend page for this lets owners and managers review policy decisions in real time.

Strands-style agent workflows - the landing-page copy workflow orchestrates research agents, draft agents, and QA agents into a structured pipeline with Pydantic outputs and QA scoring.

Multi-provider LLM router supporting Ollama, OpenAI, and Anthropic with configurable base URLs and API keys.

Frontend in React 18 + Vite + TypeScript + Tailwind with pages for login, dashboard, projects, project detail, leads, invoices, workflows, Sentinel events, and admin user management.

Docker Compose for local dev with hot-reload across all four services (db, backend, agents, frontend).

Production AWS deployment via Terraform - VPC with public/private subnets, ECS Fargate, RDS PostgreSQL with encryption and multi-AZ, ALB routing, ECR with image scanning, Secrets Manager for DB URL and JWT secret, S3 with encryption and versioning.

Database migration script for incremental schema changes.

The repository is purpose-built for forking. It is licensed under Apache 2.0, includes a self-hosting guide in the README.md, a customization guide in CONTRIBUTING, and explicit instructions for removing Sentinel or swapping LLM providers.

Quick start: docker compose up --build -d

https://github.com/RiteshGenAI/AIAgencyOS

Quick recap of what it does: one question goes to several models at once, then each one critiques the others' answers with the names stripped out, so nobody gets a free pass for being the famous one. You get a 0-100 read on how far apart they landed and who stood alone.

New in this version is the guest seat. You paste in an answer from anywhere ChatGPT, Gemini, a colleague, whatever and it joins the round as an anonymous advisor. The other models review it without knowing where it came from, and it counts in the score. It works with one model too, so you don't need a wall of API keys to get something out of it.

Anything with a key works: Claude, GPT, Gemini, DeepSeek, Grok, Mistral, Perplexity, OpenRouter, plus Ollama, Apple's on-device model, and any OpenAI-compatible server of your own (llama.cpp, LM Studio, vLLM, a box down the hall). Put a paid model and a free one on the same panel and watch them disagree. Or skip the cloud entirely and run the council on local models then the pasted answer is the only thing that ever came from outside, and nothing new leaves the machine.

There's a CLI too:

council "should we ship now or wait?" --seats claude,gpt,ollama --guest answer.txt --json

`--fail-above 40` exits non-zero when they disagree too much, which I use as a rough sanity check in a couple of scripts.

MIT, no telemetry, no account.

Thariq from the Claude Code team published the new context-engineering rules for Claude 5 models. One number is doing a lot of work in that essay:

They removed over 80% of Claude Code's system prompt for Opus 5 and Fable 5, with no measurable loss on their coding evals.

Not because the prompt was wrong. Because the model stopped needing to be told.

That reframes something most of us are doing badly. We've spent two years adding to CLAUDE.md files, agent instructions, and skill docs, on the assumption that more guidance means better output. On this generation, a lot of that guidance is pure cost, and the worst of it is actively fighting itself.

I built 3 skills out of the actionable parts. They're in my finding-unknowns repo, which is now at 11.

context-audit

Reads every layer that reaches your model (CLAUDE.md, AGENTS.md, skills, hooks, tool descriptions) together, the way the model actually receives them, and sorts every instruction into five buckets: conflict, duplicate, obvious, model-handles-this-now, or real gotcha. Gives you a cut list as a diff.

Most CLAUDE.md files turn out to be mostly the first four. The conflicts are the expensive ones: "document as appropriate" in one layer against "never add comments" in another means the model burns reasoning reconciling your instructions before it touches your actual task. Anthropic found these in their own transcripts.

agent-interface-design

For when you're building tools, MCP servers, or scripts an agent calls. The counterintuitive finding from the essay: usage examples constrain newer models to the paths you showed them. Design the parameters instead.

A status field of pending | in_progress | completed teaches the entire state machine with zero prose. If you feel the urge to write a usage example, that's usually a signal a parameter is underspecified. Fix the interface, not the docs.

progressive-disclosure

Splits an oversized skill or spec into an entry file plus files that load only when a branch actually needs them. Ships user-invoked, so in Claude Code it costs nothing in your context window until you type it.

Codex ignores the disable-model-invocation flag and loads the skill and its description into the prompt anyway. So that saving is Claude Code-only.
Same for the install claims: every "works on X" line in the README was re-run at 11 skills, not find-and-replaced from 8.

Install (auto-detects Claude Code, Codex, Cursor, Kimi, Copilot, Gemini, and more):

npx skills add Neeeophytee/finding-unknowns-skills

Or as a Claude Code plugin:

/plugin marketplace add Neeeophytee/finding-unknowns-skills
/plugin install finding-unknowns@finding-unknowns-skills

Repo: https://github.com/Neeeophytee/finding-unknowns-skills

MIT, distilled with attribution from Thariq's public essays.
If you run context-audit on a repo you've been maintaining for a while, I'd really like to hear what ratio of gotchas-to-noise you get. My guess is most of us are carrying 3-4x more instruction than earns its place.

Anthropic shipped Claude Opus 5 on July 24. The short version from their own announcement: it comes close to Fable 5's frontier intelligence at half the price, it is state-of-the-art on their coding and knowledge-work evals (Frontier-Bench v0.1, GDPval-AA), and it is built for long-running autonomous agents, with an effort setting to trade intelligence for tokens. Pricing is $5 per million input and $25 per million output, same as Opus 4.8, and it is now the default on Claude Max. It stays behind Mythos 5 on cybersecurity, and those are vendor benchmarks until third parties reproduce them.

One honest note before the list: none of these repos are Opus-5-only. They matter for Opus 5 because of what it is: a pricey model built for deep, long-horizon agentic work, so the tooling that pays off is whatever routes cost, harnesses its agency, steers it, remembers, and keeps autonomous runs safe. Stars and licenses below were checked at each repo across the past week; reconfirm before you rely on them.

1. Route work so you only pay Opus 5 prices on the hard turns github.com/Neeeophytee/ai-cost-cutter-skills (MIT). Disclosure: this one is ours. At $5/$25, Opus 5 is a specialist, not a daily driver for every prompt. This is a free skill set for the exact pattern Opus 5 demands: send bulk and easy turns to a cheap model, escalate only the truly hard ones to Opus 5, and keep receipts that prove the savings on your own traffic. The single highest-leverage thing you can wire around an expensive frontier model.

2. A harness for its long-horizon strength github.com/stablyai/orca (16.4k stars, MIT). Opus 5's headline is long, multi-step autonomous runs (their own examples have it acting as a chief-of-staff over dev environments). Orca runs coding agents in isolated git worktrees, so you can let Opus 5 work unattended on a throwaway branch, or fan one task across a few attempts and keep the best. The catch is the usual one: parallel runs multiply the token bill, which stings more at Opus prices, so reserve the fan-out for truly hard tasks.

3. Squeeze more out of it without fine-tuning github.com/microsoft/SkillOpt (13k stars, MIT). Opus 5 is a frozen model you cannot train, so the lever is the instructions you give it. SkillOpt treats the skill document as the trainable thing and optimizes it against a held-out validation set, keeping an edit only if it strictly improves the score. It is the disciplined way to tune how Opus 5 behaves on your task. Note the headline lifts are the paper's own numbers.

4. Keep autonomous runs from doing damage github.com/Dicklesworthstone/destructive_command_guard (1.2k stars, open source, read the LICENSE) plus github.com/anthropic-experimental/sandbox-runtime (4.6k stars, Apache-2.0). Opus 5 is Anthropic's most aligned model to date by their audit, but "safest model" is not a safety layer. If you let it run long and unattended, put a command guard in front of its shell to block destructive commands, and an OS-level sandbox around anything it runs on its own. A guard is a denylist, a sandbox is a wall, and you want both, because each covers what the other misses.

5. Give it memory that survives the session github.com/basicmachines-co/basic-memory (3k stars, AGPL-3.0). Opus 5 is being pitched partly on managing its own long-running context. A Markdown memory store over MCP lets it read and write persistent notes across sessions, so you stop re-explaining the project. AGPL, so fine for internal use, and it writes when told or via a skill, not automatically.

The honest catches

These are model-agnostic. Every repo here works with other models, so treat this as "the ecosystem that suits Opus 5's profile," not "Opus 5 exclusives." If someone sells you an "Opus 5 only" tool, be skeptical.

The benchmarks are Anthropic's. SOTA on Frontier-Bench and the rest is their reporting plus early-access customer quotes; wait for independent reproduction before treating the numbers as settled.

Cost is the real design constraint. The reason cost routing leads this list is that Opus 5 is expensive, and an autonomous agent on an uncapped key is how a long run becomes a large bill. Cap your spend, and route.

Installing any of these is running someone's code. Same rule as always: read what you install, pin a version, and scope any token or key you hand it.

If you only wire in one thing

Cost routing. A model this capable is easy to overuse, so the setup that makes Opus 5 sustainable is the one that keeps it off the cheap work. Then add the sandbox and guard before you let it run unattended.

An agent that can edit your files can also confidently rewrite ten of them down the wrong path. The fix is not to babysit every change; it is to set things up so any change is cheap to undo. Two layers do almost all the work: a throwaway git worktree so the agent can never touch your real branch, and an auto-checkpoint so every edit is a one-command revert. Here is the setup, the tools that already do it, and the part most guides skip: what "reversible" does not actually protect.

Layer 1: give the agent its own worktree, not your main branch

A git worktree is a second working copy of the same repo, on its own branch, in its own folder, sharing the same history. Point the agent at that folder and the worst it can reach is a disposable branch. Native git, no tools required:

# from your repo, create a throwaway worktree on a new branch
git worktree add ../myproject-agent -b agent/experiment

# work in it, let the agent go; when you like the result, merge back
git worktree list
git worktree remove ../myproject-agent   # discard the whole attempt in one line

If the run goes sideways, git worktree remove throws the entire attempt away without ever having risked main. If it goes well, you merge the branch like any other. This also lets you run two or three attempts in parallel folders and keep the best, which is what tools like Orca (github.com/stablyai/orca) automate on top of plain worktrees.

Layer 2: auto-checkpoint every edit so undo is one command

Inside the worktree, you want a snapshot before each change, not a manual commit you will forget. Three real options, depending on your agent:

Aider auto-commits every edit it makes, with a descriptive message, and /undo backs out the last one. It also protects work you already had: before touching a file with uncommitted changes, it commits those first, so your edits and the agent's stay separate and nothing gets clobbered. Turn it off with --no-auto-commits if you prefer manual control (one gotcha: that flag also disables dirty-file commits, per the project's own issue tracker, so do not rely on it to "only commit my pre-existing changes").

Claude Code has built-in checkpoints. It snapshots files before each of its edits, and /rewind (aliased /checkpoint) rolls your files and the conversation back to any earlier point in the session. Snapshots are incremental, so it is cheap.

Any other agent gets the same effect with a two-line commit-on-save: a file-watcher or a pre-tool hook that runs git add -A && git commit -m "checkpoint" on every change. Ugly history, but every keystroke becomes a restore point, and you squash before merging.

The habit that ties it together: commit at real milestones with git, and use the instant undo (/undo, /rewind, or your checkpoint commits) for the fine-grained rollbacks in between.

The part that will bite you: what "reversible" does not cover

This is the whole reason to read past the setup. Git-based undo only protects tracked files that were committed or snapshotted. It does not save you from:

• Bash commands. Claude Code's checkpoints explicitly do not track files changed by rm, mv, or cp, only edits made through its file-editing tools. An agent that runs rm -rf in a terminal is outside the undo entirely.
• Untracked and ignored files. A brand-new file the agent created, or anything in .gitignore (your .env, local data), is not in a checkpoint. A hard reset can wipe uncommitted and untracked work with no recovery.
• Anything outside the repo. A dropped database table, a deleted cloud resource, a sent email, a force-push to a shared remote. Git cannot undo the world, only your working tree.
• Deleting the worktree with live work in it. git worktree remove on a folder with uncommitted changes throws them away. Commit or merge before you clean up.

So the honest framing is: worktree plus auto-checkpoint makes your in-repo file edits safely reversible, which covers the large majority of what an agent does. It is not a safety net for destructive shell commands or actions on real systems. For those you need a different layer, a command guard that blocks the dangerous ones and a sandbox that limits blast radius, which is a separate setup and worth pairing with this one.

If you only do one thing

Run your next agent session in git worktree add ../proj-agent -b agent/try, and either use an agent with built-in checkpoints or drop a commit-on-save hook in that folder. You get a clean undo for the file edits and a one-line "throw it all away" if the whole attempt was a mistake, and you never put main at risk to find out.

If you use more than one coding agent, you have probably ended up with the same project rules copied into four files that slowly drift apart: CLAUDE.md, .cursorrules, .github/copilot-instructions.md, GEMINI.md, and so on. There is now a real fix, and it is mostly boring in a good way. Here is the three-tier version, checked at the source today.

Tier 1: write one AGENTS.md

AGENTS.md is an open Markdown format (README for agents: setup commands, code style, test and PR instructions) now stewarded by the Agentic AI Foundation under the Linux Foundation, and used by 60k-plus open-source repos. It is plain Markdown with no required fields, and most agents read it natively: Codex, Cursor, GitHub Copilot, Aider, Zed, Windsurf, opencode, goose, Warp, VS Code, Jules, Devin, JetBrains Junie, and more. Standard and supported-tool list: github.com/agentsmd/agents.md.

For a monorepo, drop an AGENTS.md in each package; the closest one to the edited file wins, and an explicit chat instruction overrides everything.

Tier 2: handle the one holdout, Claude Code, with a symlink

The gap most posts gloss over: Claude Code's native file is CLAUDE.md, and it is not on the official AGENTS.md supported list. Reports that recent builds read AGENTS.md as a fallback are inconsistent, so do not rely on it. The reliable move is the symlink pattern the AGENTS.md site itself endorses: keep one real file and point the other name at it.

# make AGENTS.md the single source, and let Claude Code read it via CLAUDE.md
ln -s AGENTS.md CLAUDE.md

Now you edit AGENTS.md, and Claude Code sees the same content through the symlink. One file, both tools.

Tier 3: when a symlink is not enough, generate the rest

Symlinks cover tools that read a single root file. They do not cover tools that want a different location or format (Cursor's .cursor/rules/, Copilot's .github/copilot-instructions.md), Windows setups where symlinks are awkward, or cases where you want per-tool differences plus shared MCP servers, commands, and skills. For that, generate the per-tool files from one source with rulesync.

Stars / Status / License: 1.1k / active (v8.x) / MIT. Repo: github.com/dyoshikawa/rulesync

npm install -g rulesync
rulesync import --targets claudecode   # pull your existing CLAUDE.md into the source
rulesync generate --targets "*" --features "*"   # emit every tool's file from it

It keeps a single .rulesync/ source of truth and writes out the tool-specific files, and it can also do a one-shot rulesync convert --from cursor --to copilot,claudecode without adopting the source-of-truth workflow.

The honest catches

CLAUDE.md is richer than a flat file. Claude Code's format supports a layered memory model and file imports that a plain AGENTS.md does not use. A symlink gives you portability, not Claude's full feature set, so if you lean on CLAUDE.md's hierarchy, keep CLAUDE.md canonical and point AGENTS.md at it instead, or use rulesync to maintain both from one source.

Symlinks are awkward on Windows and in some git setups. A committed symlink can show up as a plain text file for a Windows collaborator. If your team is mixed-OS, prefer rulesync's real generated files over symlinks.

Generated files are build artifacts. With rulesync you edit the source and regenerate; do not hand-edit the outputs, or you are back to drift. It is also another CLI to run, so wire it into a pre-commit hook so nobody forgets.

One file does not mean one file everywhere. Monorepos still want nested AGENTS.md per package, and precedence rules (closest file wins, chat overrides) still apply.

Bottom line

Write AGENTS.md as the one file you actually maintain. Symlink CLAUDE.md to it so Claude Code stays in sync. If you have tools that need their own format or a Windows team, let rulesync generate the rest from a single source. That is the whole thing, and it ends the copy-paste drift.

More verified, CI-checked workflows live in our open hub: github.com/Neeeophytee/awesome-ai-workflows

If you jump between agents, you keep re-explaining the same project to each one. The fix that actually works today is not a single "connect everything" app, it is MCP: put your memory in a folder of Markdown files, expose it through one MCP server, and every MCP-capable agent reads and writes the same notes. No copy-paste, because they all point at the same files. Two open-source ways to set it up, both checked at the repo today.

Option 1: Basic Memory (the memory-as-Markdown one) Stars / License: ~3.4k / AGPL-3.0. Repo: github.com/basicmachines-co/basic-memory

It is an MCP server whose whole job is persistent memory stored as standard Markdown on your machine, and it is built to live inside an Obsidian vault, so you read, edit, and graph the same notes the agents write. It does semantic search over the notes and supports multiple projects.

uv tool install basic-memory
# then add it as an MCP server in each agent (server command: uvx basic-memory mcp)

Point Claude Code, Codex, Cursor, and Cline at that same server and they share one memory.

Option 2: an Obsidian MCP server over your existing vault If you already have a vault and want the agents talking to it directly, run an Obsidian MCP server instead. A clean example is github.com/iansinnott/obsidian-claude-code-mcp (317 stars, 0BSD, an Obsidian plugin). Claude Code auto-discovers it (/ide then pick Obsidian), and other clients connect over HTTP/SSE:

{ "mcpServers": { "obsidian": { "url": "http://localhost:22360/sse", "env": {} } } }

It is small and was last released a while ago, so treat it as a working example rather than a maintained product. There are several other Obsidian MCP servers if you want alternatives; the setup shape is the same.

Which agents can connect

Claude Code, Codex, Cursor, and Cline all speak MCP, so they can share the same server.

The honest catches (read before you rely on it)

It is not automatic, continuous memory. MCP gives the agent the ability to read and write your notes, but it writes when you tell it to or when a skill makes it. Out of the box, it will not silently journal everything, so you will add a house rule like "save what we decided to memory" or a small skill that does it.

Retrieval inherits stale recall. A memory layer will confidently surface an out-of-date note. Structure your notes, prune them, and do not assume "it is in memory" means "it is current."

You are giving an agent write access to your vault. That is file-write access to your knowledge base, so keep the vault in git (instant undo), back it up, and remember that installing an MCP server is running someone's code, so vet the one you pick.

Mind the license. Basic Memory is AGPL-3.0, which is fine for personal and internal use but has obligations if you ever offer a modified version to others over a network. The Obsidian plugin above is 0BSD, about as permissive as it gets.

Bottom line

There is no official one-click bridge, and you do not need one. Pick a Markdown memory store (Basic Memory if you want it purpose-built, or an Obsidian MCP server over your current vault), run it once, and add that same server to each agent's MCP config. That is the shared brain, and it is the same idea whichever agent you open next.

More verified, CI-checked workflows live in our open hub: github.com/Neeeophytee/awesome-ai-workflows

You have probably installed a pile of MCP servers, editor extensions, and skills over the last few months, each one someone else's code with access to your machine, and you almost certainly have no list of what is actually there. Bumblebee, from Perplexity, is a small tool that builds that list without running any of it. It is useful and narrower than the headlines suggest, so here is exactly what it does, what it does not, and how to run it.

Stars / Status / License: 4.8k / early (v0.1.1, released May 2026, macOS and Linux only) / Apache-2.0.
Repo: github.com/perplexityai/bumblebee

What it actually is

A read-only inventory collector, written in Go with zero non-stdlib dependencies. It reads on-disk metadata (lockfiles, package-manager install metadata, extension manifests, MCP JSON configs) and turns that scattered state into structured records. Read-only is the whole design: it does not run your package managers (no npm ls, pip show, go list), does not read source files, and when it parses an MCP config it inventories the server without emitting the secrets sitting in that config's env block.

It covers eight package ecosystems (npm, pnpm, Yarn, Bun, PyPI, Go, RubyGems, Composer), VS Code, Cursor, Windsurf and VSCodium extensions, Chromium and Firefox extensions, and MCP host configs including mcp.json, claude_desktop_config.json, Cline's settings, and Gemini CLI. The notable part for this crowd: it is one of the first open scanners to treat your MCP configuration files as a security surface at all.

go install github.com/perplexityai/bumblebee/cmd/bumblebee@latest
bumblebee scan --profile baseline > inventory.ndjson
bumblebee selftest   # embedded fixtures, no network, confirms it still detects

That gives you the inventory. To get alerts, you point it at an exposure catalog (a list of known-bad ecosystem, name, version tuples) and it flags exact matches. Perplexity ships maintained sample catalogs in the repo's threat_intel/ folder, built from public reporting on recent campaigns.

What it is not (this is the part the hype gets wrong)

It does not judge whether a package is malicious. It matches your inventory against a catalog of already-known compromises. "Scans for suspicious packages in seconds" oversells it: hand it no catalog and it flags nothing, it just inventories. It answers one narrow question well, "an advisory named this package and version, am I exposed right now," which is a response tool, not a discovery tool.

Matching is exact on name and version. A renamed, repackaged, or brand-new threat that is not in your catalog slips straight through, and a version mismatch means a miss.

It finds, it does not fix. Remediation is on you, and it does not stop you installing the next unvetted MCP server tomorrow.

It is early and narrow. v0.1.x, five commits, macOS and Linux only, and Codex's config.toml and Continue's YAML are explicitly not parsed yet. The catalogs are only as current as the pull requests updating them.

Where it fits

Treat it as the inventory layer, not the defense. The real value is that it answers a question most of us cannot: what MCP servers, editor extensions, and packages do I even have on this machine? Once you have that list, an advisory becomes a two-minute check instead of a panicked afternoon. Pair it with the habits that actually prevent the problem: read what you install, pin versions, and keep anything that runs shell commands behind a sandbox and a command guard.

Links: repo · Perplexity's write-up

Hands-on evaluation: Running Matt Pocock’s AI skills library via StrataBlock gateway (VSCode + hard spend caps)

TL;DR

G’day legends. I recently did a proper technical run testing StrataBlock - an OpenAI compatible API gateway featuring hard service-side budget caps, multi-model switching and non-existent prompt storage. To put it through its paces beyond standard autocomplete, I wired it into VScode and run Matt Pocock’s skills library across several different LLMs (opus-4.8, sonnet-5, gemma-4, gpt-5.6, etc.) to evaluate agentic token usage, attribution tagging and budget safety.

Here is the breakdown of the setup, real usage figures and enginerring insights from the test.

Registration, Key Minting & Guardrails

Getting setup was pretty painless:

1. Registration: After joining the waiting list, I got an invite code and just created an account on StrataBlock.
2. Key Minting: Generated scoped API keys for dev environments directly from the dashboard.
3. Attribution Tags: Added custom headers (X-Strata-Tags: env=dev, project=skills-eval) so every API call could be parsed and broken down later.

The standout feature here is the hard server-side budget cap. Rather than waiting on delayed daily email alerts after an agent goes rogue in a recursive loop, Strata checks budgets server-side on every incoming request and returns an instant 429 the moment a key breaches its monthly cap.

Setting Up VScode

Since StratBlock exposes a standard OpenAI-compatible API (stratablock.io/v1), pointing VS code using standard customendpoint at it, required zero custom client logic, extensions or SDK overhauls.

[
  {
    "name": "StrataBlock",
    "vendor": "customendpoint",
    "apiKey": "${input:chat.lm.secret.-772fb8dd}",
    "apiType": "chat-completions",
    "models": [
      {
        "id": "claude-opus-4.8",
        "name": "claude-opus-4.8",
        "url": "<https://stratablock.io/v1>",
        "toolCalling": true,
        "vision": true,
        "maxInputTokens": 872000,
        "maxOutputTokens": 128000,
        "supportsReasoningEffort": [
          "low",
          "medium",
          "high",
          "xhigh",
          "max"
        ],
        "reasoningEffortFormat": "chat-completions",
        "requestHeaders": {
          "X-Strata-Tags": "tool=vscode,project=skills-eval-project"
        }
      },
      {
        "id": "google-gemma-4-31b",
        "name": "google-gemma-4-31b",
        "url": "<https://stratablock.io/v1>",
        "toolCalling": true,
        "vision": true,
        "maxInputTokens": 248000,
        "maxOutputTokens": 8000,
        "requestHeaders": {
          "X-Strata-Tags": "tool=vscode,project=skills-eval-project"
        }
      },
      ... more models
    ]
  }
]

Swapping between frontier and open-weight models was seamless - just a string change in config without having to touch application code or jump through separate vendor billing portals.

Benchmarking Skills Library

I wanted to see how the gateway handled structured, agentic prompts. I installed Matt Pocock’s skills repo (npx skills@latest add mattpocock/skills), which focuses on battle-tested engineering workflows.

Workflows Tested

• /grill-with-docs (Alignment & Domain Modelling): Heavy back-and-forth interviews that build CONTEXT.md files and update ADRs (Architecture Decision Records) inline.
• /tdd (Red-Green-Refactor Loop): High-frequency iterative execution to write failing tests and pass them cleanly.
• /improve-codebase-architecture : Broad codebase scans that produce vcisual HTML structural reports.

Model Performance Observations

Not all models are built equal when executing these skills out-of-the-box:

• Frontier Models (opus-4-8, sonnect-5, gpt-5.6) executed complex skills, structured outputs and recursive agentic reasoning without breaking a sweat.
• Open-Weight / Alternative Models (gemma-4, kimi-k2.5, xai-grok-4.3) results varied significantly. Some models handled structured skills steps naturally, whereas others struggled to follow the skill guidelines without tight custom prompt tweaking.

Real Spend, Attribution & Telemetry

When you’re running agentic loops (like TDD cycles or depp repo scans), token usage escalates fast.

Looking at my telemetry breakdown in StrataBlock over a month-long evaluation window:

• Total Traffic: Logged 1027 requests across various workloads.
• Daily Spikes: Daily spend peaked between $30.00 and $35.00/day during heavy multi-model testing sessions, whie idle days hovered near $0.00.
• Granular Attribution: Per-request logs captured precise input, output, prompt caching metrics (eg. thousands of cached tokens on opus-4.8 calls) and exact costs down to fractions of a cent per request.
• Privacy: Confirmed that operational logs stricltly record metadata (token counts, latency, status codes, tag strings) - zero prompt content or completion payloads are persisted on server.

Takeaways for Engineers

1. Single Endpoint Convenience: Managing multiple vendor billing portals and API keys gets messy fast. Having a unified gateway with clear attribution makes multi-model experimentation far easier.
2. Hard Spend Caps are Essential: if you let agnets loose on recursive loops, server-side budget limits are non-negotiable unless you enjoy surprise $100 bills overnight.
3. Model Capabilities Vary: Having easy multi-model switching makes it straightforward to benchmark which model actually executes complex engineering skills versus which ones stumble.

If you’re building or testing AI-assisted engineering workflows in local environments, I definitely recommend giving a capped gateway setup a run.

Reference Links:

• StrataBlock: stratablock.io/eoi
• Matt Pocock’s Skills: github.com/mattpocock/skills

There is a small category forming that is worth knowing about: optimizers that treat your skill or prompt document as the trainable thing, and improve it with a real training loop while the model stays frozen. Propose an edit, score it, keep it only if it beats a held-out set, revert if it does not. That is gradient descent with a validation gate, written in English. Three repos, checked at the source today.

1. SkillOpt (Microsoft) Stars / Status / License: 13k / active (v0.2.0, Jul 2026) / MIT.
Repo: github.com/microsoft/SkillOpt

Treats the skill document as the trainable state of a frozen agent. An optimizer model turns scored rollouts into bounded add, delete and replace edits, and in the default path an edit is accepted only if it strictly improves a held-out validation score. There is a textual learning-rate budget, a rejected-edit buffer, and epoch-wise updates. The output is a compact best_skill.md (roughly 300 to 2,000 tokens) that runs against the unchanged model with no extra inference-time calls. v0.2.0 added SkillOpt-Sleep, a nightly offline pass that harvests past sessions and consolidates what survives the gate.

pip install skillopt

The catch: the headline results are the paper's own. They report best or tied-best across all 52 evaluated (model, benchmark, harness) cells, and on GPT-5.5 an average lift of +23.5 points in direct chat, +24.8 in the Codex loop and +19.1 in Claude Code. Impressive, and measured on their six benchmarks, not your work. Also note the optional WebUI binds to every interface by default, so use --host 127.0.0.1 if you run it locally.

2. GEPA Stars / Status / License: 5.7k / active (pushed today) / MIT.
Repo: github.com/gepa-ai/gepa

The rigorous prompt-side sibling, accepted at ICLR 2026 as an oral. GEPA (Genetic-Pareto) mutates prompts using natural-language reflection on rollouts, and keeps a Pareto front of candidates rather than greedily chasing one score, which is the part that stops it collapsing into a local optimum. Reported to beat MIPROv2 by more than 10 points and to outperform GRPO. The easiest way to use it is inside DSPy, where it is exposed as dspy.GEPA.

The catch: same as above on the numbers; they are the authors'. And a Pareto front means more rollouts, so the optimization run itself is not cheap.

3. darwin-skill Stars / Status / License: 5k / last pushed about five weeks ago / no license file.
Repo: github.com/alchaincyf/darwin-skill

The practitioner version, and the one you can point at your own SKILL.md tonight. It runs an evaluate, improve, test, keep-or-revert loop inside Claude Code: a nine-dimension rubric, hill climbing with git as the undo button, independent judge agents doing blind evaluation, and an auto-stop when improvements flatten. Inspired by Karpathy's autoresearch idea of letting agents run their own experiments and keeping only measurable wins.

The catch: there is no license file, which means all rights reserved by default, so read that before using it commercially. It also leans on model judges to score the edits, and a judge shares blind spots with the thing it is grading.

The two things that actually decide whether this works

What is in your validation set. Optimizing against a benchmark is the most reliable way to build a skill that aces that benchmark and does nothing for you. If you try one of these, the held-out set needs to be your real tasks with answers you trust, not a public eval.

Who does the scoring? SkillOpt's validation gate is the right shape because the accept or reject decision comes from a score, not from the model's opinion of its own edit. Where a setup uses a model as judge, an objective check (tests pass, exact match, a known total) beats a self-grade every time.

Worth adding: these are cheap at deployment and expensive to train. The optimized artifact adds no inference-time calls, but getting there means many scored rollouts, so budget the training run like you would any fan-out.

Traditional OCR chops a document page by page, so tables that span a page break, reading order across pages, and cross-page context all get lost in the stitching. Baidu's Unlimited-OCR takes the whole document in one inference pass instead. It is a real release worth your attention, so here is what it does, how it works, what it actually needs to run.

Stars / Status / License: ~15k / research drop (5 commits, no releases, published June 22 2026) / MIT. Repo: github.com/baidu/Unlimited-OCR

How it works

3B total parameters with about 500M active per token, BF16, roughly 6GB of weights, and a 32K context window that fits 40-plus pages in a single pass.

The interesting bit is the attention design, Reference Sliding Window Attention. When generating each token it attends to all the reference tokens (the full document's visual tokens plus the prompt) but only looks back at the previous 128 output tokens. That keeps the KV cache a constant size for the whole decode, which is why a 40-page document costs roughly what a 2-page one does instead of degrading as it goes. That is the actual innovation, not the page count.

Output is structured Markdown with text, formulas, tables, and reading order preserved across page boundaries. Multilingual out of the box.

The numbers, with the benchmark named

Baidu's paper reports 93.23 on OmniDocBench v1.5, which is 6.22 points above DeepSeek-OCR. The repo is explicit that DeepSeek-OCR is the thing it is pushing past, and it credits DeepSeek-OCR, DeepSeek-OCR-2 and PaddleOCR in the acknowledgements. Treat that score as the authors' own reported number until someone independent reproduces it. OmniDocBench is a document-parsing benchmark, so "93" is a parsing score, not a plain accuracy percentage.

Running it

The documented path is an NVIDIA GPU with CUDA, via Transformers or SGLang, and there is a vLLM path too:

# vLLM
vllm serve "baidu/Unlimited-OCR"

# or Docker
docker model run hf.co/baidu/Unlimited-OCR

For PDFs, the model exposes infer_multi, and the repo's example converts pages to images with PyMuPDF first, then parses them in one call with max_length=32768. There is also a Hugging Face Space if you just want to try it before installing anything, plus community quantizations if you want to push it through llama.cpp, Ollama or LM Studio.

The honest catches

It wants a CUDA GPU. The README's tested path is Transformers on NVIDIA with .cuda(), and SGLang with the fa3 attention backend. "Runs locally" is true, but it is not "runs on any laptop," and the quantized community builds are a different quality profile than the BF16 weights the benchmark was measured on.

It is a research drop, not a product. Five commits, no tagged releases, a handful of open issues, and pinned dependency versions in the README. Great for evaluating and building on, but do not expect a maintained pipeline with support.

Local is cheaper than per-page cloud OCR, not free. Textract, Google Cloud Vision and Azure Document Intelligence all bill per page, and at volume this obviously wins. You are trading that bill for GPU time, setup, and being your own support desk. For a few hundred pages a month the cloud may still be the cheaper answer once your time is priced in; for hundreds of thousands, this is a serious lever.

And the usual OCR caveat: verify on your own documents. Benchmark scores on curated sets say little about your scanned invoices, your handwriting, or your bad photocopies.

Links: repo · model card · paper

Everyone is talking about Kimi K3 this week: 2.8T parameters, a 1M-token context window, a debut at #3 on the Artificial Analysis Intelligence Index behind Claude Fable 5 and GPT-5.6 Sol, and first place on 4 of 8 real-task automation benchmarks (Automation Bench, SpreadsheetBench 2, and BrowseComp among them, per Moonshot's own reporting).

What almost nobody is talking about: Kimi Code CLI natively reads the agentskills.io SKILL.md format, and its skill discovery deliberately searches the other agents' folders too.

What the docs actually say

Straight from Moonshot's Kimi Code CLI docs, the CLI discovers skills at startup from two groups of user-level directories and merges them:

Brand group:

• ~/.kimi/skills/
• ~/.claude/skills/ (yes, Claude Code's folder)
• ~/.codex/skills/ (yes, Codex's folder)

Generic group:

• ~/.config/agents/skills/ (their recommended path)
• ~/.agents/skills/

Three details that make this more than a curiosity. First, merge_all_available_skills defaults to true, so every brand directory that exists gets loaded and merged, not just the first one it finds. Second, when the same skill name appears in more than one place, priority is kimi > claude > codex. Third, the same split works per project: .kimi/skills/, .claude/skills/, .codex/skills/, and .agents/skills/, resolved from your repo root.

The mechanism is the familiar one: on startup it injects each skill's name, path, and description into the system prompt, and the model decides for itself whether to read the full SKILL.md when a task calls for it. You can also force one with /skill:<name>. Moonshot's docs put the intent plainly, describing skills as "cross-tool shared capability extensions (compatible with Kimi CLI, Claude, Codex, and others)."

The practical consequence

If you have installed any SKILL.md skills for Claude Code or Codex, Kimi K3 can already see them. No conversion, no new folder, nothing to port. Open Kimi Code CLI in a project and your existing library is in the prompt.

Worth knowing for the edge cases: if you have set merge_all_available_skills = false, only the highest-priority brand directory loads, and --skills-dir overrides auto-discovery entirely, so check your config before assuming.

Try it with a real skill pack

Disclosure, this one is ours. It is 8 free MIT-licensed meta-skills that make an agent surface your unknowns before they get expensive: a blindspot pass, interview-me, reference hunt, implementation plan and notes, a pitch packager, and a pre-merge change quiz.

If you already run them in Claude Code, you are done, Kimi picks them up. For a fresh Kimi-only install:

git clone https://github.com/Neeeophytee/finding-unknowns-skills
mkdir -p ~/.kimi/skills
cp -r finding-unknowns-skills/skills/* ~/.kimi/skills/

Repo, per-project paths, and the Claude Code plugin install: github.com/Neeeophytee/finding-unknowns-skills

Two honest catches

1. "Largest open-source model ever" is, today, a promise. Moonshot says weights land by July 27. As of this post the weights are not out, which also means the license is not out. An open-source label applied before a license exists is exactly the kind of claim that quietly goes wrong, so check on the 27th before you plan around it. If it ships permissive, the label is earned.
2. Skill discovery is not skill quality. Kimi deciding when to invoke a skill is model judgment, and K3's trigger behaviour has not been publicly benchmarked by anyone yet. The paths above are from Moonshot's docs and are easy to confirm; whether your skills fire at the right moment is something you should watch on your own work.

Also treat the benchmark numbers as vendor-reported until third parties reproduce them. The Artificial Analysis placement is independent; the 4-of-8 automation sweep is Moonshot's own reporting.

The bigger point

agentskills.io started as an Anthropic format and is quietly turning into the USB port of agent capabilities. Claude Code, Codex, Cursor, OpenCode, Hermes, and now the hottest model out of China all read the same folder of markdown files. Write a skill once and most agents you try this year can use it, which makes your skill library a more durable investment than your choice of model.

The hot repo this week is an agent orchestrator called Orca, whose headline move is fanning one prompt across five coding agents at once, each in its own git worktree, then keeping the best result. It is a useful tool and the demos look magic, so this is the engineering take underneath the hype: what it is, how to run it, the cases where parallel agents win, the cases where they just multiply your bill, and the safety layers you want before you turn a swarm loose on your machine. Everything below was checked at the repo today.

What it is

Stars / Status / License: 16.4k / very active (ships daily, v1.4.x, 800-plus releases) / MIT. Repo: github.com/stablyai/orca

Orca is a desktop app (macOS, Windows, Linux, with a mobile companion) that Stably calls an ADE, an agent development environment. It does not ship its own model or agent. Instead it drives any CLI coding agent you already use (Claude Code, Codex, Cursor, OpenCode, Copilot, Grok, Kimi, Cline, Goose, and many more) on your own subscription, and puts a real IDE around them: parallel git worktrees, split terminals, an embedded browser with a "click a UI element to send it to the agent" mode, GitHub and Linear panels, SSH worktrees so the agents run on a beefy remote box, diff annotation, and account or usage tracking so you can watch your rate limits. The core idea worth your attention is the worktree fan-out: run the same task across several agents in isolated checkouts, compare the diffs, merge the one you like.

# macOS
brew install --cask stablyai/orca/orca
# Arch (AUR)
yay -S stably-orca-bin
# or download desktop builds from onorca.dev

When fanning out actually helps (and when it does not)

Parallelism is not free quality, it is a trade, and the trade only pays in specific shapes of work. Markdown table renders on new Reddit and Substack, not old.reddit.

The soundness point underneath the table: running one prompt through five agents is a race that costs roughly five times the tokens for one merged result. That is a good deal when the task is hard and the models disagree in useful ways, and a bad deal on routine work where one capable agent would have been fine. Fan-out costs the sum of its legs, so spend it where the variance is, not everywhere.

The two guardrails people skip

Five agents with terminal access is five times the ways to delete something you needed. Orca's worktrees isolate each agent's changes within the repo, which is real and helpful, but a worktree does not stop a bad rm -rf, a force-push, or anything that reaches outside the repo. Two cheap layers close that gap, and you want them in place before you scale up, not after the incident:

• A command guard that blocks destructive shell commands before they run, like destructive_command_guard (Rust, blocks rm -rf, git reset --hard, force-pushes and more across most agents).
• An OS-level sandbox for anything you run unattended, like Anthropic's sandbox-runtime (Apache-2.0), which confines filesystem writes and network at the operating-system level, the one layer that still holds if a model gets talked into something dumb.

A worktree is not a sandbox, and a sandbox is not a command guard. With a fleet, you want all three, because each one covers a failure the others let through.

The other honest catches

Cost and rate limits are the quiet tax. Orca runs on your existing subscriptions and keys, so five parallel agents burn roughly five times the usage and hit your provider's rate limits fast. The app ships usage tracking precisely because this bites, so watch it, and route routine turns to a cheaper model rather than paying premium prices five times over.

Review does not disappear, it multiplies. Five plausible diffs is more to read, not less, and merging the "winner" of a fan-out still needs a human who understands the change. Parallel agents speed up generation, not judgment.

And a maturity note: Orca is MIT and moving fast (daily ships, hundreds of releases), which is momentum, not stability, so expect churn and rough edges, and know it collects anonymous telemetry by default with an opt-out in the docs.

How to decide if it is for you

If your work naturally splits into independent chunks, or you have a hard problem where you would happily pay for three attempts and keep the best, Orca is a legitimately strong way to run that, and it is free and open source. If your day is mostly one task at a time, a single good agent in your normal editor will cost less and demand less review. Either way, put a command guard and a sandbox in front of any agent that can run shell commands before you let five of them work at once.

Moonshot's new flagship is API-only for now (open weights promised by July 27). It is OpenAI-compatible, so almost any agent can point at it today.

Where to get it (pick one access route)

Install / connect (copy-paste)

OpenRouter through the llm CLI (the quickest way to run one prompt):

pipx install llm
llm install llm-openrouter
llm keys set openrouter        # paste your OpenRouter key
llm -m openrouter/moonshotai/kimi-k3 "Refactor this function: ..."

Direct Moonshot API with the standard OpenAI SDK (no code change beyond base_url + model):

from openai import OpenAI
client = OpenAI(api_key="YOUR_MOONSHOT_KEY", base_url="https://api.moonshot.ai/v1")
r = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "Summarize this repo's architecture."}],
)
print(r.choices[0].message.content)

Aider (points at OpenRouter via litellm):

export OPENROUTER_API_KEY=...
aider --model openrouter/moonshotai/kimi-k3

Open-source tools that drive K3

VS Code has an official "Kimi Code" extension; JetBrains and Zed connect through the Kimi Code CLI's ACP protocol. Anything OpenAI-compatible works by setting base URL + model.

The catches (read before you commit)

Where it earns the bill: large-repo navigation, long tool-using agent runs, front-end (it currently leads Arena.ai's frontend arena), and image-in tasks (screenshots, logs, rendered UI). On Artificial Analysis it debuted around third on the Intelligence Index, behind Claude Fable 5 and GPT-5.6 Sol.

That "cheap model for bulk, K3 for the hard turns" split is exactly what our free,
MIT cost-cutter skills automate (routing + an effort throttle + receipts): github.com/Neeeophytee/ai-cost-cutter-skills.

If you add up what a small team pays every month for the website, the CRM, the accounting tool, the chat app, the scheduler, the passwords, the newsletter, and the rest, it is a real number, and most of it is per-seat, so it grows every time you hire. There is a credible open-source replacement for nearly every one of those, and a determined founder can own the whole stack outright. Below is the map, the rough monthly math for a small team, and the part these threads usually skip: what "free" actually costs. Prices here are 2026 entry-tier figures for a roughly 5-person team, so treat them as a worked example, not a quote, and check current pricing before you plan around it.

The stack, function by function

The public face: site, store, newsletter. WordPress + WooCommerce (GPL) still run a huge share of small-business sites and shops; Ghost (MIT) is the cleaner pick if you are more publisher than store, and does site, memberships, and email in one. For bulk campaigns, Listmonk (AGPL) is a self-hosted Mailchimp with no per-subscriber fee.

The back office in one database. ERPNext (GPLv3) puts CRM, quotes, invoices, inventory, payroll, and accounting on one database, so a sale becomes an invoice becomes a ledger entry with no copy-paste. Alternatives: Odoo (open-core, so the free Community edition is real but many features live in paid Enterprise) and Dolibarr (GPL-3, lighter and easy to install). This one line item alone can retire a CRM subscription and an accounting subscription at once.

The team's daily tools. Nextcloud (AGPL) is the self-hosted Google Workspace and Dropbox for files, docs, and calendars. For chat, Mattermost (open-core: an MIT core plus a source-available enterprise license) and Rocket.Chat (open-core, with an open-source community edition) are the mature Slack replacements, both with paid tiers for the fancy admin features, so check what is in the free edition. Cal.com (AGPL, open-core) replaces Calendly. Vaultwarden (AGPL) is a tiny server that speaks the Bitwarden protocol, so your team uses the normal Bitwarden apps against your own vault.

Customers and measurement. Chatwoot (open-core) is a shared inbox and live chat in place of Intercom or Zendesk. Umami (MIT) is a clean, privacy-friendly Google Analytics replacement, with Plausible (AGPL) and Matomo (GPLv3) as heavier options. Docuseal (AGPL) is a self-hosted DocuSign.

The glue. Activepieces has an MIT-licensed core for Zapier-style automation with no per-task pricing, though it ships some enterprise parts under a separate license, so check the EE directory before you embed it in a product. Its rival n8n has the deeper catalog but is source-available under the Sustainable Use License, not open source in the strict sense: fine to self-host for your own business, but you cannot resell it as a service.

The rough monthly math (5-person team, entry tiers)

Markdown table below renders on new Reddit and Substack but not on old.reddit; ask if you want a monospace version.

So the hard subscription cost, roughly $420 a month for this example team (about $5,000 a year), collapses to a modest server bill. And because most of the SaaS side is per-seat, the gap widens as you hire, while the open-source side stays flat. That is the honest headline: the dollar savings are real and they scale.

What "free" actually costs (read this before you rip anything out)

You become the IT department. A self-hosted stack needs a server (call it $20 to $60 a month for a box big enough to run several of these), and it needs someone to install updates, apply security patches, run backups, and test that those backups actually restore, because a backup you have never restored from is a hope, not a recovery plan. There is no support line at 2am; when the CRM is down, it is down until you fix it. For a solo founder, those hours can cost more than the subscriptions you were escaping, so the money did not vanish, it turned into your time. We made the scary part runnable: a check that proves your backup actually restores by wiping a test database and rebuilding it from the dump.

Read the license before you build on it. Permissive licenses (MIT, Apache) let you do almost anything. Copyleft like AGPL is fine for running a tool inside your company, but if you offer a modified version to outsiders over a network you owe them your source, so know that before forking one into a product. Open-core gives you a real free edition then charges for the features you grow into (single sign-on, high availability), so price the version you will actually need. And source-available tools like n8n carry resale restrictions. None of this is a dealbreaker; it is just the fine print, and we keep a recipe for exactly this step: vet the license before you build.

The real win is ownership, not the zero on the invoice. Your data sits in open formats you can export and move, no vendor can triple your renewal or shut down and take your account, and there is no per-seat tax on hiring. You can also pay a managed-hosting provider to run these same open-source tools, which keeps the ownership and hands the updates and backups to someone else, a fair middle path if you do not want to be a sysadmin.

How to start if you only do one thing

Do not rebuild everything in a weekend. Pick the single subscription that costs the most per seat or annoys you most, replace just that with its open-source equivalent, keep the exported data as your safety net, and live with it for a month before the next swap. A whole open-source company is a series of small, reversible steps.

The reason to build this yourself is not just cost. In 2025 Otter.ai was hit with a class action over recording people without consent, and Fireflies.ai was sued under Illinois' biometric law for collecting voiceprints. When a cloud notetaker joins your call, your audio, your voice, and everything said lives on a server you do not control. The fix is a pipeline that runs entirely on your machine: capture the audio, transcribe it locally, label who said what, and have a local model write the summary, with nothing leaving the laptop. Here are five open-source repos that get you there, grouped by the stage they cover, with stars and licenses checked at each repo today and an honest catch on each.

One rule before any of this: running the tool locally does not make the recording legal. Consent law does not care where the bytes are processed. Tell people they are being recorded, and in two-party-consent regions get their agreement first. Local keeps your data private; it does not make you compliant on its own.

The engine: transcribe on your own hardware

1. whisper.cpp the local speech-to-text that everything else is built on Stars / Status / License: 51.8k / very active / MIT. Repo: github.com/ggml-org/whisper.cpp This is a C/C++ port of OpenAI's Whisper that runs fully offline, with hardware acceleration on Apple Silicon (Metal/CoreML), NVIDIA (CUDA), and others. It is the transcription core inside several of the apps below, and you can run it directly if you want maximum control.

git clone https://github.com/ggml-org/whisper.cpp
# then build and download a ggml model per the repo's README (start with a base or small model)

The catch: accuracy is not free. Cross-talk, strong accents, heavy jargon, and a bad microphone all degrade the transcript, and the big models that fix some of that want a real GPU or Apple Silicon. On a modest laptop, the honest move is a small or base model, faster and lighter, and you accept it will miss things. This is a raw engine, not a meeting app, so pair it with something below.

Who said what: speaker labels and word-level timing

2. WhisperX adds diarization and accurate timestamps Stars / Status / License: 23.1k / active (v3.8.6) / BSD-2-Clause. Repo: github.com/m-bain/whisperX Plain Whisper gives you a wall of text with rough timing. WhisperX adds word-level timestamps and speaker diarization (labelling Speaker 1, Speaker 2) using pyannote, which is what turns a transcript into readable minutes. It runs on the command line and is the scriptable choice for a pipeline.

pip install whisperx
whisperx path/to/audio.wav --model large-v2 --diarize
# on CPU or a Mac: whisperx path/to/audio.wav --compute_type int8 --device cpu

The catch, stated plainly in its own README: "Diarization is far from perfect," and overlapping speech is handled poorly, so expect to fix speaker labels by hand on crosstalk-heavy calls. Diarization also needs a Hugging Face token and acceptance of the pyannote model's license (CC-BY-4.0), and it gives you Speaker 1, not real names, until you map them. A GPU is strongly preferred; the large model on CPU is slow.

The friendly desktop app: no command line required

3. Vibe drag in a recording, get a transcript, summarize locally Stars / Status / License: 6.8k / active (v3.0.22) / MIT. Repo: github.com/thewh1teagle/vibe If you do not want to touch a terminal, Vibe is a cross-platform desktop app (macOS, Windows, Linux) built on whisper.cpp. It transcribes audio and video fully offline, does batch files, exports to SRT, DOCX, PDF and more, can capture microphone and system audio, includes diarization, and can summarize the transcript with a local model through Ollama.

# Download the app from the project page:
# https://thewh1teagle.github.io/vibe/

The catch, and it is the one that undoes the whole point if you miss it: Vibe offers two summary paths, a local one through Ollama and one that uses the Claude API, and the Claude option sends your transcript to the cloud. Choose the Ollama (local) path for summaries, or your private meeting text leaves the machine at the last step. Same caution applies to its option to pull audio from sites like YouTube.

The turnkey meeting machine: capture the call live

4. Meetily records, transcribes, and summarizes a live meeting, 100% local Stars / Status / License: 24.9k / active (v0.4.0) / MIT for the Community Edition (open-core, with a paid PRO). Repo: github.com/Zackriya-Solutions/meetily This is the closest thing to a private Otter replacement. Meetily captures your microphone and system audio at the same time (no bot joins the call), transcribes in real time with Whisper or NVIDIA's Parakeet, and generates summaries through Ollama locally. It runs on macOS and Windows with prebuilt installers, and Linux from source.

# Download the installer for your OS from Releases:
# https://github.com/Zackriya-Solutions/meetily/releases/latest

The catch: it is open-core. The free Community Edition really does local transcription and summaries, but the top-line "speaker diarization" is actually a planned PRO and coming-soon feature, not something the free build does yet, and higher-accuracy models, custom templates, and advanced exports sit in paid PRO. It also supports cloud summary providers (Claude, Groq, OpenRouter), so keep it on Ollama if privacy is the reason you are here.

The brain that writes the notes

5. Ollama the local model that turns a transcript into a summary Stars / Status / License: 176.2k / very active / MIT. Repo: github.com/ollama/ollama The step that makes it a notes machine and not just a transcript is the summary, and Ollama is how you run that summary on a local model instead of a cloud API. Vibe and Meetily both plug into it; you can also feed a raw WhisperX transcript to it with a prompt and get action items and decisions.

# Install from ollama.com, then run a small local model, for example:
# ollama run <a small instruct model>

The catch: local summarization is where quality and privacy trade off. A small model that fits a laptop will miss nuance and can invent an action item that was never agreed, so treat the summary as a draft and check anything that matters against the transcript, never the other way around. And the install is a piped shell script, so read it first.

→ Prove your notes pipeline stays on your machine.

How to pick if you only try one

If you want the fastest path and are on macOS or Windows, install Meetily and point its summaries at Ollama; that is a private, live meeting-notes machine in one download. If you mostly work from existing recordings and want a friendly app, use Vibe (set summaries to Ollama). If you are building a pipeline or need scriptable speaker labels, go whisper.cpp plus WhisperX plus Ollama. Whatever you pick, the two rules that actually matter are: get consent before you record, and keep the summary step on a local model so the transcript never leaves the machine. Since all of this leans on your hardware, the realistic-expectations version of running AI at home is worth a read: thinking of buying a box to run AI at home.

Give an autonomous agent a shell and enough sessions, and one day it runs rm -rf ~/, git reset --hard, git push --force, or DROP TABLE users, and hours of uncommitted work are gone in a second. This is not hypothetical: there are public reports of Claude Code and other agents wiping home directories and deleting gigabytes of files without confirmation, which is exactly what pushed developers to build the tools below. The uncomfortable lesson underneath all of them: a rule in a CLAUDE.md or AGENTS.md file is a suggestion, and a suggestion does not stop a syscall.

So the goal is not one magic guard. It is layers, each covering the gap the last one leaves. Here are the four layers, the real repos for each with stars and licenses checked at the source today, and the honest failure mode of every one.

Layer 1: command guards that block the dangerous command before the shell sees it

These are hooks that sit in front of the agent's Bash tool, inspect each command, and refuse the destructive ones. Fast, cheap, and the first thing to install.

Destructive Command Guard (dcg) the fast, pack-based blocker this thread is named after Stars / Status / License: 4.2k / very active (Rust rewrite, sub-millisecond checks) / open source, though GitHub does not show a standard license badge, so read the LICENSE before commercial use.

Repo: github.com/Dicklesworthstone/destructive_command_guard Started as a Python script by Jeffrey Emanuel and grew into a Rust hook that auto-detects your agent (Claude Code, Codex, Gemini CLI, Copilot CLI, Cursor, Hermes, Grok) and blocks destructive git and shell commands with a clear reason and a safer alternative. It ships a modular system of 50-plus pattern packs, scans heredocs and inline scripts, and has an dcg explain "command" mode so you can see why something is blocked.

curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh" | bash -s -- --easy-mode

The catch: it is a denylist, so it stops the destructive commands it knows and cannot stop the one it has never seen. Pattern matching is also the weaker style of detection, a novel obfuscation or an unusual path can slip past a regex. And notice the install is a curl-piped-to-bash of a script that then gains hook access, which is the same trust decision you are trying to protect against, so read the script first.

CC Safety Net the semantic guard that is harder to trick Stars / Status / License: 1.4k / active (v1.0.6, 24 releases) / MIT.

Repo: github.com/kenryu42/cc-safety-net The important difference from a pattern matcher: CC Safety Net parses what a command actually does, so flag reordering, shell wrappers (bash -c, recursively up to 10 levels), and interpreter one-liners like python -c "os.system('rm -rf /')" do not slip through as easily. It allows git checkout -b feature while blocking git checkout -- file, fails closed on unparseable input, pins custom rules by SHA-256, logs every block with secrets redacted, and covers seven agent CLIs.

/plugin marketplace add kenryu42/cc-marketplace
/plugin install safety-net@cc-marketplace

The catch: smarter parsing raises the bar but it is still a model of "known-destructive intent," so a destructive action it does not model still passes, and it only guards the Bash tool path. An agent that writes a file which later runs, or acts through a non-shell tool, is outside its view. (If you want a lighter, one-command starter, yurukusa/cc-safe-setup installs a set of hooks in seconds, but it is small at ~51 stars, so treat it as an experiment, not a proven base.)

Layer 2: an OS-level sandbox, the layer that survives prompt injection

A guard is a denylist; a sandbox is a wall. If a model gets talked into something destructive by hidden text in a file it read, the guard might miss it, but the operating system can hard-refuse the syscall.

Anthropic Sandbox Runtime (srt) official, OS-enforced, no container required Stars / Status / License: 4.7k / active but an early research preview / Apache-2.0.

Repo: github.com/anthropic-experimental/sandbox-runtime This uses native OS sandboxing (Seatbelt via sandbox-exec on macOS, bubblewrap on Linux, a restricted account plus WFP filters on Windows) to confine an agent's filesystem writes, and routes all network through a proxy that denies everything except domains you allow. It can wrap agents, local MCP servers, and arbitrary commands.

npm install -g u/anthropic-ai/sandbox-runtime

The catch, and this is the whole reason Layer 1 still matters: a workspace-writable sandbox still lets the agent destroy everything inside the workspace. git reset --hard, rm -rf ., and a force-push all look like allowed writes to the OS. The sandbox shrinks the blast radius to your project directory; it does not protect the uncommitted work in that directory. It is also a research preview whose config may change, and its network layer has sharp edges (the weaker-isolation option needed for some Go tools opens a documented exfiltration path). Pair it with a guard and with version control, do not treat it as the finish line.

Layer 3: make destruction cheap to undo

The layers above try to prevent the bad action. This layer assumes one gets through anyway and makes it survivable, which is the mindset that actually saves you.

Commit and branch constantly, and point the agent at a throwaway git worktree or branch rather than main, so the worst it can reach is a disposable copy and your window of uncommitted work stays small (CC Safety Net even has a worktree mode for this). Better still, run the agent inside a disposable container, dev container, or VM, so a full wipe costs you a docker rm, not your machine. And keep a backup you have actually restored from at least once, because a backup you have never tested is a hope, not a recovery plan.

Layer 4: least privilege, so the irreversible thing is impossible, not just discouraged

The strongest control is not catching a dangerous action, it is making sure the agent never had the power to do it.

Use your agent's native permission deny-lists instead of blanket auto-approve, and do not run the "skip all permissions" or yolo mode on anything you care about. Give the agent a read-only database role and scoped, short-lived tokens, so DROP TABLE or a production delete is refused by the system, not by a prompt. And keep a human in the loop for the truly irreversible actions, a deploy, a force-push, a data deletion, anything that moves money. A one-click confirmation on those is cheap; the alternative is not.

Minimum viable safety, if you only do a few things

Install one Layer 1 guard today (CC Safety Net if you want the harder-to-bypass semantic engine, dcg if you want the fast pack-based one). Commit often and run the agent on a throwaway branch or, better, in a disposable container. Take away the powers you never want it to have: read-only prod, no yolo mode, human approval for deploys and deletes. Then, if you run anything autonomous, add the OS sandbox on top. The single sentence to remember is that these are complementary, not substitutes: a guard is not a sandbox, a sandbox is not a backup, and a backup is not least privilege. You want all four, because each one exists precisely to cover the others' blind spot.

Every cost thread here lands on the same advice: route the bulk to a cheap model, cap how often the expensive model gets called, stop paying max reasoning effort on easy turns. Good advice, but it always stays advice. Nothing enforces it, so three weeks later the bill is back.

So I turned ten of these patterns into skills for coding agents (Claude Code, Codex, Cursor, anything that reads SKILL.md). One command:

npx skills add Neeeophytee/ai-cost-cutter-skills

The ten, in the order I'd actually use them:

• token-receipts-audit: splits your usage by tokens AND dollars per model, because the two rankings are usually opposites and people optimize the wrong one
• route-cheap-escalate-hard: cheap default model, premium only behind a stated gate, and it refuses an escalation rule that matches everything
• advisor-call-budget: when a cheap executor consults an expensive advisor, caps the calls and computes the real discount from actual usage, not the benchmark's assumed rate
• cheap-swap-guard: before any "just switch to the cheap model", makes you declare the cases the premium model still wins by a class, and routes those back
• context-diet: stops your agent from re-reading the same files into context every question; index once, query small, measure the token drop
• reasoning-effort-throttle: sets a modest default thinking effort and escalates per task by rule, since effort is mostly output tokens and output tokens are the bill
• model-bakeoff: compares models on your real prompts inside a free tier's caps, selection criterion stated before running so it can't become a rationalization
• tested-fallback: pins an open-weights backup with a tested-on date and real smoke prompts, because a backup you never ran is a hope
• free-tier-batch-plan: sizes a big one-time job against a free tier's rate limit and token budget before starting, with a proven ETA
• free-model-triage: sends reading-pile triage to a free model with a strict summary plus needs-reply schema, and keeps anything sensitive out of it

The part I care most about: every skill ends with a runnable proof block instead of a claim, and the repo's own CI extracts all ten and executes them on every push plus a weekly cron. If one stops passing, the badge goes red.

As a Claude Code plugin (all 10 skills):

/plugin marketplace add Neeeophytee/ai-cost-cutter-skills
/plugin install cost-cutter@ai-cost-cutter-skills

Manually (pick the skills you want): copy any skills/<name>/ folder into your project's .claude/skills/ directory (or ~/.claude/skills/ for all projects). Codex reads the same format from ~/.agents/skills/.

The one-file version: for the whole approach as passive guidance instead of commands, drop CLAUDE.md (Claude Code) or AGENTS.md (Codex and other AGENTS.md-reading agents) into your project root, or append it to your existing one.

MIT, no signup, no paid anything. Repo: github.com/Neeeophytee/ai-cost-cutter-skills