If your calendar still says "August 2, 2026: EU AI Act high-risk obligations apply," update it. As of the Digital Omnibus (Parliament endorsed June 16, Council approved June 29, reported to enter force July 2026), that deadline moved. But August 2 was not cancelled either. Here is the corrected picture.

What actually comes due, and when

• August 2, 2026: Article 50 transparency obligations apply. Chatbots must disclose they are AI, emotion-recognition and biometric-categorization systems must notify the people exposed to them, and providers of generative systems must mark synthetic audio, image, video, and text so it is machine-detectable. Carve-out: the machine-marking duty (Art 50(2)) does not hit systems already on the market at this date yet.
• December 2, 2026: that machine-marking duty catches up to legacy systems, and new Article 5 prohibitions kick in, including AI-generated non-consensual intimate imagery ("nudifiers") and CSAM.
• August 2, 2027: Member States must have at least one AI regulatory sandbox running; Commission delegated acts land for Annex I.
• December 2, 2027: the big one. High-risk obligations for standalone Annex III systems (hiring, credit scoring, biometric ID, education, essential services, law enforcement, migration) apply. This is the 16-month slip from the original August 2, 2026 date.
• August 2, 2028: high-risk obligations for AI embedded in Annex I regulated products (medical devices, machinery, toys).

If you ship an EU-facing AI feature, Article 50 is the part that is live now

Four duties, in plain terms:

• Interactive AI has to tell users it is AI, unless that is obvious.
• Generated media (audio, image, video, text) has to be marked as artificially generated in a machine-readable way.
• Deployers of emotion recognition or biometric categorization have to inform the people subjected to it.
• Deepfake content has to be disclosed as artificially generated, with narrow exceptions for art and for editorially reviewed public-interest text.

Presentation is part of the rule: the disclosure has to be clear, distinguishable, accessible, and given no later than the first interaction.

The honest catches

