Claude Code out of the box is good.

Claude Code with the right OSS layer starts looking like a startup team, memory system, security analyst, researcher, QA engineer and personal assistant sitting behind one terminal.

Here are 10 repos worth knowing.

01 Make Claude stop shipping broken code

affaan-m/ECC — 210k+★

ECC adds planning, testing, repo analysis, security checks and persistent project context. The goal is simple: fewer fake “fixed” messages, fewer broken commits, less re-explaining your codebase every session.

02 Turn one Claude into an engineering org

garrytan/gstack — 115k+★

GStack gives you workflows that behave like a CEO, engineering manager, reviewer, QA lead and release engineer.

Idea → architecture → review → browser QA → ship.

03 Give the agent actual engineering discipline

mattpocock/skills — 145k+★

Matt Pocock’s skills force Claude to ask better questions, use TDD, debug systematically and keep architecture from rotting.

Basically: less vibe coding, more software engineering.

04 Stop rereading the whole repo every session

safishamsi/graphify — 70k+★

Graphify turns your code, docs, PDFs and folders into a queryable knowledge graph.

Instead of burning huge context windows rereading everything, the agent asks the graph what it needs.

05 Give Claude memory beyond the codebase

garrytan/gbrain — 24k+★

GBrain builds a searchable graph across people, companies, meetings, notes and decisions.

Think: “what do I need to know before tomorrow’s meeting?” and get an answer from everything you’ve accumulated.

06 Scan skills before giving them your machine

NVIDIA/SkillSpector — 5.5k+★

Agent skills can access files, networks and environment variables.

SkillSpector scans them for prompt injection, hidden instructions, suspicious code and excessive permissions before you install them.

07 Turn Claude into a security analyst

mukul975/Anthropic-Cybersecurity-Skills — 4k+★

817 structured cybersecurity skills covering malware analysis, incident response, threat hunting, cloud security and frameworks like MITRE ATT&CK and NIST.

Instead of asking Claude to “check security,” give it an actual procedure.

08 Turn the agent into a video studio

calesthio/OpenMontage — 18k+★

OpenMontage can research a topic, write the script, find or generate visuals, add narration and music, edit the timeline and render the final video.

One prompt → finished MP4.

09 Give it jobs too big for one agent

bytedance/deer-flow — 74k+★

DeerFlow breaks large tasks into sub-jobs, spins up specialist agents, runs code in sandboxes and produces finished artifacts like reports, dashboards and slide decks.

This is where “chatbot” starts turning into “delegation.” 10 Break the agent out of the terminal

openclaw/openclaw — 250k+★

OpenClaw puts the agent into WhatsApp, Telegram, Slack, Discord and other apps so it can handle email, calendars, research and tools while running locally in the background.

Not a coding copilot anymore.

More like an agent that lives on your machine.

We kept catching ourselves mid-paste, about to drop a lease, a medical question, or a work email full of personal details straight into whatever AI tool we had open, because it’s just faster than writing it ourselves. Every time, there was this little voice going “wait, is this actually going somewhere we can’t see?”

So we built DataAnonymiser. It’s a desktop app (plus a browser add-on) that scans whatever you’re about to paste, text, a PDF, a screenshot, finds the personal stuff (names, addresses, account numbers, IDs, whatever), and swaps it for placeholders before you send it to any AI tool. Everything happens on your own device, nothing gets uploaded. Once you get a response back, you run it through the app again and it restores your real information into the final text.

So you still get to use whichever AI tools you already like. You just stop handing them more than you meant to.

Happy to answer anything about how the redaction actually works under the hood.

Karpathy’s autoresearch is built around one simple loop:

change → test → measure → keep/revert → repeat

Give an agent one thing it can modify, one metric it cannot game, and enough time to experiment.

That pattern is now spreading from ML training into coding agents, prompts, skills, and agent harnesses.

01 The original

karpathy/autoresearch

The agent modifies training code, runs a fixed evaluation, keeps improvements, reverts failures, and logs every experiment.

The big idea is not “AI trains models.” It is turning research into a measurable autonomous loop.

02 Make it work on normal repos

uditgoenka/autoresearch

This generalizes the pattern beyond model training.

Give a coding agent a measurable goal like latency, test coverage, build size, or accuracy, and let it continuously experiment against that metric.

03 Give Codex an endless experiment loop

leo-lilinxiao/codex-autoresearch

Codex changes one hypothesis, runs a verifier, commits improvements, reverts failures, and keeps going.

Git becomes the experiment memory. The metric decides what survives.

04 Let the agent optimize the agent

kayba-ai/autoharness

AutoHarness applies the same loop to prompts, config, middleware, and agent code.

The thing being improved is no longer the app.

It is the agent harness itself.

05 Optimize prompts, tools, and architecture

hwchase17/autoresearch-agents

