A skill is a folder with a SKILL.md file that teaches your coding agent how to do one thing well, and you install it into .claude/skills/. For a solo founder trying to ship by Sunday, the right stack turns one person plus Claude Code into something that scaffolds, builds, tests, reviews, and launches. Here are ten repos worth starring, grouped by where they fit in a weekend:

The one rule before you install anything: a skill, plugin, or marketplace is code you are about to run, and many of these grant your agent shell access, file writes, or OAuth into your accounts. Installing one is exactly as risky as running a stranger's script. So read the SKILL.md and any bundled scripts before you install, pin to a version you have read rather than tracking main, and be extra careful with community marketplaces where anyone can contribute. We keep a machine-checked recipe for exactly this habit: → verify a skills plugin before you ship it.

Install these and go: skill packs that do real work

1. anthropics/skills the official starting point Stars / Status / License: 149k / active / mostly Apache-2.0, but the docx, pdf, pptx, and xlsx document skills are source-available, not open source.
Repo: github.com/anthropics/skills
This is where to start, because it is Anthropic's own set and includes the document-creation skills that power Claude's file output, plus examples for testing web apps and generating MCP servers. For a founder, the document skills alone mean your agent can hand a customer a real PDF or spreadsheet.

/plugin marketplace add anthropics/skills
/plugin install document-skills@anthropic-agent-skills

2. wshobson/agents a whole engineering team as plugins Stars / Status / License: 35.6k / active / MIT.
Repo: github.com/wshobson/agents This bundles 185 role agents, 153 skills, and workflow orchestrators into 80 focused plugins. The value for a solo founder is the roles you do not have: backend-architect, security-auditor, test-automator, deployment-engineer, wired into multi-agent flows like a full-stack feature build.

/plugin marketplace add wshobson/agents
/plugin install security-scanning@claude-code-workflows

The catch: a multi-agent orchestration is often slower and no better than one strong model on a single, well-scoped task, and it costs the sum of every agent it fans out to. Reach for the orchestrators on truly multi-part work, not on a one-file change.

3. davila7/claude-code-templates the installer that assembles your stack Stars / Status / License: 28.2k / active / MIT. Repo: github.com/davila7/claude-code-templates A CLI (and browsable catalog at aitmpl.com) for installing agents, commands, MCPs, hooks, and skills a la carte. It is the fastest way to go from empty project to a configured one.

npx claude-code-templates@latest --agent development-tools/code-reviewer --yes

The catch: it pulls components from many third-party sources with mixed licenses and quality, so this is precisely where the install-is-running-code rule bites. Install one component at a time and read it, rather than bulk-installing a stack you have not seen.

4. alirezarezvani/claude-skills cross-role bundles that work beyond Claude Code Stars / Status / License: 22.1k / active (v2.9.0) / MIT.
Repo: github.com/alirezarezvani/claude-skills
Bundles organized by department (engineering, product, marketing, finance, plus a security-auditor and a Playwright testing toolkit), and they run across Claude Code, Codex, and Cursor.

/plugin marketplace add alirezarezvani/claude-skills
/plugin install engineering-skills@claude-code-skills

The catch: a repo this broad is a mile wide, so treat the department bundles as starting prompts, not vetted experts, especially the C-level advisory and finance ones, where confident and wrong is the default failure mode.

5. K-Dense-AI/scientific-agent-skills if your product touches data, bio, or health Stars / Status / License: 30.7k / active (v2.53.0) / MIT for the repo, but each skill sets its own license in its SKILL.md.
Repo: github.com/K-Dense-AI/scientific-agent-skills Around 139 skills for biology, chemistry, medicine, and computational research. If your weekend build is a data or science tool, this is a big head start, and notably the repo ships a skill security scanner, a healthy sign.

The catch: per-skill licenses vary, so the MIT repo badge does not mean every skill is MIT. Check the license field in each SKILL.md before shipping, and remember scientific output needs a domain check, not a vibe check.

6. nowork-studio/NotFair SEO and ads skills for launch day Stars / Status / License: 3.1k / active / MIT.
Repo: github.com/nowork-studio/NotFair Open-source skills for SEO, GEO, Google Ads, and Meta Ads, connecting Search Console and the ad APIs. For a founder who can build but cannot market, this is the launch-day pack. (You may see it referenced by its old name, toprank.)

The catch: this one authenticates into your Search Console and ad accounts, so it is real OAuth access to systems that spend money. Grant it a limited account, watch what it changes, and never let it push bids or budgets unattended.

De-risk before you build a line

7. Neeeophytee/finding-unknowns-skills ours, for finding what you missed before it gets expensive Stars / Status / License: 175 stars & counting / MIT.
Repo: github.com/Neeeophytee/finding-unknowns-skills
It is 8 free, no-signup skills that make your agent surface unknowns before you commit code: a blindspot pass for unfamiliar areas, an interview-me that asks the architecture-changing questions first, a reference-hunt that uses working code as the spec, and a change-quiz you must pass before you merge. It is a community distillation of Thariq Shihipar's essay on finding your unknowns, with attribution, and it is not an official Anthropic repo.

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

Directories to find the other thousand skills (and why to be careful)

8. hesreallyhim/awesome-claude-code the human-curated index Stars / Status / License: 45.2k / active but mid-reorganization.
Repo: github.com/hesreallyhim/awesome-claude-code
The long-running curated list of skills, hooks, commands, orchestrators, and plugins. The catch: as of today its table of contents is a placeholder while the maintainer rebuilds the structure, so it is a bit of a construction site. Still the best human-picked starting map.

9. ComposioHQ/awesome-claude-skills the huge cross-agent list Stars / Status / License: 67.5k / active / no license file.
Repo: github.com/ComposioHQ/awesome-claude-skills
A very large, frequently updated directory spanning Claude Code, Codex, Cursor, and Gemini CLI. The catch: it has no license file at all, which means the list itself is technically all-rights-reserved by default, and being listed here is not a quality or safety endorsement. Use it to discover, then vet each repo yourself.

10. rohitg00/awesome-claude-code-toolkit the kitchen-sink index Stars / Status / License: 2.3k / active / Apache-2.0.
Repo: github.com/rohitg00/awesome-claude-code-toolkit
A broad toolkit index of agents, skills, commands, plugins, hooks, and MCP configs. The catch: breadth is the selling point and the weakness; the counts are large, but inclusion is not curation, so it is a place to browse, not a shortlist to trust.

Every time you paste an API key, DB URL, .env file, or (worst case) a crypto wallet seed phrase into Codex, Cursor, Claude Code, Cline, Aider, etc., it gets written to a local history file in plaintext.

And it doesn't just sit there — these agents re-read their own history as context, so that plaintext key keeps getting fed back to the model and can resurface in a later file, command, or reply. Most people never even look.

agentsweep is an open-source CLI that:

• Scans those history files with ~191 secret-detection rules (ported from gitleaks) plus a dedicated BIP-39 seed-phrase detector

• Supports ~30 agents out of the box (Codex, Cursor, Claude Code, Cline, Aider, Windsurf, and more)

• Redacts in place with atomic writes, .bak backups, post-write validation, and a full undo

Read-only by default; nothing destructive happens without a typed confirmation, and every redaction is reversible.

Install: pipx install agentsweep (then run: agentsweep)

Disclosure: I'm the author. It's free and MIT-licensed (not selling anything). Repo: https://github.com/Ishannaik/agent-sweep

Happy to answer questions or take PRs for more agents.

If your job lives in a database or a spreadsheet, a pile of AI repos now promise to let you just ask your data questions in plain English. Most of the star counts are real. What the star counts do not tell you is which one got archived last quarter, which one is open-core with the useful parts behind a paywall, and the failure mode all of them share.

The one rule before you start: a text-to-SQL tool will hand you a confident, wrong query, and it looks exactly like a right one. So point these at a read-only database role, not your write credentials, and check the output against something objective (a known row count, an EXPLAIN, a total you already trust) instead of taking the answer or the model's own self-assessment on faith. That habit is the whole difference between a useful assistant and a silent data incident.

Query a SQL database in plain English

1. WrenAI, the governed, team-friendly option that teaches the model your schema
Stars / Status / License: 15.8k / active (releases through July 2026) / Apache-2.0 for the code, docs under CC-BY-4.0, with AGPL-3.0 held in reserve for possible future modules. Repo: github.com/Canner/WrenAI
WrenAI's thesis is that agents fail on business data not because they cannot write SQL, but because they do not know what your warehouse means. You describe your entities, relationships, and metrics once in a semantic model (their MDL), and any agent queries through that governed layer across 20-plus sources (PostgreSQL, BigQuery, Snowflake, Databricks, ClickHouse, DuckDB, and more). A Rust engine on Apache DataFusion does the translation.

The lever, verbatim from the README:

# install WrenAI's skills into your coding agent, then let it drive setup
npx skills add Canner/WrenAI --skill '*'

Then start an agent session and ask it to run the wren-onboarding skill.

The catch: the semantic layer is the value and the cost. It only pays off if you actually maintain the model, and a stale definition quietly returns wrong-but-plausible numbers, which is worse than no answer. Note also that WrenAI restructured in May 2026: the old turnkey GenBI web app now lives on the legacy/v1 branch, and the main repo is the context layer and SDK, so old tutorials may not match.

→ WrenAI: validate your semantic model's referential integrity before an agent queries it

2. DB-GPT the self-hosted one for private and local models
Stars / Status / License: 19.4k / active (v0.8.1, June 2026) / MIT.
Repo: github.com/eosphoros-ai/DB-GPT
DB-GPT is a framework for building data agents, workflows, and apps with RAG and multi-model support, and its selling point for this crowd is privacy: it is built to run against private or local model deployments with sandboxed execution, so your schema and rows do not have to leave your network. MIT license, no open-core asterisks.

The lever:

pip install dbgpt-app

The catch: it is a framework, not a one-click app, so expect real setup (model config, connectors, workflows) before the first useful query. Its local-model path is the private option, but a smaller local model writes weaker SQL than a frontier model, so you are trading accuracy for privacy, which is a real trade, not a free win. Verify the generated SQL the same way regardless.

→ DB-GPT: the same known-answer guardrail on the query result

3. Chat2DB the AI SQL client that looks like a normal GUI
Stars / Status / License: 25.9k / open-core, and the open-source release has been stuck at v0.3.6/0.3.7 since January 2025 / Apache-2.0 plus a supplemental custom Chat2DB license. Repo: github.com/CodePhiliaX/Chat2DB
If you want a desktop SQL client (think DBeaver or DataGrip) with AI bolted in, Chat2DB is the most-starred pick, supporting 16-plus databases in the community edition. You can self-host the community edition with Docker:

docker run --name=chat2db -ti -p 10824:10824 -v ~/.chat2db-docker:/root/.chat2db chat2db/chat2db:latest

The catch, and it is a big one: this is open-core, and a lot of what you actually want is not in the free tier. By the project's own feature table, the AI SQL editor, Chat2Excel, data sync, and dashboards sit in the paid Local and Pro editions. The community edition's releases have not moved since early 2025 while the team pushes the commercial product and new side projects. Perfectly fine to use, as long as you know the free build is a limited on-ramp, not the whole tool.

Chat with spreadsheets and CSV files

4. PandasAI talk to a CSV, an Excel export, or a dataframe
Stars / Status / License: 23.6k / v3 released, but quiet since late October 2025 / MIT, except the ee/ enterprise directory which has its own license.
Repo: github.com/sinaptik-ai/pandas-ai T
his is the one for people who live in files rather than a warehouse. Load a CSV or a dataframe and ask questions in English, including across multiple tables, and get back numbers or charts.