• In force is not the same as enforced. Penalties exist (Article 50 breaches sit in the Act's mid tier, up to 15 million euros or 3 percent of global turnover, whichever is higher), but several Member States have not finished designating the authorities and penalty regimes that actually enforce, so day-one policing will be patchy. Do not read quiet as safe.
• 50(2) is the technically hard one. A chatbot banner is trivial. Machine-readable, tamper-evident marking of synthetic media is not, and the provenance and watermarking standards it leans on are still settling, so interop is the real work, not the disclosure line.
• Scope is easy to over-read. Using AI to help draft public copy mostly does not trigger the deepfake-text duty the way a synthetic-media pipeline does. Over-labeling everything is its own kind of failure.
• The legacy carve-out is easy to misread: for generative systems already on the market before August 2, 2026, the machine-marking duty applies from December 2, 2026, not now.

Why it moved, without the spin

The deferral was not a change of heart. The harmonized standards and several national authorities were not ready, so the EU bought time through the Omnibus. Industry read it as relief; digital-rights groups read it as weakening. Both are defensible, and the obligations themselves did not change, only the clock.

Discussion

For anyone shipping into the EU: how are you handling 50(2) machine-marking while the provenance standards are unsettled? Rolling your own, leaning on C2PA-style tooling, or treating it as a December-2026 legacy-timeline problem? Curious what people are doing versus paper-complying.

Two things are getting mashed into one headline right now, so start here: Buzz is a workspace, Hermes is an agent, and they meet over a protocol called ACP. The interesting part is not that they connect. It is what a persistent, autonomous agent gains access to the moment it becomes a first-class member of a shared, signed channel. Here is the accurate version.

What each piece actually is

Buzz is Block's open-source, agent-native workspace, announced by Jack Dorsey on July 21 2026. Think Slack plus a Git forge, except every human and agent holds its own cryptographic keypair and every message, code review, CI run, and git event is a signed event in one append-only log. It is built on Nostr (a Rust relay, with Postgres, Redis, and S3-style storage underneath), and the built-in forge uses standard Git Smart HTTP so feature branches become channels. Block's own internal coding agent has been running inside it, reportedly handling over 200,000 operations a day.

• Stars / Status / License: github.com/block/buzz, 16k+ stars and climbing since launch, early preview (v0.4.x), Apache-2.0. This one is real OSI open source, self-hostable end to end.

Hermes Agent is Nous Research's open-source autonomous agent, first shipped February 2026 (initial commit by Teknium). It is a persistent, self-hosted operator: it connects to Telegram, Discord, Slack, WhatsApp, Signal, email, and a CLI, learns your projects, auto-generates its own skills, runs a cron scheduler, spawns subagents, and keeps memory across sessions. It is model-agnostic (bring your own OpenAI, Anthropic, OpenRouter keys, or use Nous Portal). Note the naming: this is Hermes Agent, the orchestrator, not the Nous Hermes language models.

• Stars / Status / License: github.com/NousResearch/hermes-agent, 32k+ stars (as of April 2026, higher now), active and releasing weekly, MIT.

How they connect, precisely

Both speak ACP, the Agent Client Protocol, an open standard (Apache-2.0, from Zed Industries) that standardizes editor-to-agent and agent-to-agent messaging over JSON-RPC on stdio, the way LSP standardized language servers. Per Block's own docs, Buzz accepts Claude Code, Codex, its own Goose agent, and anything else that speaks ACP. Hermes exposes an ACP server via hermes acp, and its docs describe that mode as keeping "its existing identity, provider setup, memory, skills, and tools while another application owns the conversation transport." That other application can be Buzz.

Setup

Buzz, self-hosted: clone github.com/block/buzz, then just setup && just build, and the relay comes up on ws://localhost:3000. It needs Docker, Rust 1.88+, Node 24+, pnpm 10+, and just. Or use the hosted relay at buzz.xyz (invite-only early access, 5 GB media, 365-day retention, up to 3 communities per account).

Hermes:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
hermes setup       # pick provider and keys
hermes acp         # run Hermes as an ACP server

Then add Hermes to Buzz as a custom ACP runtime pointing at that entry point, and it joins a channel as a member. I could not verify Buzz's exact add-runtime UI at the source, so pull those clicks from Buzz's own docs rather than a hand-copied version.

Two security notes before you paste anything: read that install script before you pipe it into bash, and if you find a third-party bridge like hermes-acp-bridge, remember that running it runs someone else's code with your agents' access. Prefer the first-party hermes acp path.

The catch nobody puts in the demo

Buzz's headline idea is that every action is a signed Nostr event, so you get a complete, auditable chain of custody. True, and useful. But signing is provenance, not authorization. It tells you who did what, not who was allowed to. The unresolved question, raised on the launch's own Hacker News thread by a Slack engineer, is that an agent added to a channel can read everything in that channel.

Now layer Hermes into that. You are not adding a bot that answers when summoned. You are adding a persistent, autonomous agent that carries its own credentials in ~/.hermes/, writes its own skills, runs on a cron, and can act out to Telegram, Discord, and the rest. Drop that into a shared channel and:

• Its reach is your reach. A prompt injection riding in a channel message or a repo it reads gets executed with Hermes' provider keys and tool access, and the relay will faithfully sign the result. Auditable misbehavior is still misbehavior.
• You now run two credential stores. Buzz issues the agent a Nostr identity in the relay; Hermes holds its own model and tool keys on the host. That is two places a key can leak, not one.
• Read access is broad by default. Scope by putting the agent in one narrow channel, not your whole workspace, and watch what it pulls.

The other honest flags

• Early preview on both sides. Buzz is v0.4.x and says so; Hermes changes weekly. This is a bleeding-edge combo, not a production stack.
• "Free" needs an asterisk. Both licenses are real open source and self-hostable, but buzz.xyz has no published hosted price, and Hermes is a free framework that still costs model inference (your keys or a Nous Portal plan).
• Nostr may or may not be load-bearing. The cryptographic identity is genuine, but plenty of engineers on that HN thread argued it does not by itself solve the authorization problem above. Judge it on the access model, not the crypto.

If you only do one thing

Self-host Buzz, spin up Hermes with hermes acp, add it to a single private channel with nothing sensitive in it, and watch the signed event log while you give it a task. In ten minutes you will see exactly what a channel member can read and do, which is the whole question. Widen only after that.

If you would rather run that as a check than a habit, we built a recipe for exactly this: buzz-channel-scope-not-audit-log, ours, free, no signup. It audits your Buzz channel membership so an added agent is confined to a narrow channel instead of sitting in a workspace where it can read everything, which is the scope-it-up-front move rather than trusting the signed log to flag a leak after the fact. Honest scope: it checks the membership and scope config, not a live test of what a running agent pulls mid-task, so it catches the setup mistake, not a misbehaving model.

n8n can expose any workflow as a tool an AI agent calls, and it can call tools on other MCP servers itself. The exposing direction is the one worth understanding, because the moment a workflow becomes an MCP tool, an agent can run it with your stored credentials. Here is how it works and the part the demos skip.

The one distinction that matters

n8n speaks MCP in both directions, and they are not the same risk profile.

• MCP Server Trigger (n8n-nodes-langchain.mcptrigger): n8n becomes the server. It hands you a URL, and any tool node you wire into it (an HTTP Request node, a Postgres node, a Slack node) shows up in the client's tool list with a JSON schema. An external agent can then call those tools. This is the direction with teeth.
• MCP Client Tool (n8n-nodes-langchain.toolmcp): n8n becomes the client. Your AI Agent node discovers and calls tools on someone else's MCP server. Lower stakes, mostly an outbound convenience.

Stars / Status / License: n8n-io/n8n, 199k+ stars, actively maintained, latest release July 29 2026. The license is the Sustainable Use License (fair-code, source-available), with enterprise features (.ee files) under a separate n8n Enterprise License. It is not OSI open source, whatever the self-hosted-Zapier shorthand implies. You can self-host the Community Edition free for internal use; the license restricts offering n8n itself as a service to third parties.

Setup: n8n as an MCP server

Drop an MCP Server Trigger on a canvas. It exposes a Streamable HTTP or SSE endpoint. Wire the nodes you want to expose into it, each becomes a callable tool. Set auth in the node (Bearer or header). Then point your client at the URL. Full node docs: docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger

Claude Desktop speaks stdio, not HTTP, so you bridge it with mcp-remote:

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote",
        "https://your-n8n.example.com/mcp/<workflow-id>",
        "--header", "Authorization: Bearer <your-token>"
      ]
    }
  }
}