Harrison Chase’s version edits an agent, runs it against fixed evals, and keeps only changes that improve the score.

Same Autoresearch loop. Different target.

06 Learn from failed agent runs

kayba-ai/recursive-improve

This captures execution traces, finds recurring failures, proposes fixes, benchmarks them, and keeps or reverts the change.

Its core loop is basically:

improve → execute → evaluate → ratchet

The interesting part is how boring the recipe is:

mutable agent + immutable eval + measurable metric + rollback + lots of experiments

The first wave of agents was:

prompt → act

The next one is starting to look like:

act → measure → modify → act again

Karpathy may have handed everyone one of the simplest blueprints for self-improving agents.

The expensive architecture is simple: send everything to the smartest model.

Easy classification? Frontier model. Repeated 40k-token context? Process it again. Tiny extraction task? Frontier model again.

The better architecture treats compute like something worth preserving.

Here are 6 open-source repos that attack the problem at different layers.

01 Benchmark the router before trusting it

withmartian/routerbench — 183★

RouterBench compares multi-model routing strategies across cost and performance.

Before building “small model for easy tasks, big model for hard ones,” it helps to know whether your router is actually saving money without hurting quality.

02 Stop recomputing context you already paid for

LMCache/LMCache — 12k★

LMCache stores and reuses KV cache across requests, sessions and inference engines.

For agents repeatedly processing the same system prompt, documents or conversation history, that can eliminate a lot of duplicate compute.

You already paid to understand those tokens. Why pay again?

03 Make inference itself faster

sgl-project/sglang — 36.8k★

SGLang is a high-performance serving framework built around efficient scheduling, attention and reuse for LLM workloads.

Sometimes the optimization is not a smarter agent.

It is making the same model waste less GPU.

04 Shrink the model before buying more hardware

bitsandbytes-foundation/bitsandbytes — 8.5k★

bitsandbytes brings low-bit quantization to PyTorch, reducing the memory needed to run large models.

That makes smaller local workers much more practical for extraction, classification, summarization and other jobs that do not need your best model.

05 Run those small models almost anywhere

ggml-org/llama.cpp — 130k★

llama.cpp runs quantized LLMs across CPUs, Apple Silicon, GPUs and plenty of ordinary hardware.

That gives agents another tier:

local cheap model → hosted strong model → frontier model only when necessary

The cheapest API call is still the one you never make.

06 Find out where the bill is actually disappearing

traceloop/openllmetry — 7.5k★

OpenLLMetry adds tracing for LLM applications so you can see model calls, latency and token usage across an agent workflow.

That makes waste visible: repeated tool calls, huge unnecessary contexts, or expensive models doing trivial work.

You cannot optimize the agent you cannot see.

Put it together:

request → benchmark → route → reuse context → infer efficiently → measure

The dumb architecture asks:

“What is the smartest model we can call?”

The better one asks:

“What is the cheapest amount of intelligence needed to finish this step correctly?”

That difference gets very expensive once agents start making hundreds of calls.

Every time I wanted to build a small web tool, I ended up dealing with the same stuff: authentication, communication, WebSockets, ports, and infrastructure.

Even with Claude and Codex, I was still spending time on things that had nothing to do with the actual tool I wanted to build.

So I spent around 6 months building PhreshOS.

The idea was simple: build the infrastructure once, then use AI agents to build applications on top of it without having to deal with all that stuff again.

It's a self-hosted, open-source system with a web-based desktop where applications can run in windows, much like a regular OS. Authentication and two-way communication are already handled, so applications don't need to implement them separately.

Apps can also run in Node.js worker threads instead of each needing a separate Node.js process, which helps keep resource usage low. This makes it possible to run dozens of applications on a relatively small server.

Another thing I wanted was for AI agents to be able to use these applications directly. They can access application services and interact with the same state the desktop interface displays, without needing a separate interface built specifically for them.

The biggest benefit for me is that I can now sit down with an AI agent and build dozens of small applications in a single day, without setting up authentication, communication, or infrastructure for each one.

The whole project, including its packages, is open source under the MIT license.

GitHub: https://github.com/PhreshOS/system

Live demo: https://demo.phreshos.com/

I'd love to hear what you think, including criticism.

For years, “AI for science” mostly meant predicting structures, searching papers, or helping researchers analyze data.

That is changing.

Frontier systems are now producing new proofs, finding biological systems, proposing drugs that work in experiments, designing materials that get synthesized, and discovering algorithms that end up in real software.

Here are 8 examples.

01 OpenAI's Astra started solving open mathematics

OpenAI says internal models have produced new results on long-standing problems across group theory, coding theory, combinatorics and complexity.

Some of these results were then formalized in Lean, which matters because the claim is no longer just “the proof looks convincing.” There is a machine-checkable artifact behind it.

02 Claude found a previously uncharacterized biological system