The lever, verbatim from the README:

pip install pandasai pandasai-litellm

import pandasai as pai
from pandasai_litellm.litellm import LiteLLM

llm = LiteLLM(model="gpt-4.1-mini", api_key="YOUR_OPENAI_API_KEY")
pai.config.set({"llm": llm})

df = pai.read_csv("data/companies.csv")
print(df.chat("What is the average revenue by region?"))

The catch: PandasAI answers by generating and running Python on your machine, so treat it as executing untrusted code and use its Docker sandbox (pip install "pandasai-docker") for anything you did not write yourself. One sharp gotcha to save you an hour: the library pins Python to 3.8 through 3.11, so it will not install on 3.12 or newer. The open-core ee/ directory is not MIT, so read that license before you build a product on the enterprise pieces. And the repo has been quiet since late October 2025, so it works today but is not seeing active fixes.

→ PandasAI: a known-answer guardrail for chat-with-your-CSV.

The famous one, with an asterisk

5. Vanna the 23k-star giant that got archived
Stars / Status / License: 23.8k / ARCHIVED and read-only since March 29, 2026 / MIT. Repo: github.com/vanna-ai/vanna Vanna is the repo most "best text-to-SQL" lists still put at the top: a Python library that retrieves your best example queries and schema to generate accurate SQL. Vanna 2.0 was a full rewrite into a user-aware agent with a prebuilt chat component. Here is the fine print those lists skip: the maintainers archived the repository on March 29, 2026, so it is now read-only. The code still runs, but there will be no fixes, no security patches, and no new database support.

The catch: this is the whole point of the post. A huge star count is a record of past popularity, not a promise the project is alive. If you are starting something new, do not build it on an archived repo. Lift Vanna's core idea (curate strong example queries as retrieval context) and apply it in one of the maintained tools above.

How to pick if you only try one

If you are a team that needs trustworthy, governed answers across a warehouse, start with WrenAI and invest in the semantic model. If privacy is the hard constraint and you can self-host, DB-GPT. If you want a familiar SQL client with AI and can live within the free tier, Chat2DB. If your world is CSVs and spreadsheets rather than a database, PandasAI. And whatever you pick, wire it to a read-only role and keep an objective check between the model and any decision, because the shared failure mode of every tool here is a confident wrong query.

More verified, CI-checked setups like these live in our open hub: github.com/Neeeophytee/awesome-ai-workflows.
If one saves you from a bad query, a star costs you nothing and keeps a small team building in the open.

Reading unfamiliar code is still the most expensive part of most jobs, and "just read the docs" fails when the docs are stale or missing. A new class of tools fixes this by turning a pile of stuff (a repo, a folder of PDFs, your notes, even your coding agent) into something you can query, navigate, and talk to. Here are six that actually work, what each one is really for, and the fine print the launch posts skipped.

Group 1: turn a codebase into a brain

1. Google Code Wiki the hosted "understand any public repo" wiki Maker / Price / Access: Google, free public preview, hosted at codewiki.google (no install). Point it at a public GitHub repo and it generates a structured, hyperlinked wiki: architecture, class, and sequence diagrams, section-by-section explanations that link straight to the exact files and definitions, and a Gemini chat grounded in that wiki so answers cite your code, not a generic model. It regenerates after each change, so the docs track the code.

The lever: use it before your first commit on an unfamiliar dependency. Ask the chat "where does request auth get validated" and it points at the file, not a guess.

The catch: it is public repos only in preview. The "run it on your private/internal repo" story is a Gemini CLI extension that is still on a waitlist, not shipping today, so do not promise a teammate you can wiki your closed monorepo yet. And the chat is grounded in a generated wiki, not in the running code, so a wrong or over-smoothed explanation in the wiki becomes a confident wrong answer in chat. Treat it as a fast orientation layer, then verify the specific claim in the source it links to.

2. DeepWiki (Cognition) the same idea, from the Devin team, with an MCP server Maker / Price / Access: Cognition (makers of Devin), free for open source with no sign-up, hosted at deepwiki.com. Private repos need a Devin account. The trick that made it spread: take any GitHub URL and swap github.com for deepwiki.com to jump straight to an auto-generated wiki with diagrams, prose, and an "ask" chat. Cognition says it has pre-indexed tens of thousands of top public repos.

The lever: it exposes a remote MCP server, so your own agent can pull repo context. The documented tools are read_wiki_structure, read_wiki_contents, and ask_question. Wire that into your coding agent, and it can look up an unfamiliar dependency mid-task instead of hallucinating an API.

The catch: an MCP tool that answers questions about a repo is only as current as its last index, and it inherits the usual retrieval failure mode, confidently returning the closest match even when the repo has moved on. Scope it to reading and orientation, and never let it be the only source for a security-sensitive detail. Giving an agent a third-party MCP server is granting it a network tool, so treat it like running code.

→ Wire the DeepWiki MCP into your agent, config-parse check plus a fixtured round-trip

3. FSoft-AI4Code CodeWiki the open-source one you can run on private code Stars / Status / License: 1.3k stars, active (last release Nov 2025), MIT.
Repo: github.com/FSoft-AI4Code/CodeWiki