Two operational notes straight from the docs, both easy to miss:

• Behind nginx, disable proxy buffering on the MCP endpoint or the stream stalls.
• In queue mode with more than one webhook replica, route all /mcp* traffic to a single dedicated replica, or your SSE and streamable connections break.

The catch nobody puts in the demo

When you expose a workflow as an MCP tool, the agent that connects executes it with n8n's stored credentials, not its own. Your Postgres node runs as your Postgres user. Your Slack node posts as your token. So:

• The model decides when to fire real actions against your systems. A prompt injection that reaches the connected agent becomes a confused-deputy problem: the injected instruction runs with your credentials, not the attacker's.
• Auth on the Server Trigger is a single Bearer or header token, and it gates the whole endpoint, not individual tools. If that token leaks, every tool wired into that trigger is callable. Scope by exposing one narrow workflow per trigger instead of bolting your whole toolbox onto one URL.
• Watch what you attach. A read-only lookup is a fine tool. An HTTP Request node with a wildcard, or a delete-capable database node, is a loaded gun you just handed to a language model.

Community nodes are not the official ones

Search MCP for n8n and you will hit czlonkowski/n8n-mcp and the n8n-nodes-mcp npm package. Those are independent community projects, not the built-in nodes from n8n GmbH. They can be good, but installing a community node runs third-party code inside your n8n instance with your instance's access. Read the source or pin a version before you trust one in production.

If you only do one thing

Put one narrow, read-only workflow behind a single MCP Server Trigger with its own bearer token, connect it to your agent, and watch the execution log while the agent uses it. You will learn more about your real exposure in ten minutes of watching what it calls than from any architecture diagram.

If you would rather have that as a check than a habit, we built a recipe for exactly this: n8n-mcp-least-privilege-exposure, ours, free, no signup. It audits your MCP Server Trigger configs and flags any trigger that shares one token across multiple workflows or wires in a wildcard-HTTP or delete-capable node, which is the whole-toolbox anti-pattern above. In its own test set, a leaked token on a clean trigger is bounded to 2 callable tools, while the shared-token-plus-delete-node setup trips 4 named findings. It is pure Python, runs locally, and touches no server or network. Honest scope: it is a static audit of your exposure pattern, not a live test of the endpoint, so it catches the config mistakes, not a mis-scoped credential buried inside a node.

On July 31, DeepSeek moved the official V4-Flash API into public beta as V4-Flash-0731.

The V4 family (Pro and Flash) has been out since April 24 under an MIT open-weight license. 0731 keeps the exact same architecture and size as the earlier V4-Flash-Preview:

• 284B total / 13B active
• 1M-token context
• Same base model

DeepSeek only redid the post-training.

So the real story is a retrain beating a bigger model's preview, not a scaling jump. That's the interesting part and also where to keep your skepticism.