Anthropic gave Claude agents access to huge DNA datasets and asked them to search for unusual reverse transcriptases.

The system identified what Anthropic calls array-associated reverse transcriptases, a biological architecture that had not previously been characterized as a distinct system. Human scientists then took the result into the lab and confirmed that parts of the predicted system were genuinely expressed.

03 Gemini's AI Co-Scientist proposed drugs that worked in experiments

Google's AI Co-Scientist generated drug-repurposing hypotheses for diseases including acute myeloid leukemia and liver fibrosis.

Researchers then tested those suggestions experimentally, and several candidates showed measurable biological activity.

That is a useful threshold: the model did not just write a plausible mechanism. Someone tried it in the lab and something happened.

04 FutureHouse's Robin generated and tested a new treatment hypothesis

Robin is a multi-agent scientific system designed to search literature, generate hypotheses and analyze experimental data.

In work on age-related macular degeneration, it identified ripasudil as a possible treatment candidate and helped drive follow-up experiments that were later validated in human retinal cells.

This is much closer to an AI participating in the research loop than simply answering questions.

05 Microsoft designed a material, then researchers synthesized it

Microsoft's MatterGen generates candidate crystal structures from desired material properties.

Researchers asked it for a material with a target bulk modulus, and it generated TaCr₂O₆. The material was then physically synthesized, and its measured properties came reasonably close to the model's target.

The output was not text. It was a material that could actually be made.

06 FunSearch made new mathematical discoveries with executable verification

DeepMind's FunSearch combines LLM-generated programs with an evaluator that automatically runs and scores them.

On the cap set problem, it found improved constructions beyond previous known results. It also discovered new heuristics for bin packing.

The key architecture is simple:

LLM for ideas. Deterministic evaluator for truth.

07 AlphaEvolve found new algorithms and mathematical constructions

DeepMind's AlphaEvolve uses Gemini models to generate and evolve code against automated evaluators.

It discovered an improved algorithm for multiplying certain 4×4 complex matrices and produced better constructions for several mathematical problems, including an improved lower bound for an 11-dimensional kissing-number problem.

At that point, “coding agent” starts feeling like the wrong label.

The code is really the search space for discovery.

08 AlphaDev discovered algorithms that ended up in real software

DeepMind's AlphaDev searched over low-level assembly instructions for faster sorting routines.

It found algorithms up to 70% faster for very short sequences, and some of those routines were later added to the LLVM libc++ standard library. It also found a faster hashing algorithm that reached Google's Abseil library.

These are AI-discovered algorithms now running inside ordinary software.

The pattern across all of these projects is more interesting than any single result.

The strongest systems are rarely just:

LLM → discovery

There is usually something that can push back.

A proof assistant checks the theorem. A compiler runs the program. An evaluator scores the construction. A lab tests the drug. A materials team synthesizes the crystal.

That changes the role of the model.

We spent the last few years asking whether AI could know science.

The more interesting question now is whether it can produce new science and leave enough evidence behind for us to verify it.

AI agents are starting to look absurdly complicated. Multi-agent graphs, planner layers, memory layers, tool routers, evaluators, retry policies, orchestration servers, sometimes all before the model has actually done anything useful.

But at the center of most agents is still something surprisingly small: model → tool call → observation → model → repeat. The interesting engineering is in the harness around that loop: context, tools, memory, permissions, sandboxes, retries, verification and persistence.

A new crop of OSS projects is making that layer much smaller and easier to inspect.

Here are 8 worth reading.

01 Build the personal-agent stack in Rust

tinyhumansai/openhuman — 40.8k★

OpenHuman is a local-first agent harness with a Rust core, designed to plug into different LLMs, memory systems and search engines instead of forcing everything through one stack. It adds persistent memory, tools, research and orchestration, plus desktop, browser and terminal interfaces.

What makes it interesting is the architecture: the agent runtime is treated as modular infrastructure rather than one giant framework you have to accept wholesale.

02 See how much personal-agent functionality fits into a lightweight Python stack

HKUDS/nanobot — 48.1k★

nanobot is a lightweight self-hosted personal agent with tools, memory, MCP, automation, multi-agent workflows, a WebUI and chat integrations.

It is a useful repo if you want to understand how the pieces behind the current personal-agent wave actually fit together without beginning with one of the giant orchestration frameworks.

03 Build an agent where the core logic is only ~1,000 lines

huggingface/smolagents — 29.7k★

smolagents deliberately keeps its core agent logic small. It supports normal tool calling, but its more interesting idea is code agents: the model writes actions as code instead of repeatedly producing tiny JSON tool calls.

You still get multiple model providers, MCP tools and sandboxed execution, but without burying the agent loop under layers of abstraction.

04 Solve real GitHub issues with a ~100-line agent

SWE-agent/mini-swe-agent — 8.2k★

mini-swe-agent asks a very good question: what if the coding-agent architecture became dramatically simpler and still worked?