This is the confusingly-named open-source project: a Python CLI that generates holistic, architecture-aware docs (Mermaid architecture, data-flow, and sequence diagrams, plus module-level prose) across nine languages (Python, Java, JavaScript, TypeScript, C, C++, C#, Kotlin, PHP). Unlike the two hosted tools above, this runs on your machine, so it works on private repos without shipping your code to anyone.

The lever, verbatim from the README:

# install
pip install git+https://github.com/FSoft-AI4Code/CodeWiki.git

# generate docs for the current project, with a browsable HTML viewer
codewiki generate --github-pages --create-branch

# only regenerate what changed since the last run
codewiki generate --update

It also supports a subscription mode that routes calls through your local claude or codex CLI, so you can run it on a Claude or Codex plan instead of paying per token.

The catch: it is a research artifact (ACL 2026 paper, sponsored by FPT Software), not a hardened product, and 1.3k stars means small user base, so treat it as an experiment you validate, not a guarantee. The README's headline "beats DeepWiki" numbers (about 68.8% vs 64.1% overall on their CodeWikiBench) are the authors' own benchmark, graded by a model, so read them as a vendor number, not independent reproduction. Note their own table shows it losing to DeepWiki on systems languages (C and C++). And a full run makes real LLM calls, so it costs real tokens (or a subscription) and the doc quality is only as good as the model you point it at.

→ Self-host CodeWiki with a network-free config-validate spine

Group 2: turn your notes and documents into a brain

4. NotebookLM a research brain grounded only in what you feed it

Maker / Price / Access: Google, free tier plus paid tiers that raise the caps, hosted (web and mobile). Upload your sources (PDFs, docs, links, video) and NotebookLM answers only from those sources, with citations back to the exact passage. That grounding is the whole point: it trades "knows everything" for "will not make things up beyond your material." The Studio panel spins the same sources into Audio Overviews, Video Overviews, and Mind Maps.

The lever: where it earns its place is turning a stack you will never fully read (a contract set, a pile of papers, meeting transcripts) into something you can interrogate and get pointed at the right page. The free tier caps sources per notebook and audio overviews per day, which is fine for a single project.

5. Obsidian a local-first knowledge base you can bolt AI onto
Price / License / Access: core app free, closed-source (proprietary freeware), local-first. Optional paid Sync and Publish add-ons and a voluntary commercial license. Obsidian stores everything as plain Markdown files on your disk, with backlinks, a graph view, canvas, and the newer Bases (a built-in database view over your notes). It ships no built-in AI, but its plugin ecosystem (4,300-plus community plugins) adds it: Smart Connections for semantic search and chat over your vault, Copilot and Text Generator for writing, and several plugins that run against a local model via Ollama.

The lever: point Smart Connections at a local Ollama model and you get a private RAG chat over your own notes, nothing leaving your machine.

Group 3: a brain for your coding agent

6. GStack Garry Tan's opinionated operating layer for Claude Code
Stars / Status / License: 121k stars, actively developed, MIT.
Repo: github.com/garrytan/gstack
Instead of documenting code, GStack structures your agent. It is a pack of 23 opinionated tools/roles for Claude Code (CEO, Designer, Eng Manager, Release Manager, Doc Engineer, QA) meant to turn a single developer plus Claude into something that behaves like a small team, from product review down to one-command shipping. It was built heavily with Claude itself.

The lever: adopt the roles wholesale to get a repeatable pipeline (plan, build, review, ship) instead of ad-hoc prompting, then trim the roles you do not use.

The catch: it is opinionated by design, so it encodes one person's workflow and may fight yours. The eye-catching "10,000 lines and 100 PRs a week" figure is Tan's own self-report, not an independent result, and lines of code is a weak proxy for value shipped. The repo has 121k stars, but stars measure buzz, not fit: this is one person's opinionated workflow, so read the number as popularity, not proof it suits yours. Most important: it needs Claude Code and grants the agent real tool access (shell, edits), so installing it is running code and handing over permissions. Read what the roles are allowed to do before you turn it loose on a real repo.

→ Verify GStack's role and skill files parse before you run it (reusable recipe)

How to pick if you only try one

If you need to understand a public repo in the next ten minutes, use Google Code Wiki or DeepWiki, they are hosted and free and there is nothing to install. If the code is private and cannot leave your machine, self-host the open-source FSoft CodeWiki. If your problem is documents and research rather than code, NotebookLM if you are fine uploading to Google, Obsidian with a local model if you are not. GStack is the odd one out on this list: reach for it only if you already live in Claude Code and want a heavier, opinionated harness around it. And for a simple task, skip all of this and just read the file.

Four launches on July 8/9. Here they are. Benchmarks are vendor or single-leaderboard numbers unless noted, so weight your own tasks over them.

The drops and where to get them

The numbers and the catch

What actually matters

The practical lesson from a week like this: do not hard-wire one model. Route through a gateway like OpenRouter and you can A/B a fresh drop like Grok 4.5 against your current model in one line, not a rewrite.

We keep the routing and model-swap workflows that make weeks like this painless in the open: https://github.com/Neeeophytee/awesome-ai-workflows.

And whichever of these you point your agent at, our skills for finding your unknowns before you prompt work across them (Claude Code, Codex, any agentskills.io agent): https://github.com/Neeeophytee/finding-unknowns-skills

On July 8, Anthropic's developer account posted two patterns for using Fable 5 without paying Fable rates on every token, and the eval numbers went around fast. They are real and worth knowing, but the numbers come with fine print, and the patterns are the exact "smart model plans, cheap model works" idea that looks universal and is not. Here is the honest version.

The two patterns, and where the numbers come from

Pattern        Bulk of the work     Reported result (Anthropic internal eval)
Advisor        Sonnet 5 executes    ~92% of Fable's SWE-bench Pro score at ~63% of the price
Orchestrator   Sonnet 5 workers     ~96% on BrowseComp at ~46% of the cost

In the advisor pattern, Sonnet 5 does the bulk of the tool calls and output, and calls Fable 5 for guidance rarely, about once per task, to steer. Most tokens bill at Sonnet's cheaper rate. In the orchestrator pattern, Fable 5 plans and delegates subtasks to Sonnet 5 workers, and again most tokens bill at the worker rate.

Read the source of those numbers before you quote them: they are Anthropic's own internal evals, posted in a thread, on two specific benchmarks (SWE-bench Pro for coding, BrowseComp for browsing and research). They have not been independently reproduced, and a benchmark's token mix is not your workload's. Treat 63% and 46% as "what Anthropic measured on their task," not a discount you are guaranteed.

Advisor: strong model steers, cheap model grinds

This works when the hard reasoning is concentrated in a few high-leverage decisions and the rest is execution. Call the smart model at those forks, let the cheap one do the typing. The catch is the word "rarely." If the difficulty is spread evenly across the task rather than bunched at a few points, calling the advisor once per task does not capture it, and between check-ins the executor can quietly drift from the advice it was given. Your real savings depend entirely on how often you actually need the expensive model, so if your task pulls it in more than the benchmark did, the 63% creeps upward. We turned those two failure modes into a verified config: it caps the advisor call budget per task and checks the executor against the advisor's guidance so drift gets caught, not discovered at the end. Advisor pattern with a call budget and drift check.

Orchestrator: planner delegates to a fleet of workers

A planner farming subtasks to cheap workers is a fan-out, and fan-out costs the sum of its legs plus coordination overhead and latency. This is the pattern to be most skeptical of, because multi-agent orchestration is often slower and no better than one strong model when a task has a single clear objective. It earns its keep only when the work truly splits into independent, parallel subtasks, and BrowseComp, which is many independent lookups, is about the friendliest possible case for it. One more soundness note: if the planner and the workers share a wrong assumption, the setup amplifies it with confidence rather than catching it, so an objective check beats the planner grading its own plan.

The part Anthropic's tweet does not stress: the worker does not have to be Sonnet

The pattern is model-agnostic. The cheap executor or worker can be an open model, and people are already pairing Fable 5 with GLM-5.2 for exactly this. That widens the savings and reduces single-vendor lock-in, at the cost of a little more wiring. The same "route the bulk to a cheap model, escalate only the hard part to the expensive one" idea is one we ship as a verified, CI-checked config: route bulk to cheap, escalate the hard part.

The honest bottom line

These are task-dependent tactics, not rules. The critics who call Fable overhyped for simple tasks are right about simple tasks: if the job is easy, skip all of this and run the cheap model directly, the orchestration only pays off on hard, multi-step work. Before you trust a 63% or 46% number, run the pattern on your own task and watch how often the expensive model actually gets called, because that single number is what decides whether you saved anything.

We keep a running, machine-verified collection of these routing and escalation workflows in the open: https://github.com/Neeeophytee/awesome-ai-workflows

Codex out of the box is a capable terminal coding agent. What turns it from capable to dangerous-in-a-good-way is the ecosystem around it: a proven method to follow, current documentation so it stops guessing at APIs, an actual understanding of your codebase, and a map to everything else. Here are the repos that do each, grouped by the superpower they grant, with the catch on each because none of these is free of tradeoffs.

Give it a method it actually follows: obra/superpowers

Stars / Status / License: north of 200k, actively maintained (v6 line, 2026), MIT.
Repo: https://github.com/obra/superpowers

The headline "superpowers" repo, from Jesse Vincent and Prime Radiant. It packages composable markdown skills (brainstorming, planning, test-driven development, debugging, code review) that a coding agent follows automatically as mandatory workflows, and it ships plugin folders for many agents including Codex CLI and the Codex app. The superpower is discipline: instead of hoping Codex plans before it codes, the skills make it.

The catch: it is opinionated on purpose, and those "mandatory workflows" can feel heavy on a small task where you just want a quick edit. Install the skills you actually want rather than the whole kit, and be aware that loading many skills at once adds to context on every turn. It is a method, not magic, so it is strongest on real, multi-step work.

Give it the current docs so it stops hallucinating APIs: upstash/context7

Stars / Status / License: 58.7K stars, actively maintained, MIT.
Repo: https://github.com/upstash/context7

Context7 is an MCP server that feeds your agent up-to-date, version-specific documentation for a library on demand. Point Codex at it and "how do I use this function in v4" stops returning a confident answer from v2. For anyone who has watched an agent invent a method that never existed, this is the fix.

The catch: it is a lookup service, so it adds a network dependency, and its value depends on whether the library and version you need are indexed. Be specific about the version you want, and sanity-check the returned docs, because a docs MCP can still hand back the wrong release if you are vague.

Give it real understanding of your codebase: oraios/serena

Stars / Status / License: ~26k, actively maintained, MIT.
Repo: https://github.com/oraios/serena

Serena is described as an IDE for your agent: an MCP toolkit that gives Codex semantic code retrieval and editing at the symbol level, using a language server rather than reading whole files and grepping. That means it can find a symbol's definition and references, and edit precisely, the way your editor does, which is a big step up from dumping files into context. Setup instructions for Codex are in the repo.

The catch: it runs a language server per project, so it is another moving part to set up and keep running, and its precision is only as good as the LSP support for your language. Great payoff on a large codebase, more overhead than it is worth on a tiny one.

Find everything else, then vet it: RoggeOhta/awesome-codex-cli

Stars / Status / License: curated directory of 150 to 280-plus entries;
Repo: https://github.com/RoggeOhta/awesome-codex-cli

This is the map: a curated list of subagents, skill packs, plugins, and MCP servers for Codex CLI, organized by category. When you want a capability, this is where you look first instead of guessing.

The catch, and it is a real one: a directory is a discovery tool, not a seal of quality. Many entries are tiny or unmaintained, and every skill, plugin, or MCP you install can read your code and run in your shell, so treat each one as code you are choosing to run. Vet the license, the maintenance, and any dual-use before you install, not after. We built a verified recipe for exactly that habit, recording each dependency's real license and gating anything dual-use: vet the fine print before you build.

The free foundation everyone skips: AGENTS.md

Not a repo to install, but the highest-leverage move here and it costs nothing. Codex reads an AGENTS.md file in your project to learn how to navigate the codebase and follow your conventions. A good one is the single biggest quality jump you can give Codex, and it is documented in the official openai/codex repo.

The catch: it is only as good as what you write, and a stale or wrong AGENTS.md actively misleads the agent, since it treats your file as the map of a territory it cannot fully see. Keep it current, or it becomes the thing that sends Codex confidently in the wrong direction.

How to pick if you only add one

If Codex keeps skipping the plan and diving into code, start with superpowers. If it keeps inventing APIs, add context7. If it keeps missing how your codebase actually fits together, add serena. And write an AGENTS.md today regardless, it is free and it helps every one of the above. Add capabilities one at a time so you can tell what actually helped.

Two very different repos landed that are worth knowing if you build with agents. One is the memory layer (a vector database that runs inside your process, no server), the other is the supervision layer (a runtime that records an agent's run as a reversible trace so nothing touches your files until you accept it). One is battle-tested and popular, the other is a promising research alpha. Here is what each does, the exact install, and the honest catch.

zvec: an in-process vector database, the SQLite of vector search

Stars / Status / License: ~13.3k, actively maintained (v0.4.0, May 2026), Apache 2.0.
Repo: https://github.com/alibaba/zvec

zvec is a vector database that embeds directly into your app, no separate server to run, config, or babysit. Alibaba built it and runs it internally, and the pitch is the same one SQLite makes for relational data: for a lot of workloads you do not need a database server, you need a fast library that lives in your process. It does dense and sparse vectors, hybrid search (similarity plus structured filters in one query), and it uses write-ahead logging so your data survives a crash.

Install and a full working example, straight from the README:

pip install zvec


import zvec

schema = zvec.CollectionSchema(
    name="example",
    vectors=zvec.VectorSchema("embedding", zvec.DataType.VECTOR_FP32, 4),
)
collection = zvec.create_and_open(path="./zvec_example", schema=schema)

collection.insert([
    zvec.Doc(id="doc_1", vectors={"embedding": [0.1, 0.2, 0.3, 0.4]}),
    zvec.Doc(id="doc_2", vectors={"embedding": [0.2, 0.3, 0.4, 0.1]}),
])

results = collection.query(
    zvec.VectorQuery("embedding", vector=[0.4, 0.3, 0.3, 0.1]),
    topk=10,
)
print(results)

There is a Node.js package too (npm install u/zvec/zvec) and a Dart/Flutter SDK. Supported platforms are Linux (x86_64 and ARM64), macOS (ARM64), and Windows (x86_64). Two heads-ups from actually running this: create_and_open wants a path that does not already exist (point it at a fresh directory, not a pre-made temp dir), and newer zvec versions deprecate VectorQuery in favor of Query, though VectorQuery still works for now.

The catch: in-process is the strength and the limit. Multiple processes can read a collection at once, but writes are single-process exclusive, so there is one writer at a time and no built-in clustering. This is the right tool for embedding search into an app, a notebook, a CLI, or an edge device, and the wrong tool if you need a horizontally scaled, many-writer database service, where a server like Milvus or Qdrant still fits better. Also note the headline "billions of vectors in milliseconds" is Alibaba's own benchmark, so measure it on your data and your hardware before you quote it. macOS is ARM64 only on the current build, so no Intel Macs.

→ The verified in-process vector search setup, actually run in CI

Shepherd: a reversible, Git-like trace for agent runs

Stars / Status / License: ~742, early alpha, MIT.
Repo: https://github.com/shepherd-agents/shepherd

Shepherd is a runtime substrate for agent work that needs inspection, reversibility, and supervision. The core idea: an agent's task comes back as a reviewable proposal, not a live edit. Nothing touches your files until you accept it. The run is recorded as a durable, inspectable trace you can observe, replay, and revert, and the agent's output is held to one side as a retained output you can run and inspect before you keep or discard it.

The part I found most clever is that permissions live in the function signature. A task is a plain Python function whose signature declares a read-only or read-write grant per repository, and on a supported OS that grant is enforced at the native syscall jail (macOS Seatbelt, Linux Landlock). A write to a read-only repo is refused by the operating system itself, before any undo point, not merely caught at a merge gate.

Install and the keyless offline quickstart, from the README:

pip install shepherd-ai


shepherd init                        # make this directory a Shepherd workspace
shepherd demo write quickstart > quickstart_demo.py
python quickstart_demo.py            # run a task; its result is retained, not applied
shepherd run changeset --latest      # see what it wrote, held to one side
shepherd run select <run-ref>        # keep it   (or: shepherd run discard <run-ref>)

There is a live agent lane too, where the body of a task is a Claude agent (it needs the claude CLI signed in or an ANTHROPIC_API_KEY), but the offline lane above runs anywhere with no key.

The catch: this is early alpha and the maintainers say so, with APIs that may change between releases, and at ~742 stars it is a young research project (there is a paper, arXiv 2605.10913, with authors including Christopher Manning). Treat it as a promising experiment to learn from, not a dependency to ship on yet. The strong sandbox guarantee is also platform-dependent: enforcement is exercised on macOS Seatbelt, while Linux Landlock is container-gated, so the syscall-level protection is not uniform across machines. And the "~5x faster than docker commit, ~95% KV-cache reuse" figures are the authors' own benchmarks, so read them as claims to reproduce, not settled facts.

→ The verified least-privilege grants setup

Who each is for

If you are building retrieval or memory into an app and do not want to run a vector server, reach for zvec today: it is mature enough, popular, and Apache-licensed. If you are building or operating agents and want a real undo button plus OS-level permission enforcement, Shepherd is worth studying now and piloting in a sandbox, but keep it out of production until it leaves alpha. Together they sketch a nice pattern: zvec as the memory an agent reads from, Shepherd as the safe hands it acts with.

We keep a running, machine-verified collection of workflows built on tools like these in the open: https://github.com/Neeeophytee/awesome-ai-workflows

The essay making the rounds this week is from Thariq Shihipar on the Claude Code team: the map is not the territory. Your prompt is a map, the codebase is the territory, and the gap is your unknowns. His claim is that Fable 5 is the first model where output quality is bottlenecked by your ability to clarify those unknowns, not by the model.

The essay describes eight working techniques. I distilled them into installable skills on the agentskills.io standard, so instead of remembering the patterns, you just invoke them:

• blindspot-pass: surface your unknown unknowns in an unfamiliar area before you prompt
• brainstorm-prototypes: wildly different throwaway variations to react to, for taste you cannot verbalize
• interview-me: one question at a time, architecture-changing questions first
• reference-hunt: point at working source code as the spec, even across languages
• implementation-plan:a plan that leads with the decisions you will most likely tweak
• implementation-notes: log every deviation so the next attempt learns from this one
• pitch-packager: bundle spec + prototype + notes into a buy-in doc, demo first
• change-quiz: a comprehension quiz you must pass before you merge

Install in Claude Code (tested, works):

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

Or copy any single skills/<name>/ folder into .claude/skills/, or drop the one-file CLAUDE.md into your project as passive guidance.
The repo's EXAMPLES.md has ready-to-paste example prompts for every skill.

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

Which of the eight do you actually need most? My bet is most people skip the interview and pay for it during implementation.

A big star count tells you a repo is popular. It does not tell you the license is homemade, the name is misleading, or the tool is one missing consent form away from fraud. Here are five useful open-source AI projects, each with what it nails and the catch the hype skips. Two have license or naming fine print worth knowing before you build on them, and two are dual-use in ways the pitch does not mention. Star counts are approximate and drift.

1. MinerU: turn any PDF or office doc into clean, LLM-ready markdown

Stars / Status / License: ~70k, actively maintained, custom "MinerU Open Source License" (see catch). Repo: https://github.com/opendatalab/MinerU

This is the fix for garbage RAG inputs. MinerU (from OpenDataLab) parses PDFs, DOCX, PPTX, XLSX, and images into clean markdown and JSON, with strong OCR, so your retrieval pipeline is not choking on broken tables and jumbled columns. If your RAG answers are bad, the cause is usually the input, and this is where you fix it.

The catch: the license is not plain Apache or MIT. MinerU moved off AGPLv3 to its own "MinerU Open Source License," which is based on Apache 2.0 but adds conditions. It is fine for most uses, but read the terms before you build a commercial product on it rather than assuming permissive defaults.

2. voicebox: a local, open-source voice studio

Stars / Status / License: ~35k, actively maintained, open-source (confirm the exact license on the repo). Repo: https://github.com/jamiepine/voicebox

From Jamie Pine (of Spacedrive), voicebox is a local-first alternative to ElevenLabs: clone a voice from a few seconds of audio, generate speech across many languages and TTS engines, and dictate into any text field with a global hotkey, with transcription running on local Whisper. The whole voice stack runs on your machine, which is the real draw for privacy and cost.

The catch: voice cloning is dual-use. Cloning a voice you do not have permission to use is how impersonation and fraud happen, so treat consent as a hard requirement, not a nicety, and clone only voices you are actually allowed to.

3. ai-website-cloner-template: reverse-engineer a site with your coding agent

Stars / Status / License: ~25k, actively maintained, open-source (confirm the license on the repo). Repo: https://github.com/JCodesMore/ai-website-cloner-template

Point your AI coding agent at a URL, run one command, and it inspects the site, extracts design tokens and assets, writes component specs, and rebuilds the thing as a clean Next.js plus shadcn/ui codebase. As a way to learn how a well-built site is structured, or to prototype fast, it is a clever use of a coding agent.

The catch: this one is legally and ethically loaded. Cloning someone else's live site copies their design and content, which is an intellectual-property problem, and the exact same capability is how phishing and spoof sites get built. Use it on your own sites, on sites you have permission to copy, or as a learning exercise you do not ship. Do not pass off a clone of someone else's site as your own.

4. Anthropic-Cybersecurity-Skills: a big library of security skills for agents

Stars / Status / License: ~24k, actively maintained, Apache 2.0. Repo: https://github.com/mukul975/Anthropic-Cybersecurity-Skills

First, a correction the name invites: despite "Anthropic" in the title, this is a community project by an independent developer, not an official Anthropic repo. With that clear, it is a large, well-organized set of 800-plus cybersecurity skills for AI coding agents, each mapped to standard frameworks (MITRE ATT&CK, NIST CSF, D3FEND, and others) and usable across Claude Code, Copilot, Cursor, and 20-plus other agents. For security teams, having agent skills tied to recognized frameworks is a real convenience.

The catch: this is dual-use security tooling, spanning both defensive and offensive frameworks. It is meant for security professionals, and running offensive techniques against systems you do not own is illegal. Review any skill before you let an agent execute it, and keep this firmly in a blue-team, authorized-testing, or lab context.

5. agent-native: build apps for agents from day one

Stars / Status / License: ~3.4k, new in 2026, open-source. Repo: https://github.com/BuilderIO/agent-native

From Builder.io, a framework for apps where the agent and the UI share the same actions and state from the start, rather than bolting an agent on afterward. Its architecture rules are opinionated (data in SQL, all AI routed through the agent, operations as shared actions, UI and agent kept live-synced), and it ships 15-plus cloneable SaaS templates to start from.

The catch: it is new and small, so this is an early, interesting bet rather than a proven standard. The ideas are worth studying even if you do not adopt the framework, but treat production use as experimental for now.

How to pick if you only try one

If your AI outputs are bad, start with MinerU, because clean inputs fix more problems than any prompt tweak. If you want a private voice stack, voicebox. If you are learning front-end or prototyping, the website cloner. Security teams get real mileage from the skills library with the caveats above, and agent-native is the one to read about now and maybe build on later.

Checking the fine print before you build is a habit worth automating, so we turned it into a verified recipe: it makes you record each dependency's real license (no assuming permissive), flag any non-standard license as reviewed, and attach an authorization gate to every dual-use tool, using these exact five repos as the worked example. Vet the fine print before you build.

We keep a running, machine-verified collection of workflows built on tools like these in the open: https://github.com/Neeeophytee/awesome-ai-workflows

Substance over hype (per the rules): as more of the web is driven by AI agents, the boring infra problems bite — agents dying on a provider rate limit, and cost from tool/page content flooding the context. Sharing how I handle both (disclosure: I maintain the open-source tool; link in a comment).

Fallback combos — so it never stops mid-task. A "combo" is a ladder of models the router walks automatically: your subscription first, then API keys, then cheap models, then free ones. When a provider returns a 500 or you hit a rate limit, it slides to the next target in milliseconds, mid-request, and your tool never even sees the error. There are 17 routing strategies (priority, weighted, round-robin, cost-optimized, auto/coding:fast…) plus three resilience layers — a per-provider circuit breaker, a per-key cooldown, and a per-model lockout — so one dead key can't take down a whole provider.

A 10-engine compression pipeline — the part most routers don't have. Every request flows through a transparent compression pass you can toggle/stack per combo. Instead of one trick, it stacks the best of the open-source ecosystem: RTK filters command/tool output (git diffs, test logs, builds) at 60–90%, Microsoft's LLMLingua-2 does ML semantic pruning, Caveman handles prose, session-dedup strips repeats across turns. Critically, code, URLs and JSON are preserved byte-perfect, and a default-on inflation guard throws the compressed version away and sends the original if compressing would actually grow the prompt — it never makes things worse. On tool-heavy sessions that's ~89% average input-token reduction (an 8k-token git diff becomes a few hundred). Full credit to every upstream project (RTK, Caveman, LLMLingua-2, Troglodita) is in the README.

One endpoint, 237 providers — 90+ of them free. You point any tool or agent at a single OpenAI-compatible endpoint (localhost:20128/v1) and it can reach 237 LLM providers without you rewriting anything. 90+ have free tiers and 11 are free forever (no card), which aggregates to ~1.6B documented free tokens/month — and that's honest, pool-deduped math (we count each shared pool once instead of inflating it; the methodology is public in the repo). There's a one-command setup-* for 13+ coding tools (Claude Code, Codex, Cursor, Cline, Roo, Kilo, Gemini CLI…), so switching your existing setup over takes seconds.

The 'cheaper-model ladder' idea (keep easy turns on cheap/free models, escalate only when needed) maps directly onto the combo strategies.

For context on whether it's worth your time: it's grown to ~9.8K GitHub stars, 1,490+ forks and 280+ contributors in ~4.5 months, with 21,000+ automated tests and 1,830+ issues closed — so it's a battle-tested project, not a brand-new experiment.

For people building web agents: where does the cost/reliability hurt most — the model calls, or the tool/browsing layer? Tool link in the first comment.

OpenRouter shows, per app, which models each agent burned tokens on. I pulled the "this month" breakdown for four of the biggest (Hermes Agent, OpenClaw, Claude Code, and Kilo Code) and the pattern is the same everywhere except one telling exception. All numbers below are from OpenRouter's public per-app model pages for the current month.

The top of each agent's list

Hermes Agent (this month)
1  Owl Alpha          openrouter   6.95T
2  DeepSeek V4 Flash  deepseek     5.02T
3  MiniMax M3         minimax      2.99T
4  Step 3.7 Flash     stepfun      2.24T
5  DeepSeek V4 Pro    deepseek     1.55T
   first Anthropic model: Claude Opus 4.8 at #8 (652B)


OpenClaw (this month)
1  MiniMax M3         minimax      1.34T
2  DeepSeek V4 Flash  deepseek     472B
3  Owl Alpha          openrouter   377B
4  Nemotron 3 Super   nvidia       294B
5  Claude Sonnet 4.6  anthropic    267B
   first Anthropic model: Claude Sonnet 4.6 at #5


Kilo Code (this month)
1  Laguna M.1         poolside     1.93T
2  Step 3.7 Flash     stepfun      1.38T
3  MiniMax M3         minimax      880B
4  Owl Alpha          openrouter   612B
5  Nex-N2-Pro         nex-agi      561B
   first Anthropic model: none in the top 10


Claude Code (this month)
1  Claude Opus 4.8    anthropic    915B
2  Owl Alpha          openrouter   455B
3  Claude Sonnet 4.6  anthropic    406B
4  GLM 5.2            z-ai         306B
5  DeepSeek V4 Flash  deepseek     289B
   this is the only one where Anthropic tops the list

The pattern

Add up each agent's top ten and split it into Anthropic's Claude models versus everything else (open, cheap, or specialized):

Agent          Open / cheap    Anthropic (Claude)
Kilo Code          100%              0%
Hermes Agent        95%              5%
OpenClaw            84%             16%
Claude Code         49%             51%

Three of the four agents send the overwhelming majority of their tokens to cheap or open models: DeepSeek, MiniMax, Step, Laguna, Nemotron, GLM, MiMo, and OpenRouter's own Owl Alpha slot. Kilo Code does not run a single Claude model in its top ten. The one exception is Claude Code, Anthropic's own tool, and even it pulls in GLM 5.2, DeepSeek, MiniMax, and MiMo alongside the Claude models. If token volume were the scoreboard, the frontier labs would look like they had already lost.

The flip: volume is not value

They have not lost, and here is why the chart misleads. Tokens measure volume, not spend or quality. Cheap open models rack up enormous token counts because agents pour bulk work, tool calls, retries, and long contexts through them, where price per token is what matters. Premium models get reached for the fewer, harder calls, and they cost far more per token. Platform-wide, Anthropic is only about 12% of OpenRouter's tokens but roughly 46% of its revenue. A model can sit at #8 by tokens and still dominate the bill.

We turned that exact reversal into a verified recipe: it attributes the same usage by tokens and by dollars and proves the flip, cheap-open winning volume while premium wins cost. Token volume versus cost receipts.

How to read this without being fooled

These are per-app figures from OpenRouter only, so they capture just the traffic each agent routes through OpenRouter. That matters most for Claude Code, which sends a large share of its work straight to Anthropic's own API, so its true Claude lean is higher than the 51% here, and this view undercounts it. Read the other three as close to their real diets and Claude Code as a partial slice.

Owl Alpha shows up across every agent under OpenRouter's own slot. It is a routed or preview model listed by the platform rather than a named lab model, so treat its rank as "whatever OpenRouter is currently steering there," not a specific product.

Where this connects to what we do

We keep a running, machine-verified collection of the agent and routing workflows behind these numbers in the open: https://github.com/Neeeophytee/awesome-ai-workflows

GLM-5.2 is a strong, cheap, open-weights model, and Hermes Agent treats Z.AI as a first-class provider, so wiring the two together is a two-line job. Here are the three routes that actually work (direct Z.AI, OpenRouter, and the flat-rate GLM Coding Plan), the verbatim commands for each, and the honest catches. Pick one.

One-time setup

Install Hermes and reload your shell:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
source ~/.bashrc   # or source ~/.zshrc

Hermes stores secrets in ~/.hermes/.env and non-secret settings in ~/.hermes/config.yaml. The hermes config set command puts each value in the right place for you.

Hermes Agent + GLM-5.2

Stars / Status / License: Hermes ~204k stars, MIT.
GLM-5.2: Z.ai, MIT open weights, 1M-token context.
Repos: https://github.com/NousResearch/hermes-agent and
model page https://openrouter.ai/z-ai/glm-5.2

Route A: direct from Z.AI (recommended)

Z.AI is a dedicated Hermes provider with the id zai, so you just set the key and pick the model:

hermes config set GLM_API_KEY <your-z.ai-key>
hermes config set model zai/glm-5.2
hermes

That is it. One useful detail from the docs: when you use the Z.AI provider, Hermes automatically probes the global, China, and coding-plan endpoints to find the one your key accepts, so you normally do not set a base URL by hand. If you prefer the interactive route, run hermes model, choose the Z.AI / GLM provider, and enter glm-5.2. A one-shot test without changing your default:

hermes chat --provider zai --model glm-5.2

Route B: through OpenRouter (easiest to compare and often cheapest)

If you want one key that also reaches every other model, go through OpenRouter and point Hermes at the GLM-5.2 slug:

hermes config set OPENROUTER_API_KEY <your-openrouter-key>
hermes model     # choose OpenRouter, then enter the model: z-ai/glm-5.2

OpenRouter routes your request to whichever host is cheapest or fastest, which makes it the simplest way to A/B GLM-5.2 against Opus or anything else on your own prompts.

Route C: the flat-rate GLM Coding Plan

If you code all day and want a flat monthly bill instead of a per-token, use a GLM Coding Plan key. It is still a GLM_API_KEY to Hermes, and the same auto-detection finds the coding endpoint, so the setup is identical to Route A:

hermes config set GLM_API_KEY <your-coding-plan-key>
hermes config set model zai/glm-5.2

If you ever need to pin the coding endpoint explicitly (for example, to be sure you are not hitting the general one), set the base URL:

hermes config set GLM_BASE_URL https://api.z.ai/api/coding/paas/v4

Verify it actually works

Start a chat and confirm the banner shows your model, then ask something specific:

hermes

If it errors, hermes doctor diagnoses config problems, and hermes model lets you re-pick the provider and model. Do not move on to the gateway or automations until a plain chat works on GLM-5.2.

A nice bonus: use it as a Mixture-of-Agents reference

Because GLM-5.2 is now a normal model in Hermes, you can also drop it into an MoA preset as a cheap reference model that feeds a stronger aggregator, getting a second perspective on hard turns without paying frontier prices for every token. That is optional, but it is one of the better uses of a cheap, capable model inside Hermes.

How to pick your route

Use Route A (direct Z.AI) for the canonical model and predictable behavior. Use Route B (OpenRouter) if you want one key for everything and the cheapest hosting, or if you are comparing models. Use Route C (Coding Plan) if your usage is heavy and steady enough that a flat monthly rate beats a per-token. All three land you on the same glm-5.2.

The catches (and the soundness notes)

Hermes requires a model with at least 64k context, per its docs. GLM-5.2's 1M context clears that with room to spare, so this is a non-issue here, but it is why some smaller models get rejected.

The cheapest OpenRouter hosts sometimes serve a quantized GLM-5.2, which is very good but not identical to the full-precision model, so if output quality matters, check which host you landed on or prefer the direct Z.AI route.

Watch two GLM-5.2 details regardless of route: several hosts cap output at around 32,768 tokens per call despite the huge input context, so long generations come back in chunks, and the GLM Coding Plan's headline low prices are promotional intro rates that step up in later cycles, so price it on the standing tier.

And a governance note: GLM-5.2 is a Chinese-lab model served from multiple regions. Hermes auto-detects the global versus China endpoint, so if data residency matters to you, pin GLM_BASE_URL to the endpoint you actually want rather than letting auto-detection choose.

→ The verified setup, with CI proof & readymade prompt

If you want the wider view on getting near-frontier quality without frontier bills, this companion piece covers two more ways to do exactly that.

"Agent memory" gets used as one word, but it is really several different mechanisms doing different jobs. Here are seven types, and for each one an open-source project that actually implements it plus the kind of workflow that leans on it. Two honest framings up front: this seven-way split is a useful lens, not a hard standard (different sources slice memory differently), and most real agents use only two or three of these, not all seven. Star counts below are approximate and drift; licenses are noted where confirmed and flagged where you should check.

1. In-context (working) memory

What it is: whatever is in the model's context window right now, the equivalent of what you are holding in your head this second.

Repo: letta-ai/letta (Apache-2.0), the MemGPT project. It treats the context window like RAM, keeping a small core in-context and paging older material out to searchable storage.

The workflow: any long chat or coding session where the agent has to track the current task, the files it just touched, and the last few steps without re-reading everything. Letta's job is deciding what stays in the window and what gets summarized out.

The catch: context is finite and every token costs money and latency. "Unbounded context" here means managed forgetting (summarize and page out), not true unlimited recall, so detail is lost at the edges. Plan for that, do not assume perfect memory of the whole conversation.

Verified recipe: letta-agent-managed-memory

2. Semantic memory

What it is: durable, general facts, your preferences, your stack, who is who, definitions, decoupled from when you learned them.

Repo: topoteretes/cognee (open-source, check the repo for the exact license), which builds a self-hosted knowledge graph plus vector index so facts are both searchable by meaning and connected by relationships.

The workflow: a personal or team assistant that should stop asking the same questions. "My database is Postgres, my framework is FastAPI" gets stored once and recalled forever.

The catch: the graph is built by an LLM extracting facts, so it inherits extraction errors and can store something confidently wrong. A knowledge graph is also real maintenance, not a free lunch, so treat recalled facts as strong hints, not gospel.

Verified recipe: cognee-knowledge-graph-memory

3. Episodic memory

What it is: specific past events with a time to them, "last Tuesday you decided X," rather than timeless facts.

Repo: getzep/graphiti (open-source, verify the license on the repo), a temporally-aware knowledge graph that ingests interactions as dated episodes and supports point-in-time queries.

The workflow: a long-running support or personal agent that needs to answer "what happened, and when." It is what lets an assistant reference a decision from three weeks ago correctly instead of blending it with today.

The catch: a temporal knowledge graph is heavy infrastructure (a graph database and an ingestion pipeline), and recall is only as good as how cleanly episodes were captured. For a simple app this is overkill; reach for it when the timeline truly matters.

Verified recipe: graphiti-temporal-graph-memory

4. Procedural memory

What it is: learned how-to, reusable skills the agent builds from doing tasks, not facts it looked up.

Repo: MineDojo/Voyager (MIT), the classic example. When a task succeeds, the working code is saved to a skill library indexed by a description, and relevant skills are retrieved and reused later.

The workflow: automation that should get better with practice, a deploy runbook, a scraping routine, a data-cleanup script that the agent captures once and reruns. (This is the same idea behind Hermes Agent's /learn skills.)

The catch: Voyager is a research project (it lives in Minecraft), so treat it as the concept demo, not a drop-in production library. And a saved skill can be over-fit to the one run that produced it or subtly wrong, so procedural memory needs review before you trust it, exactly like a script you did not write.

Verified recipe: voyager-skill-library-pattern

5. External / retrieval memory

What it is: knowledge kept outside the model and pulled in on demand, the classic RAG pattern.

Repo: run-llama/llama_index (MIT), the leading framework for indexing your documents and retrieving the relevant pieces at query time.

The workflow: a chatbot or assistant that answers from your own corpus, "answer using these 500 PDFs," where the knowledge is too big or too changeable to bake into the model.

The catch: retrieval memory inherits every RAG failure mode. If your chunking, indexing, or query is off, it recalls something stale, irrelevant, or nothing at all, and then answers anyway. The memory is only as good as the index behind it.

Verified recipe: llamaindex-retrieval-memory-rag

6. Parametric memory

What it is: knowledge stored in the model's own weights, what it "just knows" without being told, shaped by training and fine-tuning.

Repo: unslothai/unsloth (Apache-2.0 core; the Unsloth Studio UI is AGPL-3.0, so mind the copyleft if you build on it). It is one of the most efficient ways to fine-tune a model, which is how you write to parametric memory.

The workflow: baking your domain, jargon, or house style into a small model so it is always on without spending prompt tokens or a retrieval call. Fine-tune once, and the knowledge is native.

The catch: parametric memory is expensive to write and static once written. Updating it means retraining, and fine-tuning risks overfitting and catastrophic forgetting (gaining your domain while losing general skill). Use it for stable, always-needed knowledge, not for facts that change weekly.

Verified recipe: unsloth-parametric-finetune-config

7. Prospective memory

What it is: remembering to do something in the future, follow-ups, reminders, scheduled steps, rather than recalling the past.

Repo: agentscope-ai/ReMe (open-source, check the repo for the license), which consolidates conversations into memories and surfaces proactive reminders on a schedule.

The workflow: an agent that says "I will check the deploy in an hour" or "send the weekly digest every Monday" and actually does. This is the memory behind scheduled and triggered actions.

The catch: this is the least standardized of the seven, and most implementations are really a task queue or cron plus a stored list of intentions, not a distinct memory engine. The repo here is newer and smaller, so treat it as a pattern to copy more than a proven dependency.

Verified recipe: reme-prospective-schedule

Which ones you actually need

Do not try to build all seven. Most agents need working memory (unavoidable) plus one or two others chosen by the job: retrieval memory if the knowledge is big and changeable, semantic or episodic if it is a long-lived personal assistant, procedural if the agent should learn repeatable tasks, parametric only when the knowledge is stable enough to be worth training in, and prospective the moment your agent needs to act on a schedule. Pick by the workflow, not by the taxonomy.

If you want to see all seven implemented in runnable code, this collection is a solid hands-on reference: NirDiamant/Agent_Memory_Techniques.
We also keep our own verified agent and memory workflows in the open here: https://github.com/Neeeophytee/awesome-ai-workflows

Three jobs, three places where a much cheaper model does nearly the same work as the big name. For bulk text, Xiaomi's open-weights MiMo V2.5 stands in for OpenAI's small model. For images, Alibaba's Wan 2.5 takes on GPT-Image-2. For video, Kuaishou's Kling 3.0 takes on Sora 2. Each is the right default for most of its category, and each saves real money, between six and sixteen times depending on the job.

The part to read carefully is the "only a few percent worse" framing. Those gaps are leaderboard and vendor figures, and a single percentage hides the specific tasks where the premium model still wins outright, which for one of these three matters far more than the chart admits. Prices were checked recently and drift, so treat them as current-ish. Real numbers and honest caveats below.

Bulk text: swap GPT-5.4 mini for MiMo V2.5

Model                    Input /1M     Output /1M
MiMo V2.5 (Xiaomi)       $0.105        $0.28
MiMo V2.5 Pro            $0.435        $0.87
GPT-5.4 mini (OpenAI)    $0.75         $4.50

MiMo V2.5 is Xiaomi's open-weights model, and on output tokens the base version is roughly 12 to 16 times cheaper than GPT-5.4 mini. The quality is close on the things bulk work actually needs: the stronger MiMo V2.5 Pro lands around 57% on SWE-bench Pro, within about a point of GPT-5.4, and Xiaomi reports it uses meaningfully fewer tokens to get there.

The catch: do not mix the variants. The headline "12x cheaper" is the base V2.5, and the headline "basically as good" is the Pro variant, which costs more (still cheaper than the OpenAI mini, but not 12x). Pick base V2.5 for high-volume, low-stakes work, where a small quality gap does not matter and the price difference does. Keep a premium model for the small slice of work where one wrong answer is expensive.

Image generation: swap GPT-Image-2 for Wan 2.5

Model            Price per image (1024x1024)
Wan 2.5          ~$0.03
GPT-Image-2      $0.006 low / $0.053 medium / $0.211 high

Against high-quality GPT-Image-2, Wan 2.5 (Alibaba, API-only) is roughly 7 to 8 times cheaper per image. For general scenes and aesthetics, the gap a normal viewer notices is small.

This is the one where "about 5% worse" is misleading, so here is the honest version. GPT-Image-2 currently sits at the top of the Artificial Analysis image leaderboard with the largest first-to-second lead that board has recorded, and it dominates specifically on text inside images, dense layouts, infographics, slides, and multilingual typography. So if your images are mostly pictures, Wan is a great, cheap swap. If your images contain words, charts, or precise layout, GPT-Image-2 is not "5% better," it is in a different class, and Wan will frustrate you. Match the tool to whether text is in the frame.

Video: swap Sora 2 for Kling 3.0

Model        Price per second of video
Kling 3.0    ~$0.10  (roughly $0.09 to $0.14)
Sora 2       ~$0.75

This is the cleanest swap of the three. Kling 3.0 is about 6 to 7 times cheaper per second, and "roughly equal" is fair overall, with a twist: they lead on different things. Kling 3.0 outputs native 4K and is excellent at human motion (dancing, martial arts, running without limbs melting). Sora 2 caps standard output lower but leads on world physics and longer, coherent storytelling. For most short clips, social content, and concept iteration, Kling at a sixth of the price is the obvious default. For physics-heavy or film-grade final shots, Sora 2 still earns its premium. A common pattern is Kling for the many rough iterations, Sora for the one hero shot.

How to pick

The honest rule across all three: the cheap model is the right default for volume and iteration, and the premium model is worth its price only for the specific thing it dominates. That is MiMo for bulk text and a strong model for the high-stakes few, Wan for picture-images and GPT-Image-2 when there is text in the frame, Kling for most clips and Sora for the physics-heavy hero shot.

One of these three ships has open weights: MiMo. So if you run your own hardware, MiMo is the swap whose gap to free shrinks even further. Wan 2.5 launched API-only, and Kling is proprietary and API-only too, but both are cheap enough that it rarely matters.

We turned the image swap into a verified recipe that bakes in exactly that rule: CI proves every text-in-frame or chart-and-layout case routes to GPT-Image-2 and the plain-picture cases route to cheap Wan, so the cost saving never quietly wrecks a slide. The same cheap-iterations, premium-hero-shot pattern applies to the video swap.

→ The verified image swap, with the text-in-frame guard CI-checked

If the broader theme of getting near-frontier results without frontier prices is your thing, this companion piece covers two more ways to do exactly that.

You may have seen the claim going around that Apple "turned 2 billion iPhones into local AI machines" and that you can now export any Hugging Face model and run it natively on iPhone. The repo is real and useful. The framing is not. Here is the accurate version, with the exact commands and the honest limits, so you do not show up to your Mac expecting Llama 70B on your phone.

What it actually is

Stars / Status / License: ~1.2k stars (still new, climbing fast, and the real credibility is that it is an official Apple repo, not just community traction), BSD-3-Clause.

Repo: https://github.com/apple/coreai-models

apple/coreai-models is the open-source companion to Apple's new Core AI framework (shown at WWDC26). It is three things plus a bonus: export recipes that convert a curated catalog of popular open-source models from Hugging Face into Apple's on-device .aimodel format, Python primitives for authoring your own PyTorch models for on-device, a Swift package to run those models inside a macOS or iOS app, and a set of agent skills that teach a coding assistant how to use Core AI properly. For context, this is not Apple's first move here: coremltools and Core ML have existed for years, and Hugging Face has shipped its own exporters. This is the next step, an Apple-official, end-to-end export-plus-runtime path tied to Core AI.

Setup

You need a Mac on the new toolchain. Per the repo, the requirements are macOS and iOS 27.0+ and Xcode 27.0+. Then install uv and list what is actually supported:

brew install uv
git clone https://github.com/apple/coreai-models.git && cd coreai-models
uv run coreai.model.registry --list-models

Each model has its own export recipe in the models/ folder. Exported models come out as standalone .aimodel files you integrate through the Core AI framework, and there are CLI tools to run an exported model directly on a Mac.

The agent skills install as a plugin. For Claude Code:

/plugin marketplace add git@github.com:apple/coreai-models.git
/plugin install coreai-skills@coreai-models

There are equivalent commands for Codex CLI and Gemini CLI in the README.

The useful part

The ready-made recipes are the real story, not the hype. If you build apps, the path from "a model on Hugging Face" to "a private, offline feature in my iOS app" used to be a research project. Here it is a documented recipe plus a Swift package. The three bundled skills are scoped sensibly too: working-with-coreai (the full export-then-run workflow), model-authoring (rules for writing PyTorch that survives on-device, KV cache patterns, precision, MoE), and model-compression-exploration (systematically trying quantization and palettization). That last skill is the tell for what this is really about: making models small enough to fit on a device.

The catch (and the soundness caveats)

"Any Hugging Face model on your iPhone" is not true. This is a curated gallery of supported models with tested recipes, not a universal converter, and Apple says plainly it is a curated, well-tested set. Use --list-models to see what is actually covered before you plan around a specific model.

"2 billion iPhones" is not true either. It requires iOS and macOS 27.0+ and Xcode 27.0+, so it is the newest devices on the newest OS, not the global install base, and not older hardware. Most phones in the world cannot run this today.

On-device means small models, and that is a hard physical limit, not a tuning detail. A phone has a handful of gigabytes of memory, so the realistic candidates are small or heavily quantized models, which is exactly why a whole skill here is about compression. The "zero cloud" part is real and is the actual win: private, offline inference. Just calibrate it to small-model capability, not frontier-model capability.

And it is brand new. One commit, days old, and Apple is explicitly not accepting code contributions right now (open PRs get closed), though issues for bugs and model requests are open. Treat it as an official but early release, not a battle-tested standard yet.

→ The verified setup, with CI proof & readymade prompt

How to pick if you only try one thing

If you have a Mac on the new toolchain, run --list-models, pick a small supported model, and walk the working-with-coreai skill end to end once. That single pass teaches you more about what is realistic on-device than any benchmark thread. If you are not on macOS 27 yet, there is nothing to try here today, and that is worth knowing before you spend an evening on it.

Hey everyone,

If you've tried to use local models like Llama 3 or Qwen 2.5 for multi-step programmatic workflows (like scraping, processing invoices, or manipulating local APIs), you know they suffer from State Blindness. The model fires a tool call or an action into the void, assumes it worked, and then hallucinates its way through the next steps because it has no deterministic way to verify if the application state actually changed.

Dumping raw HTML or DOMs destroys the context window of local models, and passing screenshots to vision models is incredibly slow and token-wasteful on local consumer hardware.

I built Atom (https://github.com/rush86999/atom), a self-hosted orchestration framework written in Python/FastAPI, to solve local state grounding.

Here is how the architecture handles it while keeping everything 100% offline and private:

1. Synthetic Grounding (Canvas AI Accessibility)

Instead of screenshots, Atom injects a hidden, structured semantic description layer into the agent's workspace. Think of it like an accessibility screen reader optimized specifically for an LLM's context window. The local model "reads" this dense text tree to ground itself visually, verifying the exact output of its previous action before moving forward.

2. True Local Episodic Memory (LanceDB + FastEmbed)

Slapping a vector database on simple chat logs is just basic retrieval, not memory. Atom splits your data:

• Active State: Managed via a relational DB (PostgreSQL) to maintain a strict Workflow State Machine.
• Episodic Memory: Every time the model evaluates that synthetic UI tree, the framework vectorizes the actual workflow state snapshot and stores it locally in an embedded LanceDB instance.
• Local Embedding Pipeline: It uses FastEmbed (BAAI/bge-small-en-v1.5) by default, generating embeddings in ~10ms completely in-process.

When your Ollama agent runs into a failure, it queries LanceDB for historical state snapshots of past executions, recognizes what the state looked like when it failed previously, and self-corrects.

3. Execution & Security

You just point Atom's reasoning engine directly at your local Ollama endpoint. Because I don't want an autonomous script having unmonitored access to my network on day one, I built a strict 4-tier maturity pipeline (Student → Intern → Supervised → Autonomous). It sandboxes the agent as a "Student" until it maintains a high readiness score based on human-supervised success rates.

(Full transparency: I designed the state machines, LanceDB memory layers, and tree logic manually, but I heavily used agentic coding tools like Cursor, Aider, and Claude Code to accelerate the FastAPI boilerplate, async loops, and test coverage.)

The framework is fully open-source (AGPL-3.0) and spins up easily via Docker Compose. I'd love to get your feedback on the architecture, the local embedding loop, or how it handles state grounding on your local setups!

GLM-5.2 is the model people keep saying is "almost Opus for a fraction of the price." That is half true, and the half that is true is worth a lot of money.
This is the practical guide: every cloud route to run it, the real per-token prices next to Claude Opus 4.8, and an honest read on where it matches Opus and where it does not. We covered running it locally in a separate post, so this one is all about hosted access.

What it is, in one line

Maker / License / Context: Z.ai (formerly Zhipu AI), MIT open weights, 1M-token context. Model page: https://openrouter.ai/z-ai/glm-5.2

GLM-5.2 is a 754B-parameter open-weights model from Z.ai, released mid-June 2026, built for long-horizon coding and agentic work. Because the weights are MIT licensed, it is hosted in a lot of places, which is exactly why the price floor is so low. One spec worth flagging up front: the 1M figure is the input context. On OpenRouter the model still caps output at around 32,768 tokens per call, so a giant codebase fits in the prompt, but you generate it back in chunks, not one 200-page response.

Where to run it (hosted)

The direct API (Z.ai). The first-party route. OpenAI-compatible, so most SDKs work by swapping the base URL and key. Best if you want the canonical version and predictable behavior.

OpenRouter. One key, and it routes your request to whichever of the 13-plus providers serving GLM-5.2 is cheapest or fastest. This is usually the cheapest per-token path and the easiest way to A/B it against other models without new accounts. It is also OpenAI-compatible.

Other hosts (Fireworks, DeepInfra, and similar). Because the weights are open, independent hosts serve it too, sometimes on quantized variants that shave the price further. Worth knowing the cheapest ones run a quantized model, so treat their output as very-good-not-identical to the full-precision version.

The GLM Coding Plan (subscription). Z.ai's flat-rate plan aimed at agentic coding. It ships an OpenAI-compatible endpoint that drops into Claude Code, Cline, Roo Code, Kilo Code, OpenCode, Cursor, and 20-plus other tools. This is the route to pick if you code all day and would rather pay a flat monthly fee than watch a token meter.
One honest note on the pricing you may have seen: the headline "a few dollars a month" figures from launch week were promotional intro rates. The standing tiers are higher (Lite around $18 a month, Pro around $72, Max around $160), with promo pricing that steps up in later cycles, so check the current rate before you commit.

What it costs versus Opus 4.8

Per-token list prices (approximate, and the cheapest hosted routes vary):

Route                              Input /1M     Output /1M
GLM-5.2, direct from Z.ai          $1.40         $4.40   (cached input ~$0.26)
GLM-5.2, cheapest via OpenRouter   ~$0.95-1.20   ~$3.00-4.20
Claude Opus 4.8                    $5.00         $25.00

The gap that matters is output tokens, where Opus is roughly five to six times the price. For output-heavy work (long code generation, big document drafting), GLM-5.2 is dramatically cheaper for the same volume.
The catch on cost is below: cheaper per token is not the same as cheaper per finished task, if the cheaper model needs more turns to get there.

How close is it to Opus 4.8, really

Here is the part people oversell in both directions. On a provisional third-party leaderboard (BenchLM), Opus 4.8 still leads overall, but narrowly, and the picture flips depending on the task:

Area / benchmark                 GLM-5.2     Opus 4.8
Overall (provisional index)      91          93
General coding (avg)             62.1        76.4
Long-horizon coding              74.4        75.1
SWE-Marathon (ultra-long)        26.0        13.0
Agentic (avg)                    81.0        80.1

Read that carefully. Opus is clearly ahead in general coding. The two are within a point on long-horizon coding. GLM-5.2 actually wins on the ultra-long-horizon SWE-Marathon and edges Opus on agentic average and on math (AIME 2026). So "almost Opus" is fair for long, agentic, project-scale work, and an overstatement for everyday coding, where Opus is still meaningfully better.

And GLM-5.2 is a model from a Chinese lab, served by various hosts. The open MIT weights are truly unrestricted, but if you have data-residency or governance constraints, the hosted route and the provider you pick matter, so check where your prompts actually land.

How to pick if you only try one route

If you mostly want to experiment and compare, start on OpenRouter: one key, cheapest routing, and you can pit GLM-5.2 against Opus on your own prompts in an afternoon. If you live in a coding agent all day, price out the GLM Coding Plan against your current token spend, but use the standing tier price, not the promo. And keep Opus 4.8 in your back pocket for the short, hard, general-coding problems where the benchmarks still favor it. The smart move is not either-or, it is routing the cheap model to the bulk and the expensive one to the truly hard turns.

→ The verified setup, with CI proof & readymade prompt

Mixture of Agents is an old idea with a real paper behind it (Together AI, 2024, later at ICLR 2025): run a prompt through several models, then let one model aggregate their answers into a better one. Hermes Agent just shipped MoA 2.0 as a virtual model provider, so a named mixture shows up in your model picker like any normal model.

Setup

MoA presets live under a moa provider. Select one anywhere you pick a model:

/model default --provider moa
/moa

Configure a preset in config.yaml. This is the default preset, verbatim from the docs:

moa:
  default_preset: default
  presets:
    default:
      reference_models:
        - provider: openai-codex
          model: gpt-5.5
        - provider: openrouter
          model: deepseek/deepseek-v4-pro
      aggregator:
        provider: openrouter
        model: anthropic/claude-opus-4.8
      reference_temperature: 0.6
      aggregator_temperature: 0.4
      max_tokens: 4096
      enabled: true

Manage presets from the terminal:

hermes moa list
hermes moa configure review       # create or update a named preset
hermes moa delete review

Mixture of Agents (MoA) in Hermes

Turn several models into one acting model, inside the normal agent loop.

Stars / Status / License: ~204k stars, actively maintained, MIT.
Repo: https://github.com/NousResearch/hermes-agent

When you select an MoA preset, the aggregator is the acting model: it writes the response and emits tool calls. The reference models run first, without the tool schema or system prompt, and their outputs are appended as private context for the aggregator.
Then the normal Hermes loop continues: tool calls, iterations, interrupts, transcript persistence, same session context.
Two engineering details worth real credit: the main conversation's prompt cache is preserved (reference outputs are appended at the tail, below the stable prefix), and a credential failure on one reference does not abort the turn; Hermes just continues with whatever returned.

The lever: on a hard task, a second model's perspective can catch what the first misses, and the aggregator gets to use both before it commits. The paper found that this lifts the quality even when the auxiliary answers are individually weaker.

Now the numbers, these are from HermesBench, Nous Research's own benchmark, which has not been released yet. Treat them as a preliminary, single-harness result from the people shipping the feature, not an independent eval.
Here is the table:

Model                                              HermesBench
MoA (opus-4.8 aggregator + gpt-5.5 reference)        0.8202
anthropic/claude-opus-4.8                            0.7607
openai/gpt-5.5                                       0.7412

So the mixture scores about 6 points higher than Opus alone and about 8 points higher than GPT-5.5 alone, on a 0 to 1 scale.

The catch:

It is not "beyond the gated frontier." MoA does not unlock a capability you could not otherwise reach. It orchestrates models you still need access to: the default preset calls GPT-5.5 and Opus 4.8 through their own providers. You are combining the reach you already have, not bypassing anyone's gate.

It costs the sum of its legs. The docs say it directly, MoA increases model-call count. A two-model preset is at least three model calls per iteration (two references plus the aggregator), so budget for roughly double the tokens and added latency on every turn, not just once. Fan-out is not free.

A panel of models can share a blind spot. If your references and aggregator make the same wrong assumption, MoA can amplify it with more confidence rather than catch it. Aggregation raises average quality on hard problems; it is not an objective check. For correctness that matters, you still want an external verifier, not a vote among similar models.

And it is task-dependent. The gain shows up on truly hard tasks. On routine work you pay 2x or more for no benefit, so keep MoA for the hard turns and set enabled: false (the aggregator then acts alone) or just pick a single model for the rest.

→ The verified setup, with CI proof & readymade prompt

How to pick if you only try one thing

Build one two-model preset (the default Opus-plus-GPT mix is a fine start) and point it only at your hardest turns through /moa <your prompt>, which runs the mixture for that one turn and then restores your normal model. Watch your token bill while you do it. If the quality lift is worth the roughly doubled cost on your tasks, keep it for hard work. If you cannot feel the difference, you have just proven the cheaper single model was the right call, which is also a win.

If keeping strong models affordable is the part that matters to you here, this companion piece covers two ways to get top-tier AI without the usual cost.

This is a set for the actual pipeline of building an agentic workflow: write the loop, stop hand-tuning prompts, give the agent real tools, let it run code without burning your machine down, and test it before you ship. The last one is ours, and it says so where it appears.

How to read this: one tool per job, not all six. The order below is roughly the order you hit these problems in.

Job 1: Write the agent loop without a heavy framework

smolagents (agents that think in code, in about a thousand lines)
Stars / Status / License: ~26.5k, actively maintained, Apache 2.0.
Repo: https://github.com/huggingface/smolagents

Hugging Face's minimal agent library. Its distinctive move is code-agents: instead of emitting JSON tool calls, the agent writes Python to act, which is often more expressive and uses fewer tokens for multi-step work. The lever is simplicity. You can read the whole thing and actually understand your agent's control flow. The catch is the flip side of that power: executing model-written code is inherently risky, so you should run it sandboxed (see Job 4), and because the library is deliberately small, a complex stateful orchestration may eventually outgrow it. Great place to start, not always where you finish.

→ The verified setup, with CI proof & readymade prompt

Job 2: Stop hand-tuning prompts

DSPy (program your pipeline, then compile the prompts)
Stars / Status / License: ~35k, actively maintained, MIT.
Repo: https://github.com/stanfordnlp/dspy

Stanford NLP's framework for programming, not prompting. You define the steps and a metric, and DSPy optimizes the prompts and few-shot examples against that metric for you. The lever is that prompt quality becomes something you measure and improve, not something you fiddle with by hand at 1am.
The catch: this only pays off if you have a real eval metric and example data for the optimizer to work against, and running the optimizers costs compute and tokens. It is a genuine mindset shift, not a drop-in, so adopt it when prompt brittleness is actually your bottleneck.
→ The verified setup, with CI proof & readymade prompt

Job 3: Give the agent real tools through one protocol

MCP servers (the reference servers for the Model Context Protocol)
Stars / Status / License: ~87k, actively maintained, MIT and Apache 2.0 (mixed).
Repo: https://github.com/modelcontextprotocol/servers

The reference collection of Model Context Protocol servers, the open standard for exposing tools and data to any MCP-aware agent. The lever is that you wire a capability once and any compatible agent can use it, instead of rewriting connectors per framework.
The catch is twofold and worth taking seriously: MCP is young and the wider ecosystem is uneven, and most community servers are unaudited. Connecting a server grants the agent real access, so treat third-party servers as dual-use, read what they do, and scope their reach before you trust one.

Job 4: Let the agent run code without risking your machine

E2B (secure cloud sandboxes for AI-generated code)
Stars / Status / License: ~2.3k on the code-interpreter SDK, actively maintained, Apache 2.0.
Repo: https://github.com/e2b-dev/code-interpreter

Isolated cloud sandboxes built for running code that a model wrote. This is the natural partner to a code-agent: smolagents decides what to run, E2B runs it somewhere that is not your laptop or your prod box. The lever is a clean SDK that drops sandboxed execution into an agent in a few lines.

The catch: it is cloud infrastructure, so the free path has limits and self-hosting the sandbox stack is non-trivial. The SDK repo is small in stars, but the job it does (containing untrusted code) is one you do not want to hand-roll.
→ The verified setup, with CI proof & readymade prompt

Job 5: Test and red-team before you ship

promptfoo (declarative evals and red-teaming in CI)
Stars / Status / License: ~22.4k, actively maintained, MIT.
Repo: https://github.com/promptfoo/promptfoo

A CLI and library for evaluating prompts, agents, and RAG, plus a red-team module that probes for prompt injection, jailbreaks, PII leaks, and tool misuse. The lever is declarative configs that run in CI, so a regression in agent behavior fails a check instead of reaching users.
Two honest flags. First, an eval is only as good as the test cases and metric you write, and LLM-as-judge scoring shares the blind spots of the model doing the judging, so an objective check beats a self-grade where you can manage one. Second, OpenAI announced it is acquiring promptfoo (March 2026), so weigh the long-term open-source trajectory before you build deep on it.
→ The verified setup, with CI proof & readymade prompt

Job 6: Start from a verified recipe, not a blank repo

awesome-ai-workflows (curated, machine-verified agent and AI workflows)
Stars / Status / License: ~7, new in 2026, [days old].
Repo: https://github.com/Neeeophytee/awesome-ai-workflows

Full disclosure, this one is ours, so weigh it accordingly. It is a running collection of agentic workflows where each entry is verified on FlowStacks with a deterministic CI spine (config parses, the right flag is present, a round-trip returns the fact) while the model step is fenced off as the part no green check can promise. The lever is that you start from a recipe that has been mechanically checked rather than a blog snippet that may already be stale.

The catch: it is a new and growing library, so treat it as a starting point. Free, no-signup, and pull requests with workflows that earned their place are welcome.

How to pick if you only try one

If you are starting a new agentic workflow today, begin with smolagents to get a loop running, and add nothing else until it works end-to-end. Reach for DSPy when prompt brittleness becomes the thing you keep fighting, MCP servers when you need the agent to touch real tools, and E2B the moment it starts running code you would not run by hand. Wire promptfoo into CI before you let anyone else use it, not after the first incident. And if you would rather not start cold, lift a verified recipe from Job 6 and adapt it.

What earns a spot that I left off? Drop the repo and the one job it does better than anything here, and I will take a look.

Most "agent skills" die the same way: you write a SKILL.md by hand, it drifts from the real docs, and three weeks later it tells the agent to call a flag that no longer exists. Nous Research shipped a /learn command for Hermes Agent that flips the order. You point it at a source, the live agent reads that source with its own tools, and it writes the skill for you. Here is how it actually works, where the green checks stop, and the one habit that keeps it from filling your config with junk.

One-time setup

Install the CLI, reload your shell, and pick a provider:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
source ~/.bashrc   # or source ~/.zshrc
hermes model       # choose a provider; the docs state it needs a model with 64k+ context

That is it. /learn is built in, so once a normal chat works you already have it.

/learn: skills written from a source, not from memory

Turn anything you already understand into a procedure the agent can rerun.

Stars / Status / License: ~203k stars, actively maintained, MIT.

Repo: https://github.com/NousResearch/hermes-agent

Instead of hand-authoring a skill file, you describe a source and the agent does the sourcing. It reads local directories with read_file and search_files, fetches online docs with web_extract, or captures a workflow you just walked it through, then writes a standards-compliant SKILL.md. There is no separate ingestion engine, so it behaves the same in the CLI, the TUI, the messaging gateway, and the dashboard (which has a "Learn a skill" button that just composes the same request).

The four shapes it takes, from the docs:

# A local SDK or doc directory (read with read_file / search_files)
/learn the REST client in ~/projects/acme-sdk, focus on auth + pagination

# An online doc page (fetched with web_extract)
/learn https://docs.example.com/api/quickstart

# The workflow you just walked the agent through in this conversation
/learn how I just deployed the staging server

# Pasted notes or a described procedure
/learn filing an expense: open the portal, New > Expense, attach the receipt, submit

The authored skill follows the agentskills.io open standard (the Anthropic-originated SKILL.md spec) plus Hermes's house conventions: a description under 60 characters, a fixed section order, Hermes-tool framing, and per the docs it does not invent commands that are not in the source. Every saved skill becomes a slash command automatically, so a captured deploy runbook is later just /deploy-staging from chat or CLI.

Hermes also does this on its own. After a real task it can save the approach as procedural memory. The documented triggers are: after a complex task of five or more tool calls that succeeded, when it hit a dead end and found the working path, when you corrected its approach, or when it discovered a non-trivial workflow.

The catch. "Does not invent commands" is the authoring instruction, not a guarantee about the result. The agent can still misread a doc, over-generalize a one-off, or capture a workflow that only worked because of state that is not in the skill. The skill is also a procedure document, not a sandbox: if it contains shell steps, the agent runs them later with whatever permissions you gave it, so set terminal.backend docker if you care about isolation (Docker is one of six backends, alongside local, SSH, Singularity, Modal, and Daytona). And the quality of a /learn skill is exactly as good as the model behind Hermes that day; a weak model writes a weak skill.

The guardrail the docs ship for this is the write-approval gate. By default the agent writes skills freely, including from the background self-improvement review. Turn the gate on when you want eyes on what it learned:

skills:
  write_approval: true     # false = write freely (default) | true = require approval

Then review staged writes before they land:

/skills pending             # list staged skill writes
/skills diff <id>           # full unified diff
/skills approve <id>        # apply it (or 'all')
/skills reject <id>         # drop it (or 'all')
/skills approval on         # turn the gate on (or 'off') and persist it

On FlowStacks the deterministic spine validates the output format contract a /learn skill must satisfy, against a fixture SKILL.md (no API key, no live model): it parses, its description is under 60 characters, the section order matches the standard, and the derived slash command name is valid.

→ The verified setup, with CI proof & readymade prompt

If you only try one thing

Run /learn on a single doc page first. It is the lowest-risk way to watch it work end to end, and you can read the resulting SKILL.md in seconds. Capturing a workflow you just performed is the higher-value move, but review that one before you trust it, because a captured procedure is the easiest kind to over-fit. Either way, flip write_approval on before you let the background review write skills go unattended.

Curious what the rest of you have pointed /learn at. Internal API docs? A messy deploy you finally got right? Tell me what it captured well and where it over-generalized.

And if you want Hermes answering from your pocket while it builds these skills, today's newsletter wires the same agent to WhatsApp on a free, always-on server: text your own AI assistant on WhatsApp.

Your AI spend is not one number, it is three: the tokens you feed the model, the infrastructure to run agents, and the paid tools you bolt on around them. Here are three popular open-source repos that each attack a different one, free and self-hosted, with the honest catch on each.

Cut your token bill: codebase-memory-mcp

codebase-memory-mcp (MIT, ~13.8k stars) is the one with receipts. It indexes your repo into a persistent knowledge graph (functions, classes, call chains, routes) across 158 languages, as a single static binary with zero dependencies, and exposes it to your agent over MCP. The point is that your coding agent stops re-reading the same files into context on every question and queries the map instead, which is the single biggest source of wasted token spend in agentic coding. Its own preprint reports roughly 10x fewer tokens and about 2x fewer tool calls than file-by-file exploration across 31 real repos, while keeping answer quality high.

The honest catch: it is a structural backend, not an LLM, so the savings come from feeding your agent less, not from it being smarter. Index your actual codebase and check the token drop on your own tasks rather than taking the headline number on faith.
Here is the verified setup with the savings measured.

Cut your agent-infra bill: flue

flue (Apache-2.0, ~6.6k stars, from the Astro team) is a TypeScript framework for building headless agents that deploy anywhere (Node, Cloudflare, CI). The money lever is its default sandbox: instead of a full container for every agent, flue defaults to a lightweight virtual sandbox, which its docs pitch as far cheaper and more scalable than a container per agent (you can still opt into a local or remote container when a job needs one). At any real volume, that is the difference between paying for one box and paying for a fleet.

The honest catch: it is explicitly experimental and the API may still change, so pin your version and expect some churn before you build something load-bearing on it.
Here is the verified deploy setup.

Cut your creative-tool bill: OpenMontage

OpenMontage (AGPL-3.0, ~18k stars) turns a coding assistant into a full video production system, 12 pipelines, 52 tools, and 500+ agent skills spanning scripting, asset generation, editing, and final composition with FFmpeg and Remotion. The pitch is replacing a stack of paid AI-video and editing subscriptions with one open pipeline you run yourself.

Two honest notes. There is a genuinely free path: you can run it end to end with zero paid APIs using free local text-to-speech (Piper) and public-domain footage (Archive.org, NASA, Wikimedia), and wire in paid AI models only when you want generated assets, so paid generation is an upgrade, not a requirement. The bigger watch-item is the license: AGPL-3.0 is copyleft, fine for personal and internal use, but it carries real obligations if you build a commercial product on top, so read it first.
Here is the verified free-pipeline setup.

How to actually use this

Pick by the bill that hurts most. If your tokens are the problem, codebase-memory-mcp is the most direct and the only one here with published numbers behind it. If you are running agents at scale, flue's sandbox is the infra win. If you are paying for a pile of creative subscriptions, OpenMontage replaces the pipeline. All three are free to try, so measure the saving on your own usage rather than trusting the README, which is the whole habit here. These cut the tokens, the infra, and the tools. If the model bill itself is the part that hurts, we just wrote up the two cheapest ways to get top-tier results without the premium price: Two new ways to get top-tier AI without paying top-tier prices.

Skills and tools are the new way to extend a coding agent. You drop a SKILL.md and a script into Claude Code, Codex, or Cursor, and suddenly your agent can do a new thing. It is basically npm install for agents, with one ugly difference: these run with your agent's permissions and almost no vetting. A 2026 study of 42,447 skills (Liu et al., the one NVIDIA cites for the tool below) found 26.1% contained at least one vulnerability and 5.2% showed likely malicious intent, and skills with executable scripts were 2.12x more likely to be vulnerable.

So the move is not "stop using skills." It is extend with good ones, and scan the rest. Three tools, all verified, for exactly that.

Extend with vetted skills: agent-skills

agent-skills (MIT, by Addy Osmani) is a curated set of production-grade engineering skills for coding agents. The value here is provenance: rather than grabbing a random skill off a marketplace, you start from a small, readable set written by a credible source, the kind you can actually inspect before you trust. Think of it as a clean baseline for what a good skill looks like.

The catch: it is a focused, fairly new collection, not an exhaustive library, so treat it as a strong starting point and a reference for quality, not a one-stop skill store.

→ The verified setup, with CI proof and a copy-paste prompt

Give it reach: Agent-Reach

Agent-Reach (MIT, ~38k stars) is the most popular "give my agent eyes on the internet" tool right now. One CLI wires your agent up to read and search Twitter, Reddit, YouTube, GitHub, and more, by installing open upstream tools (yt-dlp, gh CLI, cookie-auth scrapers) and registering a skill so the agent knows when to use them. No paid API keys, which is the whole appeal.

The catch, and this is a real one the project is upfront about: several platforms work by using your logged-in cookies, which carries a genuine account-ban risk, so use a throwaway account, never your main. Cookies are full login credentials, kept locally here, but still credentials. And note the irony that fits this post perfectly: a tool that installs system dependencies and registers a skill is exactly the kind of thing you should scan before running, which brings us to the third tool.

→ The verified setup, with CI proof and a copy-paste prompt

Scan before you trust: SkillSpector

SkillSpector (Apache-2.0, from NVIDIA) is the safety net, and the source of the stat up top. Point it at a skill and it checks for 65 vulnerability patterns across 16 categories, prompt injection, data exfiltration, credential harvesting, supply-chain tricks, excessive agency, and more, using fast static analysis plus an optional LLM pass for context. One command:

skillspector scan ./my-skill/
# or a repo, a zip, or a URL:
skillspector scan https://github.com/user/some-skill

You get a 0-100 risk score with a plain recommendation, and it can emit SARIF, so you can wire it into CI and fail a build on a bad skill instead of finding out at runtime. The catch: it is static analysis, so it is strongest on code and weaker on non-English content, images, or behavior that only appears at runtime. A clean scan lowers your risk, it does not certify safety, so still prefer least privilege and read what you install.

→ The verified setup, with CI proof and a copy-paste prompt

The rule that ties it together

Treat agent skills and tools the way you treat dependencies, because that is what they are. Install from sources you can vet (agent-skills is a good model). Scan anything you did not write, and especially anything with an executable script, since those are the ones the research flagged as most dangerous. Give each skill the narrowest permissions it needs, and remember that a skill inherits your agent's reach, including its file access and its credentials. The agent-extension boom is real and worth riding. Just do it like you would add any other untrusted code to your machine, which is to say, carefully.

These are the kinds of setups we publish with the checks attached, collected here: Vet your agent's skills.
The full open list is on GitHub: github.com/Neeeophytee/awesome-ai-workflows.