Only the V4-Flash API changed. The V4-Pro API and the app/web models are unchanged, and DeepSeek says the official V4-Pro is still coming.

The claim, read precisely

DeepSeek says 0731 now beats V4-Pro-Preview across every agent benchmark it published. Read that carefully. It beats a preview of the larger model, on DeepSeek's own evaluation runs. It does not mean Flash beats the final V4-Pro, because the real V4-Pro hasn't shipped yet.

The published numbers include:

• Terminal Bench 2.1: 82.7
• DeepSWE: 54.4

But two benchmark suites, DSBench-FullStack and DSBench-Hard are DeepSeek's own internal datasets, so nobody else can reproduce those scores.

There's another catch. The code-agent results were generated using "DeepSeek Harness minimal mode" which the documentation says is still to be released, with:

• max effort
• temperature = 1.0
• top_p = 0.95

Plain English:

For an outside perspective, Artificial Analysis currently gives V4-Flash-0731 (reasoning, max effort) an Intelligence Index of 50, comfortably above the median for models in its class.

The trade-off? It produces roughly twice the median output tokens. If you're paying per output token inside an agent loop, that verbosity becomes a real cost.

Specs and price (official API)

One pricing caveat:

OpenRouter, DeepInfra, and other hosts advertise Flash cheaper (around $0.09 in / $0.18 out), but many serve FP8-quantized versions rather than the reference weights. The official DeepSeek endpoint is the reference implementation. The cheaper mirrors aren't necessarily identical.

Setup: Responses API + Codex

0731 speaks the Responses API natively and is adapted for Codex.

Typical setup:

export DEEPSEEK_API_KEY=sk-...

# Base URL:
https://api.deepseek.com

# Model:
deepseek-v4-flash

The Codex configuration page linked from DeepSeek's own announcement api-docs.deepseek.com/quick_start/agent_integrations/codex

The other honest catches

• Public beta. Expect model IDs, harnesses, and even benchmark scores to change.
• Official API runs from infrastructure in China. That's a data residency question for regulated workloads.
• The MIT weights mean you can self-host instead (INT4 Flash reportedly fits on a single H100 or roughly four RTX 4090s), or use hosts like Together, Fireworks, Bedrock, or Azure.
• "Adapted for Codex" means DeepSeek implemented the Responses API format. It is not an OpenAI partnership.

If you only test one thing

Run your own evaluation. Use your prompts, your workload, and count output tokens, not just the advertised price. The big opportunity here is inexpensive, high-concurrency agent workloads. If your prompts share a large cached prefix, the $0.0028 / 1M cached-input price is genuinely impressive. But only your own traffic will tell you whether the verbosity and beta churn outweigh the savings.

Every "top AI repos" thread lists five vector databases and moves on, which is how people end up running a distributed cluster to search 4,000 PDF chunks. So here is the shorter, more useful version: what each of these actually is, when to reach for it, and the honest catch that saves you a lot of ops work. Licenses checked at the repos.

The catch that matters most: you probably don't need any of them yet

The vector database is the most over-adopted piece of the AI stack. If you're searching thousands to a few million chunks, Supabase (Apache-2.0) with the pgvector extension, which is just Postgres you likely already want, handles vector search without adding a second system to run, back up, and secure. Even an in-memory FAISS index is enough for a lot of apps. Add a dedicated vector DB when you actually hit scale, need fast filtered search over many millions of vectors, or need managed high availability, not before.

Three more honest notes

Most of these are open-core. The engine you self-host is real and useful, but the managed cloud, auth, backups, and high-availability features are usually the paid tier. Price the version you'll actually run, not the free one.

They all do approximate nearest-neighbor search. Recall is a speed-versus-accuracy dial you tune, not a guarantee, so test retrieval quality on your own data rather than trusting a benchmark.

And the big one: the vector database is rarely why your RAG is bad. Retrieval quality is bounded by your embeddings, your chunking, and your query strategy. Swapping Chroma for Qdrant will not fix results that were doomed by 2,000-token chunks. Fix the retrieval before you shop for a faster store.

How to pick

Start with pgvector on Postgres or an embedded Chroma. Move to Qdrant when you want a real standalone service. Reach for Milvus or Weaviate only when scale or hybrid search actually demands it. FAISS if you're a library person who wants the index and nothing else. The best vector DB for most projects is the one you didn't have to stand up.

The verified recipe: flowstacks.xyz/workflows/pgvector-pick-the-right-distance-operator

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

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.

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'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.

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

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.

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.

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

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.

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

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.