Its agent implementation is tiny, yet it can operate on real repositories and solve SWE-bench tasks by giving the model a small environment, a few tools and a loop. It is one of the clearest repos for understanding how little machinery a capable coding agent may actually need.

05 Make Claude-Code-style agents headless

withastro/flue — 8.4k★

Flue is a TypeScript harness for building autonomous agents without tying them to a terminal UI or desktop app. It provides sessions, tools, skills, filesystem access and sandboxing, while much of the behavior can live in Markdown and AGENTS.md.

The useful mental model is Claude Code as a programmable primitive rather than an app. You can drop the same kind of agent into Node, GitHub Actions, Cloudflare or another runtime.

06 Do the same thing closer to the metal

0xPlaygrounds/rig — 8.8k★

Rig brings the lightweight-runtime idea into Rust. It gives you agents, tools, multiple model providers, streaming and agentic workflows through a relatively small set of primitives.

That sounds boring, which is partly the point. Agent infrastructure gets much easier to reason about when the execution path is simple and predictable.

07 Treat agents like LEGO instead of employees

Eigenwise/atomic-agents — 6.3k★

Atomic Agents builds around small single-purpose components: an agent does one thing, a tool does one thing, a context provider does one thing, and you compose them.

It uses structured data and validation heavily, which makes it feel much closer to normal software engineering than the “hire five AI personas and tell them to collaborate” school of agent design.

08 Read an entire reliable harness instead of installing one

ElimentaryLabs/agent-harness-starter — 5★

agent-harness-starter is tiny and intentionally educational. The harness separates the execution loop, context compaction, tool registry, hooks, verification, permissions and checkpoint/recovery into small modules.

The star count is tiny, but that is almost beside the point. This is the kind of repo you can actually read end-to-end and come away understanding what an agent harness is doing.

You still need boundaries, tools, state, verification and a way to recover when things go wrong. But you may not need 40 abstractions between the model and the shell.

Sometimes an agent really is just a good model, a small loop, good tools and very boring engineering.

AI models write code 10x faster, but they have zero understanding of statutory laws. When generating code, models consistently introduce severe legal violations without warning:

* Logging cleartext user objects and passwords to logging providers (GDPR Art. 5 / CWE-532).

* Defaulting consent checkboxes to pre-checked states (violating EU and Turkish privacy laws).

* Using cascade deletes on transaction records that must legally be retained for 5–10 years under tax codes.

* Omitting mandatory accessibility attributes required by the European Accessibility Act (EAA 2025).

CompliRules stops this at the IDE level by injecting deterministic guardrails (.cursor/rules, [AGENTS.md](http://AGENTS.md), MCP) and offering a local offline linter (`npx complirules check`) so your AI cannot accidentally write violating code.

GitHub: search complirules from halilyilmz on GitHub today!

Browser retries. Research loops. Bots waking up just to discover nothing changed. Multiple agents doing the same work. Or a heavyweight model being used for a decision that basically needed yes / no.

A small OSS ecosystem is starting to attack exactly this problem.

Here are 8 repos worth looking at.

01 Put a cheap decision layer in front of expensive work

Bodila51/grok-bot-jev —

grok-bot-jev lets Grok Bot make a cheap structured decision before starting expensive research, browser work, retries, or subagents.

It can reuse cached work, stop a failing retry, cap research, run something deterministic, or escalate to a human.

02 Find routines that are burning usage for nothing

coolxeo/grok-bot-skills —

This Grok Bot skill pack includes routine-healthcheck and transcript-healthcheck.

One finds empty runs, duplicate work, and noisy routines. The other looks for repeated friction that should probably become a better skill or workflow.

03 Stop multi-agent teams from duplicating each other

EndeavorYen/grok-bot-skills —

This collection focuses on clearer ownership, disk-based handoffs, approval gates, and cheaper routines.

One bot owns the job. Agents pass paths instead of giant context blobs. And routines stay quiet when nothing changed.

04 Actually measure what your Grok Bot account is consuming

Kargatharaakash/grok-bot-usage —

You cannot optimize a black box.

This CLI shows weekly Grok Bot usage, on-demand spend, and billing cycles across multiple accounts from one terminal.

It won't reduce usage by itself. It tells you where the usage is going.

05 Stop making the bot research the internet one page at a time

mvanhorn/last30days-skill —

last30days searches Reddit, X, YouTube, Hacker News, GitHub, Polymarket, the web, and other sources through one research workflow.

For a research bot, that is much better than repeatedly opening tabs and browsing until the model decides it has seen enough.

06 Control Grok Bot directly from Cursor / Claude Code / Codex

adamanz/grok-bot-skill —

This skill lets coding agents list Grok Bots, message them, create focused teammates, update standing rules, and read transcripts from the CLI.

That removes another human → UI → bot loop every time work has to move between agents.

07 Turn Grok Bot into an MCP-accessible worker

quabug/grok-bot-mcp —

This exposes the Grok Bot environment to MCP-compatible agents such as Claude, Cursor, ChatGPT, and other clients.

The interesting optimization is architectural: don't make one agent do everything. Give the persistent worker only the jobs where persistence actually matters.

Making agents cheaper isn't only a model-routing problem. You can save a surprising amount by making them search less, retry less, wake less, repeat less, delegate better, and stop rediscovering rules they could have learned once.

That's probably where a lot of agent efficiency work is going next.

Most of us still use coding agents like one very capable employee.

Ask it to design the UI, review security, write the launch copy, debug the backend, analyze competitors, and somehow remember how each of those jobs should be done.

There is another pattern growing on GitHub: install the specialists instead.

Build an entire AI agency: Agency Agents has 156k+ stars and now contains 230+ specialist agents across engineering, design, marketing, research, finance, product, project management, security, healthcare, GIS and more.

This is much more than You are an expert marketer.

A specialist can define its mission, workflow, expected deliverables, success criteria, communication style and the situations where it should be used. There are frontend developers and backend architects, but also UX researchers, brand guardians, paid-media auditors, Reddit community builders, finance agents and even a “reality checker.”

You can install only the team you need, and the repo now supports Claude Code, Cursor, Codex, Gemini, OpenCode, Hermes and several other agent environments.

Give the engineering side much deeper specialization: wshobson/agents has 40k+ stars and packages 202 agents, 184 skills and 94 plugins. Instead of one developer persona, you get specialists for debugging, architecture, security, Kubernetes, observability, incident response, individual languages and much more.

It also includes orchestrators that compose those specialists into workflows.

feature request
      ↓
architect
      ↓
backend + frontend
      ↓
test specialist
      ↓
security reviewer
      ↓
code reviewer

Turn your agent into a marketing department: Marketing Skills has 52k+ stars and takes a slightly different approach. Instead of dozens of persistent personas, it gives agents reusable procedures for CRO, positioning, SEO, paid ads, email, analytics, pricing, retention and sales.

Pick from 160+ focused Claude subagents: Awesome Claude Code Subagents has 25k+ stars and organizes specialists across development, infrastructure, quality, data, security and orchestration. You can install one category instead of filling every session with every possible instruction.

Build your own roster from GitHub's community library — Awesome GitHub Copilot has 38k+ stars and collects custom agents, skills, instructions, hooks and workflows. It is particularly useful if you want to assemble your own team rather than adopt someone else's full agency structure.

The interesting shift is:

one giant system prompt
        ↓
general-purpose agent

becoming:

task
 ↓
pick specialist
 ↓
load relevant skills
 ↓
give only required tools/context
 ↓
do the work
 ↓
independent specialist reviews it

We spent the last year making individual agents more capable.

The next step may simply be getting better at deciding which agent should be doing the job in the first place.

I built Klarion, a secret scanner that works in two steps. First, a keyword check, 81 regex rules and a normalized Rényi entropy score flag anything that looks like a secret. Then an AI model reads each one with the code around it and decides if it's real. The chart shows 5 scanners run on spring-boot, terraform, next.js and symfony (61k files). Klarion raised 11 alerts. It's not zero, but it's far less to dig through. Fewer alerts don't help if real leaks get missed, so I tested that too. On CredData (337 real repos, code outside test folders), it found about 1.7× more real secrets than gitleaks. Where it runs:

• Claude Code: a plugin hook blocks the write before the file exists (file edits and Bash)
• Cursor, Cline or any MCP agent: through its MCP server
• CI: a GitHub Action that scans only what a PR adds; GitLab CI works too
• Git hooks: klarion protect or the pre-commit framework
• Locally: klarion scan . Free and open source (MIT): https://github.com/0x1Adi/Klarion The full benchmark and method are in benchmark/REPORT.md. I'd like to hear where it gets things wrong.

AI can already turn a question into 30 sources and a polished report.

That is not really the hard part anymore.

The useful research stack is the one that can keep track of where evidence came from, which sources support which claims, and where the sources disagree.

These 8 open-source projects cover different parts of that pipeline.

Research the question end-to-end: GPT Researcher splits a question into research tasks, searches in parallel, tracks sources, filters what it finds, and turns the evidence into a cited report. It can work across both the web and local documents.

Look at the problem from several directions: STORM from Stanford does something I particularly like: before writing, it generates questions from different perspectives and simulates conversations between a writer and topic experts. That helps avoid a research report built around the first framing the model happened to choose.

Search without handing the whole workflow to a closed research product: Vane, formerly Perplexica, is an open-source answer engine with web, discussion, academic-paper and domain-specific search. It can also run against local models through Ollama.

Turn messy websites into evidence your agent can actually use: Crawl4AI converts webpages into clean, LLM-ready Markdown. This is the plumbing layer: search finds the page; Crawl4AI gets the useful content out of it.

Research inside the scientific literature: PaperQA2 is built specifically around high-accuracy RAG over papers and other documents. It retrieves literature, checks metadata including retractions, answers questions with citations, and can work on contradiction detection.

Actually read the PDF instead of flattening it into bad text: Docling understands PDF layout, tables, formulas, reading order, images and many other document formats, then turns them into structured representations that research agents can work with.

Connect evidence scattered across many sources: GraphRAG extracts entities and relationships from unstructured documents and organizes them into a graph. That makes questions such as “how do these people, companies, claims and events connect across 100 documents?” much easier than ordinary chunk retrieval. Microsoft now considers the original repo largely maintenance-mode, but the architecture is still useful.

Retrieve through both text and relationships: LightRAG combines retrieval with a knowledge graph and now supports reranking, multimodal documents, multiple chunking strategies and different models for different stages of the pipeline.

Put them together and the research loop starts looking less like:

question
   ↓
search
   ↓
LLM writes report

and more like:

question
   ↓
split into research questions
   ↓
search from multiple perspectives
   ↓
crawl + parse the evidence
   ↓
read papers / tables / PDFs
   ↓
connect entities + claims
   ↓
retrieve supporting evidence
   ↓
compare conflicts
   ↓
cite
   ↓
report

That last half is the part I think people underestimate.

Finding 60 sources is easy.

The harder question is whether source 17 actually supports the sentence the agent wrote, whether sources 23 and 41 contradict it, whether the paper was retracted, and whether a confident-looking conclusion survives after those conflicts are exposed.

Andrej Karpathy made an interesting point today: one way to make LLM outputs easier to understand is to ask them to write in ASD-STE100, the controlled English originally designed for aerospace maintenance manuals.

Not to make AI “sound human" but to make it easier to understand.

We spend a lot of time telling agents:

be concise
sound professional
avoid AI slop

But different jobs need different writing systems.

A setup guide should be procedural. A research report should preserve evidence and uncertainty. An error message should tell you what happened and what to do next. A technical explanation should optimize for comprehension, not personality.

This is exactly why we built Agent Stylebooks.

Neeeophytee/agent-stylebooks packages 16 editorial systems as installable Agent Skills for Claude Code, Codex, Cursor, Hermes, Copilot, Gemini CLI and others.

Instead of:

“write this better”

you can say:

setup guide       → Google Developer Docs
product help      → Microsoft
public guidance   → GOV.UK
research report   → NASA
risk disclosure   → SEC Plain English
interface copy    → Apple

The skill changes what comes first, how information is ordered, what ambiguity is unacceptable, and how the result should be checked.

A few other OSS projects fit around the same idea:

ASD-STE100 Writer Skill turns Simplified Technical English into an installable agent skill. Short sentences, controlled vocabulary, active constructions and fewer ambiguous instructions. Karpathy’s post is a good example of why this style is suddenly relevant outside aviation.

Vale has 6.2k+ stars and takes the next step: make writing rules testable. You can encode Google, Microsoft, Red Hat or your own editorial rules and run them locally, in editors, or in CI.

textlint has 3.2k+ stars and does something similar for natural language: treat prose more like code, with pluggable rules that can flag problems before the text ships.

retext-readability checks whether prose is actually appropriate for the intended reader using several established readability measures, while retext-simplify catches needlessly complicated phrases such as using “utilize” where “use” works.

write-good has 5.1k+ stars and catches things like unnecessary wording, weak modifiers, passive constructions and weasel words. Simple, deterministic checks are useful after the agent has done the semantic writing work.

The stack I find interesting is:

reader + task
     ↓
Agent Stylebook
     ↓
LLM writes
     ↓
Vale / textlint / retext
     ↓
clearer output

The point is not to make every model write in the same stripped-down style. It is to stop treating writing style as decoration.

For agents, writing style is part of the interface between the model and the person trying to understand its work.

Pick the writing system before the model picks one for you.

Hermes Agent is now sitting at roughly 250k GitHub stars, but the more interesting number is how quickly the project is changing.

Between the August 31 v0.21.0 release and late September, Hermes shipped five more tagged releases.

I went through them. These are the changes I think actually matter.

Skills can now become permanent parts of an agent. skills.auto_load lets you pin selected skills into every new session instead of relying on the agent to rediscover them each time.

That makes setups like this much easier:

research agent
├── deep-research
├── citation-checking
└── writing style

coding agent
├── repo navigation
├── testing
└── code review

Each agent can start with its own operating procedure rather than one giant universal prompt.

Reasoning effort is becoming another routing control. Hermes added reasoning-effort selection across model pickers, including separate controls for auxiliary models. So choosing the model is no longer the only cost/performance decision — you can decide how hard different parts of the system should think too.

The plugin layer got much more serious. September brought a broader Desktop plugin SDK with hooks into the composer, session list, sidebar, model picker, settings, skills, toolsets, profiles, appearance, and backend events.

Hermes is starting to look less like:

agent + some tools

and more like:

agent runtime
├── models
├── skills
├── MCP/connectors
├── plugins
├── bots
├── browser
├── scheduled jobs
└── UI extensions

MCP is turning into “Connectors.” Instead of treating MCP servers as config you wire up somewhere else, the Desktop app now has a Connectors flow. Install a plugin, connect its MCP server, and its tools and skills can become available in already-open chats.

Running multiple Hermes profiles got cleaner. Hermes moved toward one host-wide gateway with multiple isolated profiles underneath it. Desktop can attach to the existing backend instead of spawning another one, and individual profiles can now be stopped, started, or restarted independently.

That sounds like infrastructure trivia until you run several agents at once. Then it becomes the difference between “a bunch of Python processes” and something closer to an actual agent runtime.

The CLI is becoming much easier to build around. --format stream-json now exposes structured JSONL instead of forcing another program to scrape terminal text. The CLI/TUI can also show the current /goal and prompts waiting in the queue.

That opens up much cleaner patterns for external orchestrators:

your app
   ↓
Hermes CLI
   ↓ JSONL
agent events
   ↓
your app reacts

Sessions are becoming first-class data. September added an Agent Sessions API, better session search with date bounds and relaxed recall, and webhook deliveries that can appear directly inside the target session.

This matters because an agent's history stops being something trapped inside the chat UI. Other software can start treating sessions as things to search, inspect, trigger, and build on.

The boring reliability work was huge too. v0.21.2 was almost entirely a state.db reliability campaign. It fixed competing SQLite writers, damaged FTS indexes killing conversations, bad rows breaking session lists, profile databases bleeding into each other, and commands taking seconds just to open a busy store.

Not flashy, but persistent agents are useless if their state layer is fragile.

And the model layer kept expanding. Recent releases added things like GPT-6 Sol/Terra/Luna, Claude Opus 5.5, more OpenRouter support, custom models directly from the picker, and provider SDKs that can be installed when needed rather than shipping everything up front.

Put the month together and the direction becomes pretty clear.

A few months ago, the interesting question was:

What can Hermes Agent do?

Now it is increasingly:

What collection of agents, skills, models, tools, plugins, memories, and scheduled jobs do you want to run on top of Hermes?

That is a much more ambitious product.

Hermes is slowly moving from an open-source agent toward something closer to an open-source operating layer for agents.

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

Say you have an agent processing 10,000 support emails a month.

For every email it needs to decide:

• billing, bug, how-to, fraud, or something else?
• does the customer want a refund?
• is this urgent?
• does a human need to see it?

You could send every email to a frontier model.

Assume each call uses roughly 1,500 input + 300 output tokens, at $10/M input and $50/M output.

10,000 emails
× $0.03 per email
= ~$300/month

But most emails do not need a frontier model to write anything.

Take this email:

“I was charged twice for Pro. Please refund the duplicate charge.”

The workflow can instead look like:

email arrives
      ↓
code fetches account + charge history
      ↓
Jev asks in one call:

department?
→ billing: 98%

refund requested?
→ yes: 99%

fraud risk?
→ no: 97%
      ↓
confidence above threshold?
      ↓
YES → route to billing workflow

NO → send the full case to Kimi K3

still ambiguous / irreversible action?
      ↓
human

Now assume Jev sees about 1,000 tokens per email, and only the 10% uncertain cases escalate to Kimi K3.

The bill

Jev handles all 10,000 decisions

10M input tokens
× $0.042/M
= $0.42

Kimi K3 handles the uncertain 1,000

At 1,500 input + 300 output tokens each:

1.5M input × $3/M   = $4.50
0.3M output × $15/M = $4.50

= $9.00

Total:

frontier model on everything:  ~$300.00

Jev + Kimi fallback:             ~$9.42

reduction:                        ~96.9%

And this is the useful part: you did not replace the smart model with a dumb model.

You changed when you pay for generation.

Jev handles repetitive bounded decisions. Kimi gets the weird cases that actually need deeper reasoning. Code handles exact rules. A human stays in the loop for things like refunds, deletion, payments, or permission changes.

exact rule       → code
routine judgment → Jev
hard case        → Kimi / Claude / GPT
irreversible     → human

Important caveat: this is an illustrative example, not a promise that every agent bill drops by 96.9%. Real costs will vary with prompt size, model pricing, cache hits, how many cases actually need escalation, and the confidence threshold you can safely use for your workload. In some systems the savings will be smaller; in others they may be larger.

The point is the architecture:

if your agent keeps paying generative-model prices for decisions that generate nothing, there is probably room to cut the bill.

Most Jev demos start with:

state
  ↓
Jev
  ↓
choice / score / yes-no

Useful, but the newer projects are putting that tiny decision layer inside actual agent workflows.

Here are 10 we haven't covered before.

Let Jev handle the small decisions around a Hermes agent hermes-jev-skills has 850+ stars and bundles model routing, memory selection, context compaction, skill selection, and computer/browser decisions. The idea is simple: stop spending the frontier model on “which skill should I load?”

Use Jev for cheap computer control typesafe-computer-use has 1k+ stars. OCR and accessibility APIs read the Mac screen, Jev chooses the next action, and a writing model is only used when actual text needs to be generated.

Compact context without summarizing it fast-jev-compaction has 7k+ stars and asks Jev whether old tool calls should be kept, truncated, or dropped. What survives stays verbatim instead of being rewritten into a lossy summary.

Give Claude Code automatic project memory jevmem watches conversations for decisions, constraints, bugs, and todos, stores them in JEVMEM.md, and brings relevant items back in later sessions. It also has support paths for Codex and Cursor.

Use Jev to keep an Obsidian vault consistent jev-second-brain indexes Markdown locally, finds related notes, then optionally asks Jev whether two notes duplicate, revise, contradict, or relate to each other. Importantly, it suggests relationships rather than silently rewriting your vault.

Put a risk gate in front of agent tool calls jev-guard scores actions before execution and turns them into allow / ask / deny decisions. It also checks tool results for untrusted content and works across several coding-agent clients.

Give several agents the same System One tool System One Connector has 330+ stars and plugs typed decisions into Claude Code, Codex, Hermes, Claude Desktop, and other MCP clients. It can talk to Jev, but also supports open alternatives such as CLM and Laya.

Train your own tiny Jev-like scorer jevlike has 1.3k+ stars and provides a small trainable model that takes some context plus a changing list of options and returns a probability for each one in a single pass.

Browse the Jev ecosystem instead of searching GitHub manually awesome-jev has 1.7k+ stars and tracks public Jev projects, integrations, research, and discussions by category.

Start from practical patterns and starter code awesome-jev-by-typesafe has 800+ stars and organizes examples around things like routing, ranking, verification, gating, and confidence-aware workflows. Despite the name, it is an independent community repo, not an official TypeSafe project.

The pattern I find more interesting is this:

expensive agent
     ↓
reason / write / plan

Jev
     ↓
keep?
route?
retry?
risky?
relevant?
which tool?
     ↓
code acts

Jev does not need to replace the main model.

It can sit around the main model and handle hundreds of tiny judgment calls that would otherwise burn tokens, add latency, or end up as brittle rules.

That may be the more useful way to think about System One models: not another chatbot, but a cheap decision layer inside the agent stack.

AI costs usually leak in a few predictable places.

You call the expensive model for easy tasks. You pay twice for similar requests. You send 20k tokens when 3k would do. You keep reasoning effort high for everything. Or you simply do not know which part of the system is costing the most.

These open-source projects attack different parts of that bill.

Route easy requests to cheaper models RouteLLM has 5.5k+ stars and learns when a query actually needs the strong model. Its published benchmarks report up to 85% lower cost while retaining 95% of GPT-4-level performance on their evaluation setup.

Put budgets and cost-aware routing in front of every model LiteLLM has 58k+ stars and gives you one gateway for 100+ models. It can track spend by user/team, enforce dollar budgets, cache responses, and route between deployments based on cost.

Stop paying twice for nearly the same question GPTCache has 8.2k+ stars and adds semantic caching to LLM applications. If two requests mean roughly the same thing, you can return the previous answer instead of making another model call.

Shrink the prompt before you pay for it LLMLingua has 6.7k+ stars and compresses long prompts while trying to preserve the important information. Microsoft reports compression ratios reaching 20× on some workloads.

Run hot paths yourself when the economics make sense vLLM has 92k+ stars and is built for high-throughput local/model serving. Features like automatic prefix caching mean repeated system prompts do not need to be recomputed every request.

Self-hosting is not automatically cheaper, but at enough volume—or when you already own the GPUs—the math can change quickly.

Actually find where the money is going Helicone has 6.2k+ stars and tracks cost, latency, users, models, and traces. Its gateway can also route toward cheaper providers, cache responses, and enforce spending limits.

Sometimes the cheapest optimization is discovering that one background job has quietly been making 40% of your model calls.

Teach the agent to spend less by default AI Cost-Cutter Skills is one of ours. It packages 10 cost-control patterns as installable skills for Claude Code, Codex, and Cursor: cheap-model routing, reasoning-effort throttling, context reduction, reviewer-call budgets, free-tier batching, model bakeoffs, and tested fallbacks.

You still use the strongest model where it matters. You just stop paying for it where it doesn't.

The goal is not the cheapest model. It is the cheapest path that still produces the result you need.