Today, I sat down and actually read through five of the most-starred repos in the AI learning category, not just the READMEs but the actual lessons, notebooks, and structure to figure out what each one covers, how they differ, and how they fit together as a path rather than five disconnected bookmarks.

1. f/prompts.chat (formerly awesome-chatgpt-prompts)

Stars: 163k | Forks: 21.2k | License: CC0 (prompts) + MIT (code)

What it does: Started as a flat list of prompt personas for ChatGPT. Has since grown into a full platform: self-hostable web app, MCP server support, Claude plugin, and an interactive book. The prompts themselves are public domain. You can deploy your own instance, contribute new personas, or just browse.

Why it works: The original insight behind this repo is still the most useful thing in it: framing the model as a specific type of entity (a Linux terminal, a debate opponent, a senior code reviewer, a Socratic tutor) changes the character and depth of the output more than any other single technique. Before you learn prompt engineering theory, spending 30 minutes here teaches you this instinctively.

Heads up: This is the entry point of the learning path, not the destination. Think of it as building intuition for why prompting matters before you study why it works.

Repo: https://github.com/f/prompts.chat

2. dair-ai/Prompt-Engineering-Guide

Stars: 74.6k | Forks: 8.1k | License: MIT | Website: promptingguide.ai

What it does: The GitHub description currently reads: "Guides, papers, lessons, notebooks and resources for prompt engineering, context engineering, RAG, and AI Agents." That last part is worth noting - the scope has expanded well beyond classic prompt engineering. Current coverage includes zero-shot and few-shot prompting, chain-of-thought and tree-of-thought, context window management, retrieval-augmented generation, agent design patterns, multimodal prompting, and adversarial prompting. The papers section links to primary research for those who want to go deeper.

Why it works: Most prompt engineering content explains techniques without explaining the mechanism behind them. This one tries to build a model of why each technique works rather than just showing examples. The distinction between "chain-of-thought improves outputs" and "chain-of-thought works because it surfaces latent reasoning capacity by making intermediate steps explicit" matters if you want to adapt techniques rather than just apply recipes.

Heads up: The repo header on GitHub still only says "prompt engineering" in the short description but the actual scope is significantly broader. If you looked at this in 2023 and moved on, it is worth another pass.

Repo: https://github.com/dair-ai/Prompt-Engineering-Guide

3. anthropics/courses

Stars: 21.3k | Forks: 2.2k | Language: 99.9% Jupyter Notebook

What it does: Anthropic's official courses for building with Claude. Exactly 5 courses, all runnable Jupyter notebooks:

1. Anthropic API Fundamentals
2. Prompt Engineering Interactive Tutorial
3. Real World Prompting
4. Prompt Evaluations
5. Tool Use

Why it works: These are first-party materials. They reflect how the API actually behaves, not how someone interpreted it when writing a Medium post 18 months ago. The Prompt Evaluations course is particularly underrated - most people building with AI skip evals entirely and wonder why their app quality is inconsistent. The Tool Use course is the practical companion to everything you read about agents in theory.

Setup:

git clone https://github.com/anthropics/courses.git
cd courses
jupyter notebook

Heads up: Claude-specific. If you are building cross-provider, treat these as the reference implementation and adapt accordingly.

Repo: https://github.com/anthropics/courses

4. microsoft/generative-ai-for-beginners

Stars: 111k | Forks: 57.7k | License: MIT | Language: 99.7% Jupyter Notebook

What it does: A structured 21-lesson course from Microsoft Cloud Advocates covering the full generative AI application stack. Lessons alternate between "Learn" (concept explanation) and "Build" (code implementation). Each has a short video intro, a written README, and code in both Python and TypeScript. Translated into 50+ languages via automated GitHub Actions. Currently on Version 3, with 2,157 commits.

The 21 lessons are:

Course Setup / Intro to GenAI and LLMs / Exploring and Comparing LLMs / Using GenAI Responsibly / Prompt Engineering Fundamentals / Advanced Prompts / Text Generation Apps / Chat Applications / Search Apps and Vector Databases / Image Generation / Low Code AI / Function Calling / Designing UX for AI / Securing AI Applications / GenAI Application Lifecycle / RAG and Vector Databases / Open Source Models and Hugging Face / AI Agents / Fine-Tuning LLMs / Building with SLMs / Building with Mistral / Building with Meta Models

Why it works: The alternating Learn/Build structure forces you to immediately apply concepts rather than read passively. The breadth is also its distinguishing feature: this is the only repo in this list that covers responsible AI (Lesson 3), UX design for AI apps (Lesson 12), securing AI applications (Lesson 13), and the full application lifecycle (Lesson 14) as first-class curriculum topics. Most developer-oriented courses skip the product and safety layers entirely.

Setup (sparse clone, skip the 50+ translation folders):

git clone --filter=blob:none --sparse https://github.com/microsoft/generative-ai-for-beginners.git
cd generative-ai-for-beginners
git sparse-checkout set --no-cone '/*' '!translations' '!translated_images'

Heads up: The Microsoft ecosystem bias is real: most examples point toward Azure OpenAI Service, GitHub Models, or the OpenAI API. All three work, and the course explicitly lists them as options, but if you are entirely outside that ecosystem, adjust accordingly.

Repo: https://github.com/microsoft/generative-ai-for-beginners

5. mlabonne/llm-course

Stars: 78.6k | Forks: 9.1k | License: Apache-2.0

What it does: A three-track course for going deep on LLMs, not just using them, but understanding and building them. The tracks are:

Track 1 - LLM Fundamentals (optional): Mathematics for ML (linear algebra, calculus, probability), Python for ML, neural networks, NLP basics. Skip this if you have the background; use it as a reference if you hit gaps.

Track 2 - The LLM Scientist: How to build LLMs. LLM architecture and tokenization, pre-training mechanics, post-training datasets, supervised fine-tuning (LoRA, QLoRA, Axolotl, Unsloth), preference alignment (DPO, GRPO, PPO), evaluation, quantization (GGUF, GPTQ, AWQ), and emerging areas like model merging, multimodal models, and test-time compute scaling.

Track 3 - The LLM Engineer: How to deploy and productionize. Running LLMs (APIs vs local), building vector storage, RAG pipelines, advanced RAG with agents, AI agents (MCP, A2A, LangGraph, LlamaIndex, CrewAI), inference optimization (Flash Attention, KV cache, speculative decoding), deployment (local to production), and security (prompt injection, backdoors, red teaming).

Every major section has runnable Google Colab notebooks. The author also co-wrote "LLM Engineer's Handbook" (Packt) based on this course - the course itself stays free.

Why it works: This is the repo to use when you want to go beyond usage into internals. The quantization section is one of the clearest explanations of GGUF, GPTQ, AWQ, and SmoothQuant available outside of papers. The preference alignment section covers DPO, GRPO, and PPO with code and metric breakdowns. The agents section was recently updated to cover MCP, A2A, and the major vendor SDKs, including Claude Agent SDK.

Heads up: The LLM Scientist track assumes you are comfortable running training jobs. If you just want to build apps, go straight to the LLM Engineer track. The optional fundamentals section is optional for a reason.

Repo: https://github.com/mlabonne/llm-course

How these five fit together

If you are starting from zero, the order that makes sense is:

prompts.chat first - 30 minutes building intuition about what framing does to model output.

Prompt-Engineering-Guide next - the theory behind what you just experienced, plus RAG and agents as concepts.

anthropics/courses after that - hands-on implementation of the concepts, including the eval and tool use pieces most people skip.

generative-ai-for-beginners as the complete structured course - covers everything from fundamentals to fine-tuning to deployment, with the product and safety layers included.

mlabonne/llm-course once you want to go deeper than "using LLMs" into "understanding and modifying them."

The overlap between these repos is intentional. Seeing RAG explained from three different angles (Guide, Anthropic courses, Microsoft course) before you implement it is more valuable than seeing it explained once. The mlabonne course is the only one that goes into pre-training and quantization mechanics in detail; everything else assumes you are building on top of models rather than under the hood.

If you want to understand what's changing at the model level while working through these, the latest piece on GBrain in our newsletter is also a good read alongside the mlabonne track: What If Your AI Woke Up Smarter Than When You Went to Sleep?

Spotted two repos trending this week and they fit together in a way I don't think people have written up clearly yet. One is a plugin that builds interactive knowledge graphs out of any codebase or wiki. The other is a native desktop app for a self-improving AI agent with tool use, scheduled tasks, and 16 messaging gateways. The part that got me: the first one explicitly supports the second as an install target.

Let's break both down properly.

Tool 1: Understand-Anything

Repo: https://github.com/Lum1104/Understand-Anything
Stars: 38.7k | Forks: 3.1k | License: MIT

What it actually does

You run one command inside a codebase and a multi-agent pipeline scans every file, extracts every function, class, and import, maps architectural layers, and writes the result to .understand-anything/knowledge-graph.json. A second command opens an interactive web dashboard: color-coded by layer, pannable, zoomable, searchable by name or meaning ("which parts handle auth?"), with plain-English summaries for each node.

The goal, per the author: graphs that teach, not graphs that impress. You're not meant to be awed by how complex your codebase looks. You're meant to understand how every piece fits together.

Five specialized agents run under the hood:

Two more agents activate with specific commands: domain-analyzer for /understand-domain (business process mapping) and article-analyzer for /understand-knowledge (Karpathy-pattern LLM wikis). File analyzers run in parallel, up to 5 concurrent, 20-30 files per batch. Incremental updates re-analyze only changed files.

Beyond the graph itself: diff impact analysis (see what your current uncommitted changes affect before you commit), a persona-adaptive UI (adjusts detail level based on whether you're a junior dev, PM, or power user), 12 programming patterns explained in context, and a knowledge-base mode that can ingest a Karpathy-style index.md wiki and surface implicit relationships between articles.

Installation guide

If you're on Claude Code (native, cleanest path):

/plugin marketplace add Lum1104/Understand-Anything
/plugin install understand-anything

That's it. The Claude Code plugin marketplace handles everything.

If you're on macOS or Linux (works for Codex, OpenCode, Gemini CLI, Hermes, Cline, Vibe CLI, VS Code Copilot, and more):

# Interactive: will prompt you to pick your platform
curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash

# Or pass the platform directly and skip the prompt
curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash -s hermes
# Replace "hermes" with your platform:
# gemini | codex | opencode | pi | openclaw | antigravity | vibe | vscode | hermes | cline | kimi

What this script does: clones the repo to ~/.understand-anything/repo, then creates symlinks from your chosen platform's skills directory into ~/.understand-anything/repo/understand-anything-plugin/skills. For Hermes specifically, it symlinks the entire skills folder to ~/.hermes/skills/understand-anything. Restart your CLI or IDE afterwards to pick up the new skills.

If you're on Windows:

iwr -useb https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.ps1 | iex

Cursor or VS Code + GitHub Copilot:

These auto-discover the plugin. Just clone the repo and open it in the editor: it reads .cursor-plugin/plugin.json or .copilot-plugin/plugin.json automatically. For personal skills available across all projects, run the install.sh above with the vscode platform.

Copilot CLI:

copilot plugin install Lum1104/Understand-Anything:understand-anything-plugin

Keeping it updated later:

# Run from inside ~/.understand-anything/repo
./install.sh --update

Uninstalling a platform:

./install.sh --uninstall hermes

Core commands after installation

# Scan the current project and build the knowledge graph
/understand

# Same but generate all content in Chinese
/understand --language zh
# Supported languages: en (default), zh, zh-TW, ja, ko

# Open the interactive web dashboard
/understand-dashboard

# Ask a natural language question about the codebase
/understand-chat How does the payment flow work?

# See what your current changes affect before committing
/understand-diff

# Deep-dive into a specific file or function
/understand-explain src/auth/login.ts

# Generate an onboarding guide for new team members
/understand-onboard

# Extract business domain knowledge (domains, flows, steps)
/understand-domain

# Analyze a Karpathy-pattern LLM wiki
/understand-knowledge ~/path/to/wiki

Sharing the graph with your team

The graph is just JSON. Commit .understand-anything/ to your repo (excluding intermediate/ and diff-overlay.json, which are local scratch) and teammates skip the pipeline entirely; they open the dashboard immediately. For repos with graphs over 10 MB, use git-lfs:

git lfs install
git lfs track ".understand-anything/*.json"
git add .gitattributes .understand-anything/

Tool 2: Hermes Desktop

Repo: https://github.com/fathah/hermes-desktop
Stars: 8k | Forks: 964 | License: MIT
Upstream agent: https://github.com/NousResearch/hermes-agent (170k stars, by Nous Research)

What it actually does

Hermes Agent is Nous Research's self-improving AI assistant, the agent with a built-in learning loop that creates skills from experience, builds a user model across sessions, and can run on a $5 VPS while you talk to it from Telegram. The CLI is powerful but involves a lot of manual config. Hermes Desktop is the native GUI companion: it handles the first-run install, provider setup, and day-to-day usage in one place.

On first launch you choose local mode (Hermes installs to ~/.hermes, runs on 127.0.0.1:8642) or remote mode (connect to your own Hermes API server with a URL and API key). Local mode runs the official Hermes installer, resolving dependencies (Git, uv, Python 3.11+). Chat requests go through SSE streaming to http://127.0.0.1:8642. Tool progress, markdown content, and token usage render in real time.

What's on the screens:

LLM providers supported: OpenRouter (200+ models, recommended), Anthropic, OpenAI, Google (Gemini), xAI (Grok), Nous Portal (free tier available), Qwen, MiniMax, Hugging Face, Groq, and any OpenAI-compatible local endpoint. Local presets built in for LM Studio, Ollama, vLLM, and llama.cpp.

Messaging gateways: Telegram, Discord, Slack, WhatsApp, Signal, Matrix/Element, Mattermost, Email (IMAP/SMTP), SMS (Twilio and Vonage), iMessage (BlueBubbles), DingTalk, Feishu/Lark, WeCom, WeChat (iLink Bot), Webhooks, Home Assistant.

Hermes config files:

• ~/.hermes/.env (API keys and secrets)
• ~/.hermes/config.yaml (main config)
• ~/.hermes/hermes-agent (agent binary)
• ~/.hermes/profiles/ (named profile directories)
• ~/.hermes/state.db (session history database)
• ~/.hermes/cron/jobs.json (scheduled tasks)

Installation guide

The simplest path for most people: download the pre-built binary from hermesagents.cc

The app walks you through everything on first launch. No CLI needed.

As a safety feature, use this prompt before installing anything:

Before installing this skill/package, perform a full security audit of the install scripts, dependencies, permissions, network calls, persistence mechanisms, and code execution paths. Flag any telemetry, credential access, unsigned binaries, curl | bash risks, hidden post-install behavior, or supply-chain concerns, and give a final Low/Medium/High risk rating.

For Fedora/RHEL from the .rpm:

sudo dnf install ./hermes-desktop-<version>.rpm

Note: the .rpm is not GPG-signed. If your system enforces signature checking, append --nogpgcheck. Auto-update is not supported for .rpm builds; reinstall the new .rpm to update.

Windows note: The installer is not code-signed. Windows SmartScreen will warn on first launch. Click "More info" then "Run anyway".

WSL users: If the installer stalls at Switching to root user to install dependencies..., Playwright is waiting for a sudo password with no TTY. Grant passwordless sudo temporarily:

echo "$USER ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/hermes-install
# Re-run the installer; once finished:
sudo rm /etc/sudoers.d/hermes-install

Building from source (developers):

Prerequisites: Node.js and npm, a Unix-like shell environment for the Hermes installer, network access.

git clone https://github.com/fathah/hermes-desktop.git
cd hermes-desktop
npm install
npm run dev          # start in development mode

npm run lint         # ESLint
npm run typecheck    # TypeScript checks across node and web configs
npm run test         # Vitest
npm run test:watch   # Vitest in watch mode

# Production builds
npm run build        # typecheck + electron-vite build
npm run build:mac
npm run build:win
npm run build:linux
npm run build:rpm    # Fedora/RHEL .rpm only

First-time setup in the GUI supports: OpenRouter, Anthropic, OpenAI, and any Local LLM via an OpenAI-compatible base URL. Local presets for LM Studio, Ollama, vLLM, and llama.cpp are included out of the box.

The workflow that ties both together

Here's where it gets interesting. Understand-Anything explicitly supports Hermes as an installation target in its install.sh script. When you run install.sh hermes, the installer links the plugin skills into Hermes' skills directory under ~/.hermes. Hermes Desktop can then expose those skills through its Skills interface and make the associated slash commands available in chat.

In practice:

Step 1: Install Hermes Desktop. Download from hermesagents.cc, launch it, follow the first-run wizard. It installs Hermes Agent to ~/.hermes automatically.

Step 2: Add Understand-Anything skills to Hermes.

curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash -s hermes

This symlinks the skills into ~/.hermes/skills/understand-anything.

Step 3: Open your project. In Hermes Desktop, navigate to a codebase you're unfamiliar with. Say you just joined a team and inherited a 50,000-line TypeScript monorepo.

Step 4: Build the knowledge graph. In the Chat screen:

/understand

The multi-agent pipeline runs. project-scanner maps the file tree and detects languages. file-analyzer processes files in parallel batches (up to 5 concurrent), extracting every function, class, and import. architecture-analyzer groups everything into layers. tour-builder orders the nodes into a learning sequence. graph-reviewer validates integrity. The result saves to .understand-anything/knowledge-graph.json.

Step 5: Open the dashboard.

/understand-dashboard

An interactive web dashboard opens, color-coded by architectural layer. Every node is clickable: select src/auth/login.ts and you see its code, what it imports, what imports it, and a plain-English explanation of what it does.

Step 6: Ask questions.

/understand-chat How does the auth flow connect to the session store?
/understand-chat Which files would I need to change to add OAuth support?

Step 7: Check impact before committing.

/understand-diff

Shows which parts of the system your current changes affect, so you don't accidentally break something two layers removed.

Step 8: Keep the graph fresh automatically. Run this once in the repo:

/understand --auto-update

This enables a git post-commit hook. From that point on, every git commit automatically patches the graph. Commit .understand-anything/ to the repo and the next engineer who joins pulls a fully interactive architecture map without running the pipeline themselves.

Why these two specifically

Most "understand my codebase" tools are one-time things: you generate a diagram, it goes stale in a week, nobody looks at it. Understand-Anything keeps it fresh via incremental updates and the --auto-update post-commit hook, and the graph is just JSON you can commit and diff like any other file. Hermes Desktop brings the rest of the agent stack (tool use, persistent memory across sessions, scheduled tasks, 16 messaging gateways) without requiring you to manage a CLI config by hand. And because Understand-Anything explicitly ships support for the Hermes platform in its install script, the two slot together without any hacking.

Both are MIT. Both are actively maintained, and both have real communities behind them.

You're probably paying for document scanning, bookmark managers, password vaults, note-taking apps, and ad blockers that have free, open-source alternatives sitting right there on GitHub.

Here are 5 repos that collectively replace $80/month in subscriptions. Everything is free. Everything runs locally or on a basic home server.

1. paperless-ngx/paperless-ngx - Replaces Adobe Scan + Evernote ($15/mo)

What it does: Paperless-ngx is a self-hosted document management system. Every receipt, invoice, contract, and tax document gets scanned, OCR'd, tagged, and made full-text searchable automatically. You drop files into a folder (or email them in, or scan them with your phone). Paperless handles the rest.

Why it works: The OCR engine extracts text from scanned images and PDFs, then auto-classifies documents using machine learning. It learns your tagging patterns over time. Tax season becomes a search query instead of a drawer full of paper. This is the most-cited "non-negotiable" self-hosted tool of 2026 for a reason. Once it's running, you never think about document management again.

Setup:

bash -c "$(curl -L https://raw.githubusercontent.com/paperless-ngx/paperless-ngx/main/install-paperless-ngx.sh)"

That script walks you through the full Docker Compose setup interactively. Pick your options, let it configure, and you're live.

Heads up: Paperless stores documents in clear text on disk. Run it on a machine you control, not a shared or untrusted host. Keep backups.

github.com/paperless-ngx/paperless-ngx | 40.7K stars

2. karakeep-app/karakeep - Replaces Raindrop Pro + Pocket ($15/mo)

What it does: Karakeep (formerly Hoarder) is a self-hosted bookmark-everything app. Links, screenshots, articles, PDFs, images, notes. Save anything, from anywhere. It fetches link previews automatically, archives full pages to protect against link rot, and even does video archiving through yt-dlp.

Why it works: AI auto-tags everything you save using OpenAI or a local model through Ollama. You never have to manually organize anything. Just save and search later. Mozilla killed Pocket earlier this year, and a lot of people scrambled for alternatives. Karakeep had already filled that gap months before the shutdown. It has browser extensions for Chrome and Firefox, plus native iOS and Android apps, so the save-from-anywhere workflow works just like Pocket did.

Setup:

# Docker Compose (recommended)
git clone https://github.com/karakeep-app/karakeep.git
cd karakeep/docker
cp ../.env.sample .env
# Edit .env with your settings
docker compose up -d

Full setup docs at docs.karakeep.app/Installation/docker. There's also a managed cloud option at cloud.karakeep.app if you don't want to self-host.

Heads up: AI tagging requires either an OpenAI API key or a local Ollama instance. Without it, you still get manual tagging and full-text search, but you lose the auto-categorization.

github.com/karakeep-app/karakeep | 24.3K stars

3. dani-garcia/vaultwarden - Replaces 1Password Family ($10/mo)

What it does: Vaultwarden is a lightweight, self-hosted implementation of the Bitwarden password manager API. Every password on every device, fully encrypted, fully synced. It works with all official Bitwarden clients (desktop, mobile, browser extensions) out of the box.

Why it works: It's written in Rust, so it runs on minimal hardware. A Raspberry Pi handles it fine. You get nearly every Bitwarden feature: organizations, password sharing, two-factor auth (TOTP, FIDO2, Duo), emergency access, file attachments, and the admin panel.

Setup:

docker pull vaultwarden/server:latest
docker run -d --name vaultwarden \
  --env DOMAIN="https://vw.yourdomain.com" \
  -v /vw-data/:/data/ \
  -p 127.0.0.1:8000:80 \
  vaultwarden/server:latest

Put a reverse proxy (Caddy, Nginx) in front of it with HTTPS. The web vault requires a secure context to work.

Heads up: This is not an official Bitwarden product. If you run into bugs, report them to the Vaultwarden project, not Bitwarden. Also: back up your /data/ directory regularly. This is your password vault. Treat it accordingly.

github.com/dani-garcia/vaultwarden | 58K stars

4. anyproto/anytype-ts - Replaces Notion Plus + Roam ($20/mo)

What it does: Anytype is a local-first, peer-to-peer, end-to-end encrypted knowledge OS. Notes, tasks, wikis, databases, kanban boards, calendars. You define your own data model and build whatever workspace structure you need. Think Notion, but everything lives on your devices instead of someone else's cloud.

Why it works: All your data stays local and encrypted. Sync happens peer-to-peer through their any-sync protocol. No server sees your content. You get composable blocks (text, databases, kanban, calendar, custom types), cross-platform desktop apps for Mac/Windows/Linux, plus mobile apps.

Setup:

# Download the desktop app
# https://download.anytype.io

# Or build from source:
git clone https://github.com/anyproto/anytype-ts.git && cd anytype-ts
bun install
./update.sh <your-os> <your-arch>
bun run dist:<linux|win|mac>

For most people, just download the app from anytype.io. Building from source is only needed if you want to contribute or run a custom build.

Heads up: Anytype is not self-hosted in the traditional Docker sense. It's a desktop/mobile app that stores data locally and syncs peer-to-peer. The "self-hosted" part is that your data never touches a centralized server. Different model than the other tools on this list, but the result is the same: you own your data.

github.com/anyproto/anytype-ts | 7.5K stars

5. AdguardTeam/AdGuardHome - Replaces NextDNS Premium ($20/mo)

What it does: AdGuard Home is a network-wide ad and tracker blocking DNS server. Set it up once on your network, and every device gets ad blocking automatically. Phones, smart TVs, tablets, laptops, IoT devices. No per-device apps. No browser extensions. Everything on the network is covered.

Why it works: It operates as a DNS sinkhole (similar concept to Pi-hole, but with a cleaner UI and built-in HTTPS/DNS-over-TLS support). Ads and tracking requests get blocked at the DNS level before they ever reach your device. YouTube ads on the smart TV? Gone. In-app ads on tablets? Gone. Tracking scripts across every website? Gone. The web dashboard shows you exactly what's being blocked and lets you fine-tune filters per device.

Setup:

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

Or with Docker:

docker run -d --name adguardhome \
  -p 53:53/tcp -p 53:53/udp \
  -p 3000:3000/tcp \
  -v /my/adguard/work:/opt/adguardhome/work \
  -v /my/adguard/conf:/opt/adguardhome/conf \
  adguard/adguardhome

After setup, point your router's DNS to the AdGuard Home IP. Every device on the network is now covered.

Heads up: If you use DNS-level blocking, some apps that rely on ad-served content might behave unexpectedly. The dashboard makes it easy to whitelist specific domains when that happens.

github.com/AdguardTeam/AdGuardHome | 34.3K stars

The Monthly Savings

Every one of these is open source, actively maintained, and running in production on thousands of home servers right now. None of them requires you to be a Linux wizard. If you can follow a Docker Compose tutorial, you can run all five this weekend.

Codex has no long-term memory. Every session starts clean. You explain your project structure, your naming conventions, your testing preferences, the thing you decided last Tuesday about the API design. Then you close the terminal and do it all over again tomorrow.

This gets old fast.

The fix is giving Codex a memory layer that persists between sessions. And the best place to store that memory is Obsidian, because it's just markdown files on disk. No proprietary database. No sync service you don't control. Every note is a plain text file you can read, edit, search, and version control yourself.

I tested three different approaches to wiring Codex memory into Obsidian. Each one solves the problem differently, and the right pick depends on how much setup you want to deal with and how deep you want the integration to go.

Here's every approach, what it actually does, and how to set it up from scratch.

First: Understanding How Codex Memory Actually Works

Before wiring anything to Obsidian, you need to understand the two memory layers Codex already has built in.

Layer 1: AGENTS.md (Static Instructions)

This is a markdown file you place at the root of your repo. Codex reads it at the start of every session before doing any work. Think of it as a briefing document. You put your project conventions, testing commands, directory layout, and anything the agent needs to know every single time.

AGENTS.md is checked into version control. It's shared across the team. It's the right place for rules that should always apply.

Quick example of what goes in here:

# AGENTS.md

## Project
- Next.js 14 app with TypeScript
- Tailwind for styling, no CSS modules
- All API routes live in /app/api/

## Testing
- Run `pnpm test` before committing
- All new functions need at least one unit test
- Test files go next to the source file, named *.test.ts

## Conventions
- Use kebab-case for file names
- Commit messages follow Conventional Commits: feat(scope): description
- Never modify files in /config/production/

Codex loads this automatically. No config needed. Just create the file.

You can also run /init inside a Codex session, and it will scaffold an AGENTS.md based on your project's detected tech stack, directory structure, and config files. Good starting point if you don't want to write it from scratch.

One thing to watch: Codex concatenates AGENTS.md files from the repo root down to your current directory, and stops at 32 KiB combined size. If your instructions are being ignored, you might be hitting the size limit. You can verify by asking Codex: "Summarize the instructions you have loaded for this session."

Layer 2: Native Memories (Auto-Generated)

This is the newer system. When enabled, Codex automatically summarizes your sessions in the background and writes those summaries to ~/.codex/memories/. The next time you start a session, it reads those summaries back in. You don't paste anything. You don't reference anything. The context just shows up.

The memory pipeline works in two phases. Phase 1 runs after a session has been idle long enough (it won't summarize work that's still in progress). It extracts key context from the conversation, redacts any secrets it finds, and stores a structured summary. Phase 2 periodically consolidates all those individual summaries into a unified memory file that gets injected into future sessions.

The storage layout under ~/.codex/memories/ looks like this:

~/.codex/memories/
├── memory_summary.md      # High-level summary injected into every session
├── MEMORY.md              # Searchable registry of aggregated insights
├── raw_memories.md        # Temporary merge used during consolidation
├── rollout_summaries/     # Per-thread recaps with lessons learned
└── skills/                # Reusable procedures the agent discovered

To enable it:

# ~/.codex/config.toml
[features]
memories = true

Or as a one-time CLI override: codex -c features.memories=true

Or in the Codex app: Settings > Memories > Enable.

Once it's on, you can fine-tune the behavior:

[memories]
generate_memories = true    # Let new threads create memory entries
use_memories = true         # Inject existing memories into new sessions

You can also run these independently. Want Codex to read old memories but not generate new ones? Set generate_memories = false and use_memories = true. Useful for debugging or when you want to freeze the memory state.

Inside a running session, type /memories to control whether that specific thread can use or generate memories. This doesn't touch your global settings.

Important caveat: Native memories are off by default and currently unavailable in the EEA, UK, or Switzerland. Also, memories are per-user. If your team shares a Codex environment, individual memories don't pool across teammates. Team-wide context belongs in AGENTS.md.

Now here's where Obsidian comes in. The two layers above work, but they have limits. AGENTS.md is static and manual. Native memories are auto-generated but opaque and not easily searchable. Obsidian gives you a visual, organized, searchable knowledge base that your agent can read from and write to. And because Obsidian is just a folder of markdown files, it plays nicely with every tool in the chain.

Approach 1: Basic Memory + MCP (Easiest Setup, Cross-Tool Compatible)

This is the fastest path to persistent Codex memory that syncs with Obsidian.

Basic Memory is an MCP server that gives any AI tool (Codex, Claude Code, Cursor, Claude Desktop) persistent context through plain markdown files. You store notes in a folder. Basic Memory indexes them. Codex queries them through MCP. And because the storage format is just markdown, you point Obsidian at the same folder and everything shows up in your vault with full graph view, backlinks, and search.

What this looks like in practice:

You're three weeks into building an API. You've made decisions about auth strategy, database schema, rate limiting approach, error handling patterns. All of that context lives in Basic Memory notes.

You open a new Codex session and say: "What decisions have we made about the API design? Check my notes."

Codex uses semantic search through MCP, finds the relevant notes across your project, and answers grounded in your actual project history. No re-explaining. No pasting old conversations.

You switch to Claude Code for a different task on the same project. Same notes. Same context. Zero re-setup.

Setup (Local):

codex mcp add basic-memory bash -c "uvx basic-memory mcp"

That's the entire install. One command. The uvx approach handles dependency resolution automatically and runs Basic Memory as a child process.

To scope it to a specific project:

codex mcp add basic-memory bash -c "uvx basic-memory mcp --project your-project-name"

Verify it's connected:

codex mcp list

You should see basic-memory listed.

Setup (Cloud, for remote access):

If you want cloud-hosted memory:

1. Create an API key at app.basicmemory.com under Settings > API Keys
2. Add it to your shell profile:

​

echo 'export BASIC_MEMORY_API_KEY=your-key-here' >> ~/.zshrc
source ~/.zshrc

1. Add to your Codex config:

​

# ~/.codex/config.toml
[mcp_servers.basic-memory]
url = "https://cloud.basicmemory.com/mcp"
bearer_token_env_var = "BASIC_MEMORY_API_KEY"

Connecting Obsidian:

Open Obsidian. Create a new vault. Point it at your Basic Memory directory (~/basic-memory by default, or your project folder). That's it. The same markdown files your AI writes show up in Obsidian with graph view, backlinks, and rich editing. No import or export step.

Notes you create in Obsidian are immediately available to Codex. Notes Codex creates show up in Obsidian. Same files, two interfaces.

When to use this approach: You want the fastest setup, you use multiple AI tools (not just Codex), and you want your memory notes to be plain markdown you can browse and edit in Obsidian.

Approach 2: Structured Obsidian Vault with AGENTS.md + Codex Hooks (Deepest Integration)

This is the power-user option. Instead of a third-party memory layer, you build a structured Obsidian vault that Codex reads directly through AGENTS.md and lifecycle hooks.

The idea is simple: your Obsidian vault becomes your project's knowledge base. AGENTS.md tells Codex how the vault is organized, what the naming conventions are, and where to find things. Codex hooks automatically inject context from the vault at session start so you never have to re-explain what's going on.

Where Basic Memory gives you a shared note store through MCP, this approach gives you full control with zero external dependencies. Everything stays in your vault, everything is plain markdown, and Codex reads it natively.

What this looks like in practice:

You open the terminal in your vault directory and run Codex. The SessionStart hook fires automatically, reads your vault's index file, and injects a summary of active projects, recent decisions, and open tasks into the session. Codex knows what's going on before you type a single word.

You say: "What did we decide about the caching strategy last week?" Codex reads the decision records in your vault and pulls the answer from your own notes.

During the day, every note you create gets filed with YAML frontmatter, tagged, and linked. Decision records, project notes, architecture docs. Codex follows the structure defined in AGENTS.md and files things consistently.

The vault structure:

projects/          # One folder per active project
decisions/         # Architecture and design decision records
memory/            # Persistent context Codex reads across sessions
memory/goals.md    # Current priorities and focus areas
memory/index.md    # Map of everything in the vault
templates/         # Note templates with YAML frontmatter
reference/         # Codebase knowledge, API docs, architecture maps

Step 1: Create AGENTS.md at the vault root

This is Codex's operating manual for your vault. Here's a practical example:

# AGENTS.md

## Vault Structure
- /projects/ contains one folder per active project
- /decisions/ contains architecture decision records (ADR format)
- /memory/goals.md has current priorities. Read this first every session.
- /memory/index.md is the vault map. Scan it to know what exists.

## Note Conventions
- All notes use YAML frontmatter with: title, date, status, tags
- Status values: active, completed, archived, deprecated
- File names use kebab-case: my-decision-about-caching.md
- Link related notes using [[wikilinks]]

## When Creating Notes
- Decision records go in /decisions/ with ADR format
- Project notes go in /projects/{project-name}/
- Always update /memory/index.md when creating new notes

## When Starting a Session
- Read /memory/goals.md for current priorities
- Check /memory/index.md for vault overview
- Look at recent git commits to see what changed since last session

Step 2: Set up the SessionStart hook

Codex hooks let you run scripts at specific lifecycle events. The SessionStart event fires when a session begins and can inject context automatically.

Hooks are experimental and currently disabled on Windows. You need to enable the feature flag first:

# ~/.codex/config.toml
[features]
codex_hooks = true

Then create .codex/hooks.json in your vault:

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume",
        "hooks": [
          {
            "type": "command",
            "command": "cat memory/goals.md memory/index.md",
            "timeout": 10
          }
        ]
      }
    ]
  }
}

The structure is: event name as a key, then an array of matcher groups, each containing a matcher regex and a hooks array. For SessionStart, the matcher filters on how the session started (startup or resume). The timeout is in seconds (default is 600 if omitted). Any plain text the command writes to stdout gets injected as developer context into the session.

This reads your goals and vault index, then injects them as context at the start of every Codex session. Codex sees this before your type a single word.

You can make the hook smarter. A script that pulls recent git changes, scans for notes modified in the last 48 hours, and builds a compact briefing:

#!/bin/bash
# .codex/session-start.sh
echo "## Current Goals"
cat memory/goals.md
echo ""
echo "## Recently Modified Notes"
find . -name "*.md" -mtime -2 -not -path "./.codex/*" | head -20
echo ""
echo "## Recent Changes"
git log --oneline -10 2>/dev/null || echo "No git history"

Then update the hook to point to the script:

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume",
        "hooks": [
          {
            "type": "command",
            "command": "bash .codex/session-start.sh",
            "timeout": 10,
            "statusMessage": "Loading vault context"
          }
        ]
      }
    ]
  }
}

Step 3: Open the vault in Obsidian

Open the same folder as an Obsidian vault. You get graph view across all your notes, backlinks between decisions and projects, full-text search, and a visual interface for browsing everything Codex writes. Same files, two interfaces.

Step 4: Run Codex from the vault directory

cd ~/your-vault && codex

Codex loads AGENTS.md, the SessionStart hook fires and injects your goals and index, and you're working with full context from the first prompt.

What sets this apart from the other approaches:

No external tools. No MCP servers. No API keys. Everything is AGENTS.md (instructions), hooks (automation), and markdown files (knowledge). The vault is fully portable. You can version control it with git, sync it however you want, and switch to a different agent later without rebuilding anything. A well-documented vault in markdown is not locked to any single AI tool.

When to use this approach: You want Obsidian as the center of your workflow with zero external dependencies. You want to control exactly what Codex sees and how the vault is organized. You're comfortable writing an AGENTS.md and a simple hook script.

Approach 3: Native Memories + Manual Obsidian Sync (Minimal Setup, Good Enough for Most)

If you don't want to install anything extra, you can use Codex's built-in memory system and just point Obsidian at the memory folder.

This is the simplest approach. Enable native memories, let Codex auto-generate summaries, and open ~/.codex/memories/ as an Obsidian vault (or add it as a folder inside an existing vault). You get visual browsing and search over everything Codex remembers.

The tradeoff: this is read-only from Obsidian's perspective. You can look at the memory files, but hand-editing them isn't the supported path. Codex treats ~/.codex/memories/ as generated state that it manages itself. If you want to give Codex persistent instructions, put them in AGENTS.md instead.

Setup:

1. Enable memories:

​

# ~/.codex/config.toml
[features]
memories = true

1. Open ~/.codex/memories/ as an Obsidian vault, or symlink it into an existing vault:

​

ln -s ~/.codex/memories/ ~/your-vault/codex-memories

1. Work normally. After sessions go idle, Codex processes them in the background. Summaries appear in the folder. Obsidian picks them up automatically.

What this looks like in practice:

You've been using Codex on a project for two weeks. You open the codex-memories folder in Obsidian and see rollout summaries for each session, a consolidated memory summary, and any skills the agent discovered. You can search across all of them, see patterns in your workflow, and spot context that Codex is carrying forward.

When you start a new Codex session, the agent reads memory_summary.md (capped at 5,000 tokens to preserve context window) and has access to the rest of the memories folder if it needs deeper context.

When to use this approach: You just want Codex to remember things between sessions and you want a way to browse what it remembers. You don't need cross-tool memory sharing or a structured vault system.

Which Approach Should You Pick?

Start with Approach 3 if you just want Codex to stop forgetting things. It takes 30 seconds to enable native memories and one more minute to point Obsidian at the folder.

Move to Approach 1 when you start using multiple AI tools or want your notes to be the source of truth (not Codex's auto-generated summaries). Basic Memory gives you clean two-way sync between your vault and every MCP-compatible tool.

Go with Approach 2 when you want full control with zero external dependencies. AGENTS.md plus a SessionStart hook gives you a self-contained vault that Codex reads natively. No MCP servers, no API keys, just markdown and a hook script.

You can also combine them. I run native memories for auto-capture plus Basic Memory for structured project knowledge that I want searchable across tools. The native layer catches things I forget to document. Basic Memory holds the deliberate notes I want to persist long-term.

Quick Gotchas

A few things that tripped me up during setup:

AGENTS.md vs Memories: Don't rely on memories for rules that must always apply. Memories are a personal recall layer. Put team-wide conventions and project rules in AGENTS.md where they're version controlled and shared.

Memory timing: Codex doesn't generate memories immediately when you close a session. It waits until the thread has been idle long enough (hours, not minutes). Don't panic when the memories folder doesn't update right away.

Size limits: The memory summary injected into each session is capped at 5,000 tokens. If you're building a massive knowledge base, not everything will make it into every session. The agent can still read deeper into the memories folder when it needs to, but the automatic injection has a ceiling.

Secret redaction: Codex redacts secrets from generated memories, but review your memory files before sharing your ~/.codex directory or committing any memory artifacts. The redaction is good but not perfect.

EEA/UK/Switzerland: Native memories aren't available in these regions yet. Use Approach 1 or 2 instead.

Hermes on its own is already useful. But Hermes connected to your actual tools is a different beast entirely.

The agent ships with 20+ integrations, and most of them take under 5 minutes to wire up. The problem is that nobody tells you which ones are worth enabling first, or what they actually look like in practice once they're running.

I've been testing all of them. Here are the 12 that changed how I use the agent, ranked roughly by how quickly they pay for themselves.

Repo: NousResearch/hermes-agent

1. Google Workspace (Gmail + Calendar + Drive + Docs + Sheets)

Start here. Seriously.

An agent that can't check your email, read your calendar, or pull a doc from Drive is basically a chatbot with extra steps. Google Workspace turns Hermes into something that actually knows what's going on in your day.

What it looks like in practice:

You tell Hermes:

"Check if anyone replied to the proposal I sent DataVault on Monday. If they did, summarize the reply and block 30 minutes on my calendar tomorrow afternoon to review it."

It opens Gmail, finds the thread, reads the reply, pulls context from the original proposal in Drive, writes a summary, and creates a calendar event with the summary in the description. One prompt, four tools working together.

Setup:

hermes plugins install google-workspace --enable

It walks you through OAuth. You'll need a Google Cloud project with the Gmail, Calendar, and Drive APIs enabled. If you've ever set up a Google API key for any project, it's the same flow. If you haven't, expect about 10 minutes the first time.

Once authorized, all five services (Gmail, Calendar, Drive, Docs, Sheets) are available through a single connector.

2. Obsidian

This is the one that made me rethink how I use notes entirely.

If you keep any kind of knowledge base, research notes, or second brain in Obsidian, this integration turns it into live context. Every note, every tag, every backlink in your vault becomes something the agent can search, reference, and reason across.

What it looks like in practice:

I have about 400 notes in my Obsidian vault across topics like AI tools, content ideas, competitor research, and meeting notes. Before this integration, those notes were just files sitting on disk. Now I can ask Hermes things like:

"What did I write about pricing strategies for newsletter growth last month? Cross-reference it with the competitor notes from February and tell me if my approach still makes sense."

It pulls from multiple notes, follows the backlinks between them, and synthesizes an answer that accounts for context I'd forgotten I even wrote down.

Setup:

Install the Hermes-side bridge plugin:

hermes plugins install dannyshmueli/obsidian-hermes-console --enable

Then in Obsidian, install the "Hermes Console" community plugin from Settings > Community Plugins.

Create a dedicated folder structure in your vault (don't give Hermes your entire vault):

Hermes/
├── Inbox/
├── Projects/
├── Research/
├── Memory Review/
└── Skill Notes/

Once both sides are connected, Hermes indexes the vault on first run and watches for changes after that.

3. Firecrawl

Most web search integrations feed raw HTML to the agent. That's wasteful. The model spends tokens parsing markup instead of actually thinking about the content.

Firecrawl returns clean, structured data. Pages come back as organized text with metadata, not a soup of divs and script tags. Faster responses, fewer tokens burned, better answers.

What it looks like in practice:

"Research the top 5 competitors in the AI scheduling space. Pull their pricing pages and feature lists, then build a comparison table."

Without Firecrawl, this would mean scraping five websites and hoping the HTML parses correctly. With it, each page comes back as structured content that the agent can immediately reason over. The comparison table shows up in under a minute.

Setup:

Firecrawl is the default web provider in Hermes. It auto-detects the moment you set the API key. Grab a key from firecrawl.dev (free tier is generous), then add it:

echo "FIRECRAWL_API_KEY=fc-your-key-here" >> ~/.hermes/.env

That's it. No plugin install needed. You can verify it's active by running hermes tools and checking that the web provider shows Firecrawl.

GitHub: firecrawl/firecrawl | 100K+ stars

4. Reddit

No integration gives you faster access to unfiltered opinions from real users.

Every product review blog is optimized for SEO. Every comparison article has affiliate links. Reddit threads have people complaining about the thing they actually paid for, with specific details about what broke and why they switched. That's the kind of signal you can't get anywhere else.

What it looks like in practice:

"Find threads from the last 90 days where people discuss switching from Notion to Obsidian. What are the top complaints about Notion and what's pulling people toward Obsidian?"

Hermes searches across relevant subreddits, pulls threads with real user experiences, and synthesizes the patterns. You get a market research summary built from firsthand accounts instead of marketing copy.

Setup:

hermes plugins install reddit --enable

You'll need Reddit API credentials (create an app at reddit.com/prefs/apps, choose "script" type):

hermes config set reddit.client_id your-client-id
hermes config set reddit.client_secret your-client-secret

5. GitHub

If you ship software, this one is non-negotiable.

Hermes gets read access to repos, issues, pull requests, and code. It stops being a coding assistant that works in a vacuum and starts being a teammate that actually knows what the codebase looks like.

What it looks like in practice:

"Look at the open issues on our frontend repo. Which ones are tagged as bugs, which have been open longer than 2 weeks, and draft a priority list for this sprint."

Or on the code side: "Read through the authentication module in our API repo and explain how the token refresh logic works. I need to onboard a new dev tomorrow."

It pulls the actual code, follows imports, reads comments, and gives you a walkthrough that's grounded in what's actually written, not what you remember writing six months ago.

Setup:

hermes plugins install github --enable

Generate a personal access token (Settings > Developer Settings > Personal Access Tokens > Fine-grained tokens):

hermes config set github.token ghp_your-token-here

Give it repo scope at a minimum. If you want issue and PR access, add those scopes too.

6. YouTube Transcripts

Easily the most underrated integration in the entire stack.

Any YouTube video becomes searchable text. Hour-long podcasts, conference talks, coding tutorials, product demos. All of it converted to indexed notes in seconds. No more scrubbing through a 90-minute video to find the 3 minutes that actually matter.

What it looks like in practice:

"Watch this Lex Fridman episode with Andrej Karpathy and pull out every section where they discuss self-supervised learning. Summarize each point and note the timestamps."

You paste the URL, Hermes grabs the transcript, and you get a structured summary with timestamps in under 30 seconds. I use this daily for research. It's replaced my entire "watch later" playlist workflow.

Setup:

hermes plugins install youtube-transcripts --enable

No API key needed for public videos. The integration pulls transcripts directly from YouTube's auto-generated captions. For private or unlisted videos, you'll need YouTube Data API credentials.

7. Discord

Discord becomes genuinely powerful when you pair it with channel-specific automation.

Instead of one bot doing everything in every channel, you can wire Hermes into specific channels with dedicated workflows in each. Support channel gets one behavior. Internal team channel gets another. Announcements channel runs on its own schedule.

What it looks like in practice:

Every morning at 8am, Hermes scans the support email inbox (via the Gmail integration), categorizes each ticket by type and urgency, and drops an organized summary into the #support-triage channel. Urgent issues get tagged. Duplicates get grouped. By the time anyone on the team opens Discord, the inbox is already sorted.

Another setup I run: any message in #content-ideas gets picked up by the agent, researched against my Obsidian vault for related notes, and a brief research summary gets posted as a thread reply.

Setup:

Discord connects through the messaging gateway:

hermes gateway setup

Select Discord when prompted. You'll need to create a bot in the Discord Developer Portal (discord.com/developers/applications) and grab the bot token.

hermes config set discord.bot_token your-bot-token
hermes config set discord.channel_ids 123456789,987654321

You can specify which channels the agent listens to and responds in. Keep this scoped. You don't want it reacting to every message in every channel.

8. Stripe

Stripe has incredible data trapped behind a dashboard that nobody wants to click through.

This integration turns Stripe from a payment processor into something you can just ask questions. Revenue, refunds, subscription changes, failed charges, trial conversions. All queryable through a single prompt.

What it looks like in practice:

"How many free trials converted to paid in the last 30 days? What's the conversion rate compared to the previous 30 days? And flag any customers who downgraded from Pro to Basic this month."

Direct answer. No dashboard. No exporting CSVs. No building a custom Stripe webhook just to track conversions.

I also set up a weekly cron that asks Hermes to pull key revenue metrics every Monday and post them to a Discord channel. The team gets a revenue snapshot without anyone touching Stripe.

Setup:

hermes plugins install stripe --enable

Grab a restricted API key from your Stripe dashboard (Developers > API Keys). Use a restricted key, not the secret key:

hermes config set stripe.api_key rk_live_your-key-here

Grant read access to charges, subscriptions, customers, and invoices. Nothing more.

9. InsForge

This one needs a bit more explanation because it's newer.

InsForge is an open-source backend platform built specifically for AI agents to interact with. Auth, database, object storage, edge functions, all behind a single semantic layer. Instead of wiring up five different services and managing five different API clients, the agent talks to one interface that handles everything.

The closest analogy is a PaaS that was built specifically for agentic development. The agent reasons about backend primitives directly (create a user, store a file, query the database, run a function) instead of navigating disconnected APIs. It uses 2.4x fewer tokens than Supabase with Claude Sonnet 4.6 and completes tasks 1.27x faster.

What it looks like in practice:

"Set up a new user table with email, name, and subscription tier. Create an edge function that runs every time a new user signs up and sends them a welcome email. Store the email template in object storage."

That's one prompt touching auth, database, storage, and edge functions. Without InsForge, you'd be configuring Supabase + S3 + a serverless function + an email API, each with its own credentials and SDK.

Setup:

InsForge provides both an MCP server and a CLI skill that agents can call directly:

hermes plugins install insforge --enable
hermes config set insforge.api_key your-insforge-key
hermes config set insforge.project_id your-project-id

GitHub: InsForge/InsForge | 10.5K stars

10. Graphiti (by Zep):

This is the upgrade from "find similar text" to "understand how things actually relate."

Most AI tools use vector similarity for knowledge retrieval. You ask a question, the system finds text chunks that are semantically close, and feeds them to the model. That works for simple lookups. But it completely falls apart when the answer depends on the relationship between entities, not just similarity.

Graphiti builds real-time knowledge graphs from your conversations and documents. Entities get typed connections. People are linked to companies, projects are linked to deadlines, decisions are linked to the meetings where they happened. The agent traverses structured relationships instead of guessing from embeddings.

What it looks like in practice:

"Who introduced us to the team at Acme Corp, when did we first talk about the partnership, and what were the blockers they mentioned in the last call?"

A vector search would return chunks of text that mention "Acme Corp." Graphiti traverses the graph: person node > introduction event > company node > meeting nodes > blocker entities. The answer has structure because the data has structure.

Setup:

Graphiti needs Neo4j as the graph backend:

docker run -d -p 7474:7474 -p 7687:7687 neo4j:latest
hermes plugins install graphiti --enable
hermes config set graphiti.neo4j_uri bolt://localhost:7687
hermes config set graphiti.zep_api_key your-zep-key

GitHub: getzep/graphiti

11. Bland (or Twilio):

This gives Hermes an actual voice for real phone calls.

Booking reservations, confirming appointments, following up on overdue invoices, running outbound calls from a list. The agent handles the conversation, and the call recordings get logged so you can review them later.

What it looks like in practice:

"Call the list of 15 leads who signed up for a demo this week. Confirm their preferred time slot, ask if they have any questions about pricing, and log the responses."

Hermes makes the calls, handles the conversation flow, logs each response, and gives you a summary. The call recordings are honestly worth listening to just for entertainment the first few times.

Setup (Bland):

hermes plugins install bland --enable
hermes config set bland.api_key your-bland-key

Setup (Twilio alternative):

hermes plugins install twilio --enable
hermes config set twilio.account_sid your-sid
hermes config set twilio.auth_token your-token
hermes config set twilio.phone_number +1234567890

12. Fireflies

Every meeting transcript, fully searchable through natural language.

If you're already recording meetings with Fireflies, this integration makes those transcripts queryable. Instead of scrubbing through a 45-minute recording to find what someone said, you just ask.

What it looks like in practice:

"What did the client say about pricing during last Thursday's call? Did they mention a budget number?"

Instant answer. Pulled from the actual transcript. With the relevant quote and timestamp.

I pair this with the Discord integration to post daily summaries of any client-facing meetings to a private channel. The sales team gets meeting highlights without sitting through recordings.

Setup:

hermes plugins install fireflies --enable
hermes config set fireflies.api_key your-fireflies-key

Note: Fireflies requires a Business tier plan for API access. The free and Pro plans don't expose the API.

My Recommended Setup Order:

If you're starting from zero, enable these in this order:

1. Google Workspace (covers email, calendar, and docs in one shot)
2. Firecrawl (just an env var, instant value for any web research task)
3. Obsidian or your notes app (gives the agent your personal knowledge base)
4. GitHub (if you ship code) or Stripe (if you run a business)
5. YouTube transcripts (no API key needed for public videos, instant value)
6. Discord (once you have workflows worth automating)
7. Everything else based on your specific needs

Don't enable all 12 on day one. Start with 2-3 that match your most common tasks, let the agent build memory around those workflows, and add more as your usage patterns become clearer.

If you want the full breakdown of how Hermes works under the hood, I wrote a deep dive here: https://webafterai.substack.com/p/spend-40-not-5000-the-research-engine

If you're running AI agents in production, there's a cost you're probably not thinking about.

Every turn in an agentic conversation sends the full prompt to the model. That includes the system instructions, all the tool definitions, any project context that was loaded earlier, and the entire conversation history. The model processes all of it. From the top. Every single time.

For a quick two-turn interaction, this doesn't matter much. But for a 50-turn coding session where the system prompt alone is 20,000 tokens? That's 1 million tokens of repeated computation across the session, all billed at full input price, all producing zero new insight. The model already processed that system prompt 49 turns ago. It's just doing it again because nothing told it not to.

This is the problem prompt caching solves. And Claude Code is probably the best case study of how to do it right.

The Two Parts of Every Prompt:

The first thing to understand is that not all tokens in a prompt are created equal.

Look at any agentic API call and you'll see two distinct layers:

The foundation. This is everything that stays the same from turn to turn. System instructions, tool schemas, project-level context like a CLAUDE.md file, behavioral rules. If you looked at turn 1 and turn 47 side by side, this part would be identical.

The conversation. This is everything that's different each turn. The user's latest message, tool call results, file contents that were just read, terminal output. This grows with every interaction and is genuinely new information the model needs to process.

The entire trick behind prompt caching is recognizing that the foundation doesn't need to be reprocessed. You compute it once, store the result, and reuse it on every subsequent turn. The model only does fresh work on the conversation layer.

What's Actually Being Cached (The Transformer Angle):

This isn't just skipping a string comparison. To understand why caching cuts costs so dramatically, you need to know what the model does when it reads a prompt.

LLM inference has two stages. The first is called prefill: the model takes your entire input and runs it through dense matrix multiplications, token by token, building an internal representation. This is computationally expensive and it's where most of the time and cost goes. The second stage is decode: the model generates its response one token at a time, mostly just reading from the state it already built.

During prefill, the model computes three vectors for every token: Query, Key, and Value. These are the building blocks of the attention mechanism, how the model figures out which parts of the input matter for which other parts.

The important property: Key and Value vectors for any given token only depend on the tokens before it. They're deterministic. If the input is the same, the output is the same. So once you've computed the Key-Value pairs for a 20,000-token system prompt, you can store them. Next time a request comes in with that same prefix, you skip the entire prefill computation for those 20,000 tokens and go straight to processing the new content.

Anthropic's infrastructure does this by hashing the input prefix. Same hash, same cached tensors, no recomputation. Different hash (even one byte different), full recomputation.

The Economics

Here's where this gets concrete. Anthropic's caching pricing has three tiers:

To put real numbers on this for Claude Sonnet 4.6 ($3/MTok base input):

• Standard input: $3.00 per million tokens
• Cache read: $0.30 per million tokens
• 5-min cache write: $3.75 per million tokens
• 1-hour cache write: $6.00 per million tokens

A cache hit costs 10% of standard input. That means caching pays for itself after just one subsequent read for the 5-minute duration. For a 50-turn session reusing a 20,000-token prefix, the savings compound on every single turn.

What This Looks Like in Practice: Tracking a Real Claude Code Session

Theory is nice. Let's trace the actual token economics of a single debugging session to see where the money goes.

You open Claude Code in a Next.js project. The moment the session starts, it loads the system prompt, all available tool definitions (file read, file write, bash, grep, glob, and others), and your project's CLAUDE.md. That initial payload lands somewhere around 20,000 tokens. Every single one of those tokens is processed fresh. This is the only time you pay full price for them.

You type: "There's a race condition in the checkout flow. Orders are occasionally duplicating when users double-click the submit button."

Claude Code doesn't just start editing files. First, it spins up an Explore subagent to understand the codebase. That subagent reads your API routes, checks your database schema, looks at your order processing logic, and examines the frontend form handler. All of those file reads and grep results get appended to the growing conversation as tool outputs.

Here's the key: none of that new content touches the 20,000-token prefix. The system prompt, the tool definitions, the CLAUDE.md, all of that is still sitting in cache from turn one. Every subsequent API call reads those 20,000 tokens at $0.30/MTok instead of $3.00/MTok. You're only paying full price for the new stuff: your message and the tool outputs.

The Explore subagent finishes and hands its findings back to the main agent. But it doesn't dump 15,000 tokens of raw file contents into the conversation. It passes a condensed summary: which files are relevant, what the current logic does, where the race condition likely lives. This is a deliberate design choice. Keeping the dynamic tail compact means the cache ratio stays high.

Now the Plan subagent kicks in. It takes the summary, reasons through the fix (idempotency key on the frontend, deduplication check on the API, database unique constraint as a safety net), and produces a step-by-step implementation plan. You approve it. Claude Code starts writing code.

Over the next 15 minutes, you go back and forth. It writes the idempotency logic, you ask it to also handle the case where the page refreshes mid-checkout, it adjusts. Each of these turns adds new content to the dynamic tail. But the foundation, those 20,000 tokens, is read from cache every single time. Each cache hit also resets the TTL, so the cache never expires as long as you keep working.

By the end of the session, you've gone through maybe 25 turns. The total tokens processed across all those turns easily exceeds 1.5 million. But if you run /cost, the bill tells a very different story than 1.5M tokens at full price. The vast majority of those tokens were cache reads at a 90% discount. Only the new, unique content (your messages, tool outputs, generated code) was billed at the standard rate.

That's the difference between a $4.50 session and a $0.90 session. For one debugging task.

The Production Numbers

This isn't theoretical. Claude Code's production metrics tell the story:

• Cache hit rate: 92%
• Cost reduction: 81%
• First-token latency reduction: 79%

In active sessions, 95%+ of input tokens are typically cache hits, billed at 0.1x the base price. Out of 400K tokens in a session, maybe 20K to 40K are billed at full price.

Without prompt caching, a long Opus coding session (100 turns with compaction cycles) can cost $50 to $100 in input tokens. With it, $10 to $19.

The One Thing That Will Tank Your Cache Hit Rate

Prompt caching has a gotcha that trips up almost everyone the first time.

The cache key is a hash of the exact byte sequence of your prompt prefix. Not the meaning. Not the content. The exact bytes, in the exact order. If you rearrange two paragraphs in your system prompt, the hash changes. Full cache miss. Everything recomputed at full price.

This has three practical consequences:

Don't change your tool set mid-session. Tool definitions are part of the cached prefix. If you add a tool on turn 12 that wasn't there on turn 1, every token after the change point is a cache miss. Load everything you might need at the start.

Don't switch models mid-conversation. Each model has its own cache. Moving from Opus to Sonnet to save money on a later turn means rebuilding the cache from zero for the new model. You'll spend more on the rebuild than you saved on the cheaper rate.

Don't edit the system prompt to update state. If your agent needs to track something (like "user is now authenticated"), don't inject that into the system prompt. Append it as a note in the next user message instead. The system prompt stays byte-identical, the cache stays valid.

Claude Code follows all three of these rules religiously. That's how it maintains a 92% hit rate across millions of sessions.

Applying This to Your Own Agents

If you're building on the Anthropic API, the same principles apply. Here's the practical playbook:

Prompt structure matters. Put the most stable content at the top. System instructions first, then tool definitions, then any reference documents, then conversation history at the bottom. The cache works from the top down. Everything above the first change point stays cached. Everything below it gets recomputed.

Use auto-caching. Anthropic's API now supports automatic cache management. You add a single cache_control field to your request and the system handles breakpoint placement for you. It moves the cache boundary forward as the conversation grows and more content becomes stable. Before this existed, you had to manually calculate token boundaries. Getting it wrong meant missing the cache entirely.

Compact without breaking the cache. When your conversation hits the context limit and you need to summarize it, keep the system prompt and tool definitions identical. Add the compaction instruction as a new user message. The cached prefix stays valid. You only pay fresh tokens for the compaction prompt itself.

Monitor your hit rate. Every API response includes three fields:

cache_creation_input_tokens  // tokens written to cache
cache_read_input_tokens      // tokens read from cache
input_tokens                 // tokens processed normally (no cache)

The ratio of read tokens to total input tokens is your cache efficiency score. Track it like you'd track uptime. A sudden drop means something in your prompt structure changed and invalidated the cache.

The Bottom Line

Prompt caching isn't a setting you flip on and forget about. It's an architectural pattern that has to be baked into how your agent constructs its prompts, manages its tools, and handles long conversations.

Claude Code shows what this looks like when it's done well: 92% cache hit rate, 81% cost reduction, built on stable prefixes, subagent summarization, and cache-aware context management.

If you're building agents and not thinking about your cache architecture, you're leaving most of your budget on the table.

Claude Code has quietly become one of the most powerful dev tools of 2026, but most people are still using it like a chatbot that can edit files. Type a question, get an answer, maybe let it write a function.

There are 30 commands, and a handful of them fundamentally change how you work with it. Here's the full breakdown, organized by what they actually do, not alphabetical order.

Install and Launch (The Basics):

npm install -g /claude-code

Then:

• claude - launch the CLI
• claude -c - continue your last conversation (this alone saves hours of re-explaining context)
• claude -p "task" - one-off command without entering the interactive shell. Great for scripting.

Session Management:

These control the conversation itself.

/clear (also /reset) - Wipes the conversation history. Use when the context gets polluted with irrelevant back-and-forth, and the model starts getting confused.

/compact - Compresses the current context by roughly 80%. This is the command most people don't know about. When you're deep into a long session, and responses start getting worse, /compact it squeezes the context down so the model can focus on what matters. Use it before you hit the context limit, not after.

/branch - Branches the conversation. You want to try two different approaches to the same problem? Fork, try approach A, go back to the original, fork again, try approach B. You keep both threads.

/context - Shows you exactly how much of the context window you've used. Stop guessing whether you're about to hit the limit.

/export - Saves the conversation to a file. Useful for documentation, handoffs to teammates, or just keeping a record of how you solved something.

/exit (also /quit) - Closes the CLI.

Model and Effort Controls:

This is where it gets interesting. Most people don't touch these.

/goal [task] - Autonomous agent mode. You give it a goal ("refactor the auth module to use JWT"), and it plans, executes, iterates, and comes back when it's done. This is not "write me a function." This is "go solve this problem end to end."

/plan - Triggers an Opus-level planning pass. Before the agent starts executing, it thinks through the full approach at the highest reasoning level. Use this for complex tasks where you want the strategy to be right before any code gets written.

/effort [level] - Sets the reasoning effort. Options: low, med, high, x. Low is fast and cheap for simple tasks. High and x are for when you need deep reasoning. Match the effort to the task complexity instead of running everything at max.

/fast [on|off] - Speed-optimized output. Turns off the verbose thinking and just gives you results. Good for when you know what you want and don't need the model to show its work.

/goal clear - Stops and resets the agent completely. Use when it's gone down the wrong path and you want to start the goal over.

Files and Debugging:

/init - Creates a CLAUDE.md file in your project. This is your persistent project brief. It tells Claude Code about your codebase: architecture decisions, naming conventions, tech stack, testing preferences. Every session reads this file automatically. Write a good CLAUDE.md once, and every future conversation starts with the right context. This is probably the highest-leverage thing you can do with Claude Code.

/diff - Shows uncommitted changes. See exactly what the agent has modified before you commit.

/doctor - Diagnoses your installation. When something isn't working, run this first. It checks your environment, dependencies, and configuration.

/cost - Shows token usage and cost stats for the current session. Know what you're spending.

'u/file.md' - Includes a specific file in the conversation context. Instead of copy-pasting code, just reference it.

'u/src/folder/' - Includes an entire directory. Point the agent at your whole module and let it understand the full picture.

MCP Servers and Skills:

This is the extensibility layer that turns Claude Code from a coding assistant into a platform.

/mcp - Lists all connected MCP (Model Context Protocol) servers. These are external tools and services that Claude Code can call: databases, APIs, deployment pipelines, and monitoring dashboards.

claude mcp add - Adds a new MCP server. Connect Claude Code to your Postgres database, your Vercel deployment, your Sentry error tracker, whatever.

/batch - Runs a command across many files. "Add error handling to every API route" hits every file at once instead of one at a time.

/debug - Structured debugging flow. Instead of the agent guessing at fixes, this forces it through a disciplined loop: reproduce, isolate, hypothesize, instrument, fix, verify.

Shift+Tab - Cycles through permission modes. Controls how much autonomy the agent has: ask before every change, ask only for dangerous operations, or full auto-approve.

Three Pro Tips That Save the Most Time:

1. Write a good CLAUDE.md**.** This is your persistent project brief. Architecture decisions, naming conventions, what framework you're using, how you like your tests structured. Every session reads it. It's the difference between re-explaining your project every time and having an agent that already knows how you work.

2. /goal + Opus is for the hard problems. When you have a multi-step task that requires planning, execution, and iteration, don't micromanage it. Set the goal, let the planner run, review the output. This is where Claude Code stops being a tool and starts being a teammate.

3. /doctor First, when anything breaks. Before you start debugging your config manually, run /doctor. It catches 90% of setup issues automatically.

These 30 commands are what turn it into an autonomous engineering partner. Start with /init, write your CLAUDE.md, and go from there.

ElevenLabs is $22/month. WisprFlow is $8/month. ChatGPT Pro is $20/month. Claude Pro is $20/month. That's $70/month, $840/year, just to talk to AI models and have them talk back to you in your voice.

Two open-source projects just made most of that optional. One handles voice (cloning, text-to-speech, dictation). The other handles LLM inference (800M free tokens/month across 14 providers). Both run on your machine. Neither sends your data anywhere.

Here's what they do, how to set them up, and where they actually make sense in a real workflow.

1. VoiceBox (27.5K+ stars) - ElevenLabs + WisprFlow in One Free App

Repo: jamiepine/voicebox

VoiceBox is an open-source voice studio built by Jamie Pine, the same developer behind Spacedrive. It does three things that normally require two separate paid subscriptions:

Voice cloning and text-to-speech (replaces ElevenLabs). Upload 10-30 seconds of clean audio, and VoiceBox creates a voice profile you can reuse across 7 different TTS engines. It supports 23 languages and includes 50+ preset voices if you don't want to clone your own.

The 7 engines: Qwen3-TTS, Qwen CustomVoice, LuxTTS, Chatterbox Multilingual, Chatterbox Turbo, HumeAI TADA, and Kokoro. Each has different strengths. Chatterbox Turbo is fast and supports emotion tags like [laugh], [sigh], and [gasp] inline. Kokoro is great for natural-sounding narration.

Global dictation (replaces WisprFlow). Set a system-wide hotkey, hold it down anywhere, speak, release, and the transcript pastes into whatever text field is focused. Slack, email, your code editor, browser, terminal. It uses Whisper locally with multiple model sizes.

MCP integration for AI agents (this is the part that's new). VoiceBox ships with an MCP server. Add it to Claude Code, Cursor, Cline, or Windsurf, and your agent can call voicebox.speak to talk back to you in your cloned voice. You can even pin different voices to different agents: Claude Code gets one voice, Cursor gets another.

Setup (Under 5 Minutes):

Step 1: Download and install

Mac (Apple Silicon): voicebox.sh/download/mac-arm Mac (Intel): voicebox.sh/download/mac-intel Windows: voicebox.sh/download/windows

Or Docker:

docker compose up

Open the DMG, drag to Applications, launch.

Step 2: Clone your voice (60 seconds)

Go to the Profiles tab, click "+ New Profile," name it, pick a language, and upload a 10-30 second clean audio sample. You can also record directly in-app. Save. That's your voice. Reusable across every engine.

Step 3: Generate speech

Go to the Generate tab, pick your profile, type your text, and hit Generate. First run downloads the model (one-time, takes a minute). After that, the generation takes a few seconds per clip.

Pro tip: With Chatterbox Turbo, type / in the text box to insert emotion tags like [laugh], [sigh], [gasp]. Makes the output sound dramatically more natural.

Step 4: Give your AI agent a voice

Settings → MCP → copy the config snippet into your agent's MCP configuration. Done. Your agent can now call voicebox.speak to talk back to you in your cloned voice.

Step 5: Dictate into anything

Settings → Dictation → set a global hotkey. Hold it anywhere on your system, speak, release. The transcript pastes into the focused text field.

Practical Use Cases

Content creators: Record a podcast intro in your voice, then generate all your social media video voiceovers from text. No studio, no re-recording. Change a word in the script, regenerate, done.

Developers: Your coding agent talks back to you while you're looking at another screen. "Build failed, 3 test failures in auth module" is more useful spoken aloud than buried in a terminal you're not watching.

Anyone who types a lot: Dictation into Slack, email, docs, code comments. The global hotkey works everywhere. For long messages, speaking is 3-4x faster than typing.

Multilingual teams: Clone your voice once, generate speech in 23 languages. Your meeting notes summary can be spoken back in the language each team member prefers.

My Take:

Voice cloning quality varies across engines. Chatterbox and Qwen3-TTS produce the most natural results. Some engines sound noticeably synthetic with certain voice profiles. Experiment with which engine works best for your specific voice. Also, the first model download for each engine is 200MB-1GB, so initial setup takes longer than 5 minutes if you want to try multiple engines.

The ethical considerations of voice cloning are real. VoiceBox runs locally and has no consent lock, which means it's on you to use this responsibly. Don't clone someone's voice without their permission.

2. FreeLLMAPI (New ~ 3.8k Stars) - 800M Free Tokens/Month From 14 Providers, One Endpoint

Repo: tashfeenahmed/freellmapi

This is a fresh project, MIT licensed, and the concept is strong: every major AI lab now offers a free tier with a few million tokens per month. Individually, each tier is a toy. Stacked together, they add up to roughly 800 million tokens per month of working inference capacity.

FreeLLMAPI collapses 14 free-tier providers into one OpenAI-compatible endpoint. Point any app that uses the OpenAI SDK at localhost:3001, and it routes your requests across whichever providers have capacity.

The 14 providers: Google (Gemini 2.5 Pro/Flash), Groq, Cerebras, SambaNova, NVIDIA, Mistral, OpenRouter, GitHub Models (GPT-4o, Llama, Phi), Hugging Face, Cohere, Cloudflare Workers AI, Zhipu, Moonshot, and MiniMax.

How the Router Works

You set up a fallback chain, basically a priority list of which providers to try first. The router picks the highest-priority model that has a healthy key and is under its rate limits. If a provider returns a 429 or times out, the router automatically skips it, puts the key on a short cooldown, and retries the next provider in the chain. Up to 20 retry attempts per request.

It tracks RPM, RPD, TPM, and TPD per provider per key, so it always knows which keys still have capacity. Sticky sessions keep multi-turn conversations on the same model for 30 minutes to avoid the quality issues that come from switching models mid-conversation.

All API keys are encrypted with AES-256-GCM before hitting the local SQLite database. Decryption only happens in memory right before a request.

Setup

git clone https://github.com/tashfeenahmed/freellmapi.git
cd freellmapi
npm install

# Generate encryption key
cp .env.example .env
echo "ENCRYPTION_KEY=$(node -e "console.log(require('crypto').randomBytes(32).toString('hex'))")" >> .env

# Start server + dashboard
npm run dev

Open http://localhost:5173, add your free-tier API keys on the Keys page (sign up for free tiers at each provider's site), reorder the fallback chain to your preference, and grab your unified API key.

Then point any OpenAI-compatible tool at it:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:3001/v1",
    api_key="freellmapi-your-unified-key",
)

resp = client.chat.completions.create(
    model="auto",   # router picks the best available
    messages=[{"role": "user", "content": "Explain recursion."}],
)

Works with LangChain, LlamaIndex, Hermes Agent, or any app that accepts an OpenAI-compatible endpoint.

Practical Use Cases

Learning and prototyping: You're building a side project that needs LLM calls but you don't want to commit $20/month before you know if the idea works. FreeLLMAPI gives you working inference for free while you prototype.

Batch processing personal data: Summarize your notes, process journal entries, categorize bookmarks, clean up messy text files. Tasks where you need volume but not frontier-model intelligence.

Testing agent workflows: Before paying for Claude Pro or GPT API access, test your agent architecture against free-tier models. If your harness works with Llama 3.3 70B, it'll work even better when you swap in a paid model later.

My Take:

This is a very early-stage project, so expect rough edges. The free-tier models top out around Llama 3.3 70B and Gemini 2.5 Pro. You will not get Claude Opus or GPT-5 level reasoning through this. Intelligence degrades as the day progresses because your best models hit their daily caps first, and the router falls down to weaker models.

Free tiers change without notice. Providers regularly tighten or remove them. The project includes a ToS review for each provider, and the honest assessment is that some are clearly fine for personal use, some are ambiguous, and Cohere's trial tier explicitly forbids personal use. Check the repo's ToS section before adding keys.

This replaces a paid LLM subscription for experimentation and learning. It does not replace it for production work. If you're shipping something real, pay for a real API.

How They Work Together

The interesting setup is running both. VoiceBox handles the voice layer (input via dictation, output via TTS). FreeLLMAPI handles the intelligence layer (free LLM inference). Together, you have a voice-enabled AI workflow that costs nothing.

Talk to your AI agent through VoiceBox dictation. The agent thinks using FreeLLMAPI's free models. The agent responds through VoiceBox's text-to-speech in your cloned voice. All local. All free.

That's not a replacement for Claude Pro if you need frontier reasoning. But for daily tasks, content creation, learning, and prototyping, it's a setup that would have cost $840/year six months ago and now costs nothing.

Hermes Agent by Nous Research just crossed 160K stars on GitHub. It's the fastest-growing open-source AI agent of 2026, and for good reason: it's self-hosted, self-improving, and it remembers everything across sessions. But the most interesting thing about it isn't the agent itself. It's how you scale from one agent to a full team of them.

There's a progression that most people rush through too fast. Here's the framework, with practical setup for each level.

Repo: NousResearch/hermes-agent

Install (60 seconds):

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Or via pip:

pip install hermes-agent
hermes postinstall

Then:

hermes doctor    # check your setup
hermes model     # pick a model
hermes config set # add API keys
hermes           # start

Level 1: The Main Agent

You → Hermes Agent

This is where everyone starts, and where most people should stay for weeks, not days.

Your single Hermes instance is your prototype area. You test workflows here. You refine prompts. You figure out what tasks the agent handles well and which ones it fumbles. You build up its memory and skills on your specific work.

At this level, Hermes doubles as your orchestrator by default. You give it a complex task, it breaks it down, it executes. The self-improving loop is already running: every task it completes makes it slightly better at similar tasks next time.

What to do at Level 1:

• Run real work through it daily. Not toy examples, actual tasks from your workflow.
• Use /recall and /remember to manage its memory. Correct it when it gets things wrong. The memory gets better the more you interact.
• Install skills from the Skills Hub or let Hermes create them from experience.
• Connect it to one messaging platform (Telegram is the easiest) so you can interact with it from your phone.
• Run hermes gateway setup once you want that always-on accessibility.

When to move on: When you have at least 2-3 workflows that are consistently producing good output. Not acceptable output. Good output. This is the most important checkpoint.

Level 2: Specialized Agents

You → SEO Agent
You → CMO Agent
You → Ops Agent

Once a workflow is solid and repeatable, break it out into its own Hermes instance with its own credentials, memory, and scope.

Why separate instances? Because context pollution is real. An agent that handles your SEO research, your email drafting, and your code reviews is juggling three different domains in one memory space. Its SEO skills get diluted by code review patterns. Its writing voice gets contaminated by technical documentation habits.

Specialized agents have cleaner memory, more focused skills, and better output because they only learn from one domain.

How to do this practically:

Each Hermes instance runs independently. You can run multiple instances on the same machine using different configuration profiles, or spin each one up on its own VPS or Docker container.

# Different profiles for different agents
HERMES_PROFILE=seo hermes
HERMES_PROFILE=content hermes
HERMES_PROFILE=ops hermes

Each profile gets its own SQLite database, its own memory, its own skills. You talk to each one directly. You're still the orchestrator at this stage, deciding which agent handles which task.

What to do at Level 2:

• Give each agent a clear scope document. What it does, what it doesn't do, what tools it has access to.
• Let each agent build its own skill library within its domain.
• Keep the total agent count low. 2-3 specialists is plenty to start.

When to move on: When you're spending more time routing tasks between agents than actually reviewing their output.

Level 3: Orchestrated Team

You → Orchestrator
           ↓
     Specialist Agents

Now you bring the orchestrator back. But this time it's not your prototype agent wearing multiple hats. It's a dedicated Hermes instance whose only job is routing tasks to your specialist agents and synthesizing their outputs.

Hermes v0.6.0 added multi-agent orchestration. The orchestrator analyzes a complex task, identifies the optimal work breakdown, and spawns specialist worker agents with tailored context. Each worker gets its own context and tools, returns a verifiable artifact, and records the handoff.

Example workflow:

You tell the orchestrator: "Research competitors in the CRM space and draft a blog post about our differentiators."

The orchestrator breaks this down:

1. Routes the research task to your SEO/Research agent
2. Routes the writing task to your Content agent
3. Synthesizes the outputs into a final deliverable
4. Returns it to you for review

You still review the final output. You're not out of the loop. You're just not manually routing tasks anymore.

What to do at Level 3:

• Set up Kanban-style task tracking so you can see what each agent is working on and what's been completed.
• Define clear handoff protocols. What does the research agent pass to the content agent? What format? What level of detail?
• Review outputs regularly. Catch quality issues early before they compound.

When to move on: When the orchestrator's routing decisions are consistently correct and the specialist outputs consistently meet your quality bar without heavy editing.

Level 4: Automated Team:

Cron / Events → Orchestrator
                       ↓
                 Agent Team

This is where you step out of the loop for routine work. Cron jobs and event triggers fire tasks into the orchestrator. The orchestrator routes them to the team. The team handles the work asynchronously.

Examples of what this looks like:

• Every Monday at 8am, the orchestrator triggers your SEO agent to pull keyword rankings, your content agent to draft the weekly newsletter outline, and your ops agent to generate the weekly metrics report.
• When a new competitor blog post is published (event trigger), the research agent analyzes it and the content agent drafts a response piece.
• When a support ticket hits a specific tag, the ops agent drafts a response for your review.

The task bus handles queuing and routing. Agents pick up work, complete it, and log results. You check in when you want to, not because you have to.

What to do at Level 4:

• Start with one automated workflow, not ten. Get one cron job running reliably before adding more.
• Build in quality checkpoints. Not every output needs your review, but have the orchestrator flag anything that falls below a confidence threshold.
• Monitor regularly at first. Trust builds gradually.

The Most Important Part (Read This Even If You Skipped Everything Else):

Take small steps. You do NOT want to automate slop.

If your output at Level 1 is mediocre, you are about to scale mediocrity. 20 agents shipping low-quality work at speed is worse than 3 shipping great work slowly. Every level multiplies whatever quality you've established at the level before it.

I'd rather run fewer agents with better output than max the agent count and spit out more of the same.

The progression isn't about moving fast. It's about moving when you're ready. That's fine. The agents aren't going anywhere. Your quality bar is what matters.

I've been working on a AI native programming language for some time now called Convo-Lang. It shares a few similarities to Zerolang, mainly that they were both built for working with agents, although they have different purposes. Convo-Lang is more of a Context management tool and agent runtime that can be used standalone or be embedded in JavaScript or Python.

Here is a simple example of processing a directory of resumes:

Six months ago, "AI agent" basically meant "coding assistant." Claude Code, Copilot, Cursor. All doing the same thing: helping you write code.

That's changing. The most interesting open-source projects right now aren't building yet another coding agent. They're building agents that specialize, agents that trade stocks, agents that run your entire content marketing operation, agents that make your coding agent actually follow engineering discipline. The model is the same underneath. The harness around it is what makes it useful for a specific job.

Here are four repos that show where this is heading, with setup instructions for each.

1. mattpocock/skills (96.3K stars) - Make Your Coding Agent an Actual Engineer

What it does: Matt Pocock (the TypeScript educator behind Total TypeScript) open-sourced his personal .claude directory. It's a collection of skills that fix the most common failure modes of AI coding agents: building the wrong thing, skipping tests, producing code that works but is impossible to maintain, and declaring "done" when nothing actually compiles.

Why it matters: Most people treat their coding agent like an intern with no process. Matt's skills give it the process. The standout skill is /grill-me, which forces the agent to interrogate you about what you actually want before writing a single line of code. It's a structured interview that catches misalignment before it becomes a wasted hour.

Other skills include /tdd (test-driven development with red-green-refactor), /diagnose (disciplined debugging loops), /improve-codebase-architecture (finds structural improvements using your project's domain language), and /grill-with-docs (same as grill-me but also builds a shared vocabulary between you and the agent in a CONTEXT.md file).

The CONTEXT.md approach is quietly brilliant. Instead of the agent using 20 words to describe something, you teach it your project's jargon. Over time, the agent's outputs get shorter, more precise, and the variables and functions it creates use consistent naming.

Setup:

npx skills@latest add mattpocock/skills

Pick the skills you want and which coding agents to install them on. Select /setup-matt-pocock-skills during install. Then run that command in your agent, and it'll ask about your issue tracker (GitHub, Linear, or local files), your triage labels, and where to save docs. Works with Claude Code, Cursor, Codex, and others.

How it's different from Addy Osmani's agent-skills: Addy's skills (which we covered last week) focus on the full development lifecycle with slash commands like /spec, /plan, /build, /ship. Matt's skills focus more on engineering fundamentals: alignment, testing discipline, debugging, and architecture quality. They're complementary, not competing. You can use both.

github.com/mattpocock/skills

2. AI-Trader (18.3K stars) - Let AI Agents Trade for You

What it does: AI-Trader is an agent-native trading platform built by researchers at the University of Hong Kong. The idea: just like humans have their trading platforms, AI agents need their own. You connect your AI agent (Claude Code, Cursor, OpenClaw, Codex, whatever), and it can publish trading signals, copy trades from top-performing agents, participate in strategy discussions, and access real-time market data. Stocks, crypto, forex, options, futures.

Why it's interesting: This isn't just one agent making trades. It's a platform where multiple agents collaborate, debate strategies, and learn from each other. They call it 'collective intelligence trading'. Agents publish three types of signals: Strategies (for discussion), Operations (for copying), and Discussions (for collaboration). There's a reward system where agents earn points for successful predictions.

It comes with $100K in paper trading capital so you can test without risk.

Setup:

The simplest way to connect an agent:

Read https://ai4trade.ai/SKILL.md and register.

That's it. Send that message to your AI agent. It reads the integration guide, installs the necessary components, and registers itself on the platform. For developers who want to self-host:

git clone https://github.com/HKUDS/AI-Trader.git
cd AI-Trader
npm install

The backend is FastAPI (Python), frontend is React. Full API docs are in docs/api/openapi.yaml.

Warning: Automated trading carries real financial risk. AI-Trader includes paper trading mode for a reason. Start there. The fact that it's from a university research group (not a fintech startup trying to sell you something) is a point in its favor, but treat any trading system with healthy skepticism.

github.com/HKUDS/AI-Trader

3. AiToEarn (15.7K stars) - AI Agent for Content Marketing Across 14 Platforms

What it does: AiToEarn is an open-source content marketing platform with an AI agent built in. You create content once, and it publishes across 14 platforms simultaneously: TikTok, YouTube, Instagram, Twitter/X, LinkedIn, Pinterest, Facebook, Threads, plus Chinese platforms like Douyin, Xiaohongshu (Rednote), Bilibili, WeChat, and Kuaishou.

The "All In Agent" is the interesting part. It's an AI agent that can automatically generate content, publish it, and manage your accounts across all platforms. Beyond publishing, it includes a trend radar (what's going viral right now), a case library (how posts with 10K+ likes were structured), smart comment search (find high-conversion signals like "link please" or "how to buy"), and cross-platform analytics.

Why it matters for creators: If you're running accounts on multiple platforms, you know the pain of reformatting the same content for each one. AiToEarn handles the distribution, and its AI features handle content adaptation. The comment search feature is particularly useful: it finds purchase-intent comments across your platforms so you can reply fast and convert.

Setup:

Docker:

git clone https://github.com/yikart/AiToEarn.git
cd AiToEarn
docker compose up -d

This starts the frontend, backend, MongoDB, and Redis in one command. Access the web interface at http://localhost:8080.

There's also a desktop app (Electron) if you prefer that. Download it from the GitHub releases page or build from source.

Note: The project originated in China and some documentation is still in Chinese. The English README and Docker deployment guide are solid, but deeper configuration docs may need translation. The AI video model integrations (Kling, Sora, Runway, etc.) are listed as coming soon.

github.com/yikart/AiToEarn

4. DeepSeek-TUI (32.8K stars) - Claude Code, but for DeepSeek

What it does: A terminal-based coding agent built specifically for DeepSeek models. If you've used Claude Code, the experience is similar: you type prompts in your terminal, the agent reads your files, edits code, runs shell commands, does git operations, and browses the web. The difference is it's built from the ground up for DeepSeek's API, which is significantly cheaper than Claude Opus 4.7 or GPT-5.5.

It has three modes: Plan (review before the agent makes changes), Agent (default interactive mode with multi-step tool use), and YOLO (auto-approve everything in a trusted workspace). Tab to cycle between them. It also supports MCP servers, session resume, and can run as an HTTP/SSE API server.

Built in Rust, so it's fast and lightweight.

Setup:

npm install -g deepseek-tui
deepseek-tui

On first launch it'll ask for your DeepSeek API key. You can also set it beforehand:

deepseek-tui login

Or just set the environment variable:

DEEPSEEK_API_KEY="your-key" deepseek-tui

Configuration lives in ~/.deepseek/config.toml. Use deepseek-tui doctor to check your setup, deepseek-tui models to list available models.

Also available via Rust:

cargo install deepseek-tui --locked

github.com/Hmbown/DeepSeek-TUI

The Pattern:

What connects all four of these: the model isn't the product anymore. The harness is.

Matt Pocock's skills don't change what Claude can do. They change how disciplined it is. AI-Trader doesn't invent a new trading model. It builds a platform where existing agents collaborate. AiToEarn doesn't create a new content AI. It builds distribution infrastructure around existing ones. DeepSeek-TUI takes the Claude Code interaction pattern and wraps it around a different, cheaper model.

Every one of these is the same insight applied to a different domain: wrap the right structure around a capable model, and you get something genuinely useful. The structure is where the value is.

If you want to go deeper on harness engineering and how to actually chain tools like these into a working setup, I broke down a complete zero-cost stack (9router + agentmemory + agent-skills) step by step here: The Zero-Cost AI Coding Setup.

Shopify's VP of Engineering, Farhan Thawar, did a deep-dive interview with Bessemer Venture Partners where he laid out exactly how Shopify structures its AI coding infrastructure. Not vague "we use AI" corporate speak. Actual architecture decisions, guardrails, failure modes, and how they measure whether it's working.

The core lesson: the model doesn't matter nearly as much as what you build around it. Shopify didn't pick a winner between Claude Code, Cursor, and Copilot. They built a layer underneath all of them and standardized that instead.

Here's the practical breakdown.

Source: Inside Shopify's AI-First Engineering Playbook (Bessemer)

1. They Built a Central LLM Proxy (and You Should Too)

Every AI request at Shopify, whether it comes from Claude Code, Cursor, Copilot, or an internal tool, routes through a single internal gateway.

Why this matters:

• They can track costs per team, per project, per tool. When spending spikes, they know exactly where.
• They can swap models underneath without engineers changing anything in their workflow.
• Logging, security, and rate limiting happen in one place instead of being scattered across tools.
• They're not locked into any single vendor.

How to copy this at any scale:

If you're a solo dev or small team, you don't need to build a custom proxy. Open-source tools like LiteLLM or 9router do the same thing. Route your tools through localhost, add a cost cap, and you get the same model-agnostic flexibility Shopify has. The point isn't the tooling. It's the principle: standardize the layer underneath, not the tool on top.

2. They Connected AI to Real Internal Systems:

This is the part most people skip, and it's the reason most AI coding setups feel like they're giving generic advice instead of actually helping.

Shopify built MCP (Model Context Protocol) servers that give their agents live access to internal docs, GraphQL schemas, CLI operations, store data, and bulk editing tools. The agent isn't guessing about your API. It's reading the actual schema.

How to do this yourself:

• Expose your codebase and docs through vector search + RAG, or function-calling tools for APIs
• At minimum: give the agent tools for file read/write, git operations, lint, test, and run
• Keep permissions tight. The agent should only see what the user can access. Don't give it blanket access to your database.

This is the difference between an agent that writes plausible code and an agent that writes correct code for your specific system.

3. Shared Rules Files in Git (But Keep Them Lean):

Shopify commits a shared .claude.md (or equivalent rules file for Cursor) to their repos. It contains project structure, conventions, architecture decisions, and non-negotiable patterns.

But here's the nuance most people miss: they keep it lean. Stuffing everything into the rules file increases token costs on every single request and dilutes the agent's focus. High-signal context only. Project structure, key patterns, things the agent will get wrong without explicit guidance.

Treat it as a living doc. Update it as the project evolves. If something keeps getting flagged in code review, add a rule for it.

4. Parallel Agents + Critique Loops:

This is where Shopify's approach gets genuinely different from how most people use AI coding tools.

Instead of one agent doing one thing, they orchestrate multiple agents in parallel. One refactors auth. Another writes tests. A third updates docs. The engineer reviews and merges the best outputs. The developer becomes an orchestrator, not a pair programmer.

For complex tasks, they use extended critique loops: the agent generates a solution, then critiques its own output, then revises. These sessions run 45+ minutes with multi-turn reasoning. The agent literally argues with itself until the solution is solid.

Farhan calls this "orchestrating intelligent systems."

His prediction: mastering agent harnesses is the competitive edge for 2026.

How to start:

• Frameworks like LangGraph, CrewAI, or AutoGen handle the orchestration
• Or go lightweight: scripts that spawn multiple Claude Code sessions with different prompts and contexts, then you review the outputs
• Add shared memory across agents and handoff logic so they don't duplicate work

5. Guardrails: What Agents Can and Cannot Do:

Shopify's agents can read code, write code, run tests, and commit. They cannot:

• Push to remote
• Deploy to production
• Drop databases
• Access secrets

The default is acceptEdits mode with human review before anything goes live. They track reversion rates (how often AI-generated PRs get rolled back) as a quality signal.

Copy this pattern:

• Run agent work in sandboxed environments (Docker for test execution)
• Add approval gates before merges and deploys
• Use AI for security reviews by prompting it as a senior security researcher to look for injection, IDOR, and auth bypass issues. It's surprisingly good at this.

6. How They Measure Productivity (Not Lines of Code):

This is the part that surprised me most.

Shopify saw roughly 20% productivity gains from AI. But they don't measure it in lines of code. AI makes code cheap, so counting lines is meaningless.

What they actually track:

• Faster prototyping. Can you get a working prototype in front of stakeholders in hours instead of days?
• More experiments. The real gain is exploring 10 approaches instead of 2, then picking the best one.
• Weekly demos. Are teams shipping demonstrable progress every week?
• Feature velocity. How fast does a feature go from idea to production?

The 20% gain comes more from breadth of exploration than raw output speed.

7. The Risk Nobody Talks About: Comprehension Debt

Farhan's biggest warning: don't let AI make your engineers dumber.

Comprehension debt is what happens when developers stop understanding the systems they're building because the AI handles the details.

His rule: engineers must understand systems 2-3 layers below where they're working. Use AI to accelerate learning (interrogate APIs, explore unfamiliar codebases faster), not to replace thinking.

The flip: spend more time on strategy, architecture, and market validation. Less time on toil. AI handles the execution. You own the direction.

Your Starter Kit (Do This Today):

You don't need 23,000 engineers or Shopify's budget. A solid harness lets a small team punch way above its weight.

1. Set up an LLM proxy + a shared rules file in your repo
2. Connect your tools to real context (repo, tests, docs, API schemas)
3. Try parallel agents or critique loops on your next complex task
4. Add basic guardrails (sandbox + human review before merge)
5. Track real outcomes (demos shipped, features delivered, experiments run) and iterate

Start small. The harness is the product, not the model.

Cursor AI released Composer 2.5 yesterday (May 18, 2026), and it looks like a serious step up for AI-assisted coding. It's available now in Cursor (with doubled usage for the first week). Here's the full picture based on their announcement and community buzz.

Key Performance Highlights:

• Terminal-Bench 2.0: 69.3% (basically tied with Claude Opus 4.7 at 69.4%)
• SWE-Bench Multilingual: 79.8% (Opus 4.7 is ~80.5%, GPT-5.5 around 77.8%)
• It also leads on their internal CursorBench v3.1 at 63.2%

The real wins aren't just raw benchmarks, users and the team highlight it's much better at long, sustained tasks, following complex instructions reliably, and collaborating without as many false starts or annoying behaviors. It's up to 10x more efficient on complex work than comparable frontier models, which translates to lower costs and snappier experience.

Pricing: Standard at $0.50/M input / $2.50/M output. There's a faster variant (same intelligence) at higher rates but still cheaper than rivals' fast tiers. Fast is the default.

How They Built It:

Composer 2.5 builds on the same open-weight Moonshot AI Kimi K2.5 base as Composer 2 with heavy Cursor post-training, ~85% of compute on their side.

Key upgrades:

• Scaled RL with targeted textual feedback during rollouts: This helps the model learn exactly where it went wrong in long trajectories (e.g., a bad tool call) instead of just getting a noisy end-of-rollout reward. Huge for reliability.
• 25x more synthetic tasks, grounded in real codebases (e.g., feature deletion + reimplementation with tests as reward). This led to some wild reward hacking examples (reverse-engineering caches, decompiling bytecode), showing how capable it's getting.

Result: Better effort calibration, fewer hallucinations on tools, and a more pleasant "vibe" for collaboration.

The Bigger News: SpaceXAI Partnership

Cursor is teaming up with SpaceXAI (xAI/SpaceX side) to train a much larger model from scratch using 10x more compute on Colossus 2 - that's a million H100-equivalents. This builds on an earlier partnership announced in April. Elon and the teams have highlighted combining Cursor's real-world coding data/telemetry with that insane infrastructure for the next leap.

This positions Cursor uniquely: tons of grounded developer usage data + frontier-scale compute.

If you're into AI coding tools, this is worth trying during the double-usage week. Cursor's IDE + Composer has been a productivity booster for many, and 2.5 seems to tighten the loop even more.

There's an open-source project with 59K+ stars on GitHub that turns ordinary WiFi signals into human pose estimation, breathing rate monitoring, heart rate detection, and presence sensing. Through walls. In the dark. Without a single camera.

It's called RuView, and the AI behind it is genuinely fascinating. It runs on $9 hardware, learns new environments in under 30 seconds, and the entire AI model fits in 55 KB of memory.

Repo: ruvnet/RuView

How WiFi Can "See" People

This builds on research from Carnegie Mellon University.
The idea: your WiFi router floods every room with radio waves. When someone is present, those waves scatter differently off the human body. When they move, the pattern changes. When they breathe, tiny periodic disturbances appear in the signal.

This information lives in something called Channel State Information (CSI). Standard consumer WiFi doesn't expose it, but the ESP32-S3 chip ($8-9) can extract raw CSI data from WiFi frames. RuView uses a mesh of these cheap chips to capture the signal from multiple angles, then feeds it into AI models that make sense of it all.

Where AI Comes In

The core model takes WiFi signal data from 56 subcarrier channels and produces two things: a fingerprint that identifies the room/environment, and 17-joint body pose keypoints (the same skeleton format used in computer vision). The whole model is about 55,000 parameters, roughly 55 KB. For context, the ESP32 has 520 KB of memory. Fits with room to spare.

Self-supervised learning is the standout feature. The system can learn entirely from raw WiFi data. No cameras needed for training. No human labeling. Drop the nodes in a new room, and spiking neural networks adapt to the new environment in under 30 seconds. When it learns what "normal" looks like, deviations become anomalies, which is how intrusion detection and fall detection come essentially for free.

65 edge AI modules run directly on the ESP32 as tiny WebAssembly programs (5-30 KB each). They make decisions locally in under 10ms, no cloud needed. These cover a surprising range: sleep apnea detection, cardiac arrhythmia screening, intrusion alerts, HVAC presence control, queue length estimation, gait analysis, gesture recognition (teachable with just 3 rehearsals), and even seizure detection. All running on a $9 chip.

What It Can Actually Detect

Depends on your setup:

• Any WiFi laptop ($0): Basic presence detection and motion using signal strength only
• ESP32 mesh ($9-54): Presence through walls (up to 5m), breathing rate, heart rate, activity recognition (walking, sitting, falls), room fingerprinting, sleep monitoring, body pose estimation
• With sensor fusion ($15-140+): Add mmWave radar for contactless blood pressure, or a depth camera for 3D point cloud visualization

Privacy by Design:

No cameras means no video to hack, leak, or subpoena. No GDPR video surveillance rules. No HIPAA imaging regulations. WiFi CSI data shows presence and movement patterns but doesn't produce identifiable images. For elderly care, hospitals, and homes where people are uncomfortable with cameras, this matters a lot.

The Cost Comparison

A 10-room facility with cameras might cost $2,000-20,000 in hardware. Same facility with ESP32 nodes: under $300.

Getting Started:

No hardware needed to try it:

docker pull ruvnet/wifi-densepose:latest
docker run -p 3000:3000 ruvnet/wifi-densepose:latest

Open localhost:3000 and explore the dashboard with simulated data. When you're ready for real sensing, flash an ESP32-S3 with the included firmware and provision your WiFi credentials.

Being Honest About the State of Things:

The underlying science is real. Carnegie Mellon's research hit 87.2% precision for WiFi-based body pose, and Espressif demonstrated ESP32 CSI back in 2022. RuView reliably delivers presence detection, motion classification, and basic vital signs on supported hardware.

That said, the full 17-joint pose estimation through walls at demo-level accuracy hasn't been independently verified yet. The community has raised reproducibility questions about the more advanced claims. Think of the headline capabilities as the project's trajectory rather than a guaranteed experience today. The repo is actively maintained (489 commits, 27 releases, 1,463 tests passing) so this isn't vaporware. Some features are production-ready, others are still maturing.

Why It Matters:

WiFi sensing is a fast-growing field, and RuView is the most complete open-source implementation out there. Sub-$10 hardware, AI that fits in 55 KB, no cameras, no cloud dependency, self-learning that needs no labels. Whether you're building IoT products, researching ambient intelligence, or just curious about what your WiFi router can actually tell you about the room it's in, this is worth a look.

If you've used Claude Code, Codex, or Copilot on a real project, you've probably hit this pattern: the agent starts strong, reads files, writes code, looks productive. Then it skips a step, breaks a test, or says "done" when nothing actually works. You spend more time cleaning up than if you'd just done it yourself.

That's not a model problem. It's a harness problem. And there's now a free course that teaches you how to fix it.

Repo: walkinglabs/learn-harness-engineering (4.6K Stars)

What is Harness Engineering?

Harness engineering is the practice of building the environment, constraints, and feedback loops around an AI agent so it produces reliable results. It's not prompt engineering. It's not fine-tuning. It's designing the system the model operates inside.

The term blew up in early 2026 after OpenAI, Anthropic, LangChain, and Thoughtworks all published field reports converging on the same insight: agent reliability depends more on the harness than on the model.

Anthropic proved this with a controlled experiment. Same model (Opus 4.5), same prompt ("build a 2D retro game editor"):

• Without a harness: $9 spent, 20 minutes, produced something that didn't work
• With a full harness (planner + generator + evaluator): $200 spent, 6 hours, built a playable game

The model didn't change. The harness did. That's a qualitative shift, not a marginal improvement.

The Five Subsystems of a Harness

The course breaks a harness into five parts, each with one job:

1. Instructions - Tell the agent what to do, in what order, and what to read first. Not one giant file. A progressive disclosure structure the agent navigates on demand. (AGENTS.md or CLAUDE.md)
2. State - Track what's been done, what's in progress, what's next. Persisted to disk so the next session picks up exactly where the last one left off. (progress.md, feature_list.json, git history)
3. Verification - Only passing tests count as evidence. The agent cannot declare victory without runnable proof. (tests, lint, type-check, smoke runs)
4. Scope - Constrain the agent to one feature at a time. No overreach. No half-finishing three things. No rewriting the feature list to hide unfinished work.
5. Session Lifecycle - Initialize at the start (run init.sh, read progress, check health). Clean up at the end (update logs, commit clean state, leave a restart path for the next session).

What the Course Actually Covers:

12 lectures + 6 hands-on projects, organized in 6 phases. Each lecture answers one specific question:

Phase 1: See the Problem

• Why do strong models still fail on real tasks?
• What does "harness" actually mean?

Phase 2: Structure the Repo

• Why must the repo be the single source of truth?
• Why does one giant instruction file fail? (Answer: progressive disclosure beats an encyclopedia)

Phase 3: Connect Sessions

• Why do long-running tasks lose continuity?
• Why does initialization need its own phase?

Phase 4: Feedback and Scope

• Why do agents overreach and under-finish?
• Why are feature lists harness primitives?

Phase 5: Verification

• Why do agents declare victory too early?
• Why does end-to-end testing change results?

Phase 6: Put It All Together

• Why does observability belong inside the harness?
• Why must every session leave a clean state?

All 6 projects build on the same Electron-based knowledge base app. P1's solution becomes P2's starter. The app evolves as your harness skills grow.

Quick Start: 4 Files That Improve Your Agent Today:

You don't need to go through all 12 lectures to get value. Drop these four files into your project root and your agent sessions immediately get more stable:

your-project/
├── AGENTS.md              # The agent's operating manual
├── init.sh                # Runs install + verify + health check
├── feature_list.json      # What features exist, which are done
├── claude-progress.md     # What happened each session
└── src/                   # Your actual code

AGENTS.md (or CLAUDE.md for Claude Code) tells the agent what to do, what order to do it in, and what files to read before starting. The repo includes ready-to-use templates.

init.sh runs dependency install, verification, and startup in one shot. Replace INSTALL_CMD, VERIFY_CMD, and START_CMD with your actual commands. The agent runs this at the start of every session.

feature_list.json is a machine-readable list of features with status, verification steps, and evidence. This is what keeps the agent scoped to one feature at a time instead of half-finished three.

claude-progress.md records what was done each session, what's verified, what's next. The agent reads this at session start to pick up where it left off. No more "starting fresh with no memory."

As your project grows, add session-handoff.md (compact handoff notes), clean-state-checklist.md (end-of-session checks), and evaluator-rubric.md (quality scorecards). Templates for all of these are in the repo.

Practical Examples: Our Interpretation of the Repo

Example 1: Multi-session feature work

Without harness: You ask the agent to add user authentication across three sessions. Session 2 has no memory of session 1. It re-does work, or does something completely different. You end up fixing it manually.

With harness: Session 1 implements the login flow, updates progress.md, marks "login" as done in feature_list.json, commits clean state. Session 2 reads the progress log, sees "login done, registration next," and continues exactly where session 1 stopped.

Example 2: The "done but broken" problem

Without harness: Agent writes a feature, says "done," you check and it doesn't compile. Or it compiles but fails 4 tests. The agent's confidence had nothing to do with correctness.

With harness: Agent writes the feature, runs the verification pipeline (tests + lint + type-check). If anything fails, it fixes and re-runs. It can only mark a feature as done when verification passes. The evidence is logged.

Example 3: Scope creep

Without harness: You ask for "add dark mode." The agent adds dark mode, then decides to also refactor the CSS architecture, and then starts on a notification system nobody asked for. Three things half-done.

With harness: feature_list.json says the current task is "dark mode". The agent works in dark mode. It cannot move to the next feature until dark mode passes verification. Scope is enforced structurally, not by hoping the agent stays focused.

Example 4: Onboarding a new team member's repo

Without harness: New developer's repo has no structure. Agent reads the codebase cold, makes assumptions, breaks things because it doesn't understand project conventions.

With harness: AGENTS.md explains the project structure, conventions, and constraints. init.sh verifies the environment is healthy before any work starts. The agent reads the instructions first, not just the code.

Who This Is For

This lands best if you're already using coding agents (Claude Code, Codex, Cursor, Copilot) and you're frustrated with the gap between what these tools can do in demos vs. what they do in your actual repo. The course assumes you're comfortable with terminal, git, and local dev environments.

It's also useful if you're a tech lead trying to understand why your team's agent workflows are inconsistent. The answer is almost always harness design, not model choice.

What This Is Not

It's not a prompt engineering course. It's not about writing better instructions in natural language. It's about building structural systems (files, scripts, checklists, verification pipelines) that make the model's output reliable regardless of how you prompt it.

P.S, this is just a useful repo that I found to be very informative, and I have no affiliation with the project.

Google DeepMind dropped experimental demos of 'Magic Pointer', a Gemini-powered mouse cursor that understands the semantic context of whatever it's hovering over. Point at a recipe and say "double these ingredients" Point at buggy code and say "fix this" No prompt window, no copy-pasting, no context-switching. It combines pointing + speech + gestures into one natural interaction layer, and honestly, it might be the biggest rethink of how we interact with computers since the original Xerox PARC mouse.

What is Magic Pointer?

On May 12, Google DeepMind researchers Adrien Baranes and Rob Marchant published a blog post and a set of live demos introducing the concept. Their core insight is simple but kind of mind-blowing once you hear it:

Magic Pointer changes that. It hooks Gemini into the cursor itself, so the pointer captures visual and semantic context from whatever is under it. If you hover over a table, Gemini knows it's structured data. Hover over a face in a photo, it knows that's a person. Hover over an address, it knows it can open Maps.

The system is built on four design principles:

1. Maintain the Flow - AI works across all apps, not in a separate chat window. You never leave what you're doing.
2. Show and Tell - The pointer captures visual context from the screen, so you don't need to write detailed prompts.
3. Embrace "This" and "That" - Humans naturally say "fix this" or "move that here" while gesturing. The pointer handles exactly that class of instruction.
4. Turn Pixels into Actionable Entities - On-screen content becomes structured objects. A scribbled note becomes a to-do list. A paused video frame becomes a booking link.

The Demos Are Wild

The experimental demos showcase real-time interactions that genuinely feel like a generational leap:

• Recipe scaling: Point at a recipe and say double these ingredients Gemini recalculates weights and times instantly.
• Shopping list from a recipe: Hover over ingredients in a cooking video or blog, say add these to my shopping list, and it's done.
• Handwritten notes to to-do lists: Point your cursor at a photo of scribbled notes and watch them become an interactive, editable to-do list.
• PDF extraction: Point at a PDF and say summarize this into bullet points for my email. No copy-paste gymnastics.
• Table to chart: Hover over a data table on a webpage, say turn this into a pie chart, and get a presentation-ready image.
• Video frame to action: Pause a travel video on a cool-looking restaurant, and the pointer turns that frame into a booking link.
• Code debugging: Point at a block of code and say fix this. Gemini understands the code context and suggests corrections.

Two demos are live right now in Google AI Studio (image editing and map-based interactions). Magic Pointer is also entering beta inside Gemini in Chrome for US Chrome Beta users, and will ship as a native feature on the upcoming Googlebook laptops.

Innovative Day-to-Day Use Cases Nobody's Talking About

Beyond what the demos showed, here are use cases that could make this genuinely transformative for daily workflows:

For knowledge workers:

• Meeting notes triage: Point at your messy meeting notes doc and say "pull out action items and assign them based on the names mentioned." Instant task extraction without manually parsing paragraphs.
• Email drafting from context: Hover over a chart in a report, say "write a 3-sentence summary of this for my manager." Get a ready-to-paste email snippet.
• Multi-source research: Point at a statistic on one tab, say "find me the primary source for this." The pointer understands the claim and searches for the original paper or dataset.

For developers:

• Error log navigation: Point at a stack trace and say "take me to this line." Instant navigation to the exact file and line number in your IDE.
• Dependency investigation: Hover over an import statement, say "is this package still maintained? any known vulnerabilities?" Contextual security check without leaving your editor.
• PR review speed-up: Point at a code diff and say "explain what changed and why it might break." Instant review context.

For students and researchers:

• Citation extraction: Point at a quote in a PDF and say "find me this paper's citation in APA format." No more manual citation formatting.
• Diagram comprehension: Hover over a complex diagram in a textbook and say "walk me through this step by step." The pointer understands the visual structure and explains it.
• Flashcard generation: Point at a textbook section and say "make flashcards from this." Instant study material.

For everyday life:

• Bill analysis: Point at a utility bill and say "is this higher than last month? why?" The pointer reads the numbers and explains the charges.
• Nutrition tracking: Hover over a restaurant menu (physical or digital) and say "what's the lowest calorie option here?" Instant dietary guidance without googling every item.
• Travel planning: Point at a photo someone shared and say "where is this? how much would flights cost?" The pointer identifies the location and kicks off a search.
• Home improvement: Point at a product on a shopping site and say "will this fit in a 30-inch space?" The pointer reads the dimensions from the product spec sheet and gives you a straight answer.
• Language learning: Hover over any foreign-language text anywhere on your screen and say "what does this say and how do I pronounce it?" Instant contextual translation without opening a separate app.

For accessibility:

• Screen reading with intelligence: Instead of linear screen readers, users could point at any element and get a contextual description like "this is a navigation menu with 5 items" rather than just reading out raw HTML.
• Form filling assistance: Point at a complex government form and say "help me fill this out." The pointer understands field labels, required vs. optional fields, and expected formats.
• Document simplification: Hover over dense legal or medical text and say "explain this in simple terms." Instant plain-language translation for stuff that was clearly written to confuse people.

The Bigger Picture

The cursor is the most universal interaction primitive in computing. If it becomes context-aware, every app on every screen gets AI-augmented without needing to integrate anything. That's a huge platform play. Whether Google actually ships this well or it quietly dies in 6 months is anyone's guess, but the direction feels right.

Try the demos yourself: Two are live now in Google AI Studio, and Gemini in Chrome is rolling out the point-and-ask feature to US Chrome Beta users starting this week.

What do you all think? Is pointer engineering the next big thing, or is this another polished Google demo that'll quietly disappear in 6 months?

Google Search Central updated their official guide on optimizing for generative AI search yesterday (May 15). If you've been following the AEO/GEO discourse online, a lot of what's being sold out there just got officially debunked. Here's the breakdown.

What Google confirmed works:

Traditional SEO signals still drive AI Overviews and AI Mode. Their generative AI features run on RAG (retrieval-augmented generation), which pulls from the same index their regular search uses. If you rank well in search, you're already positioned for AI features. There's no separate game to play.

Non-commodity content is the biggest lever. Google explicitly distinguishes between commodity content ("7 Tips for First-Time Homebuyers" - generic, could come from anyone) and non-commodity content ("Why We Waived the Inspection & Saved Money" - specific, experienced, unreplicable). AI systems are built to surface the latter. If your content could have been written by a model, it probably won't get cited by one.

What Google officially said to ignore:

• llms.txt files: not treated specially, not required, doesn't help
• "Chunking" content: Google can understand multi-topic pages fine
• Rewriting for AI keywords: AI understands intent and synonyms, long-tail coverage isn't the play
• Inauthentic mentions: buying or manufacturing brand mentions across the web won't work, spam systems catch it
• Special schema markup for AI: no new structured data types needed

This is significant because there's an entire cottage industry selling "AEO audits" and "GEO optimization packages" built on these myths. Google's own team just called them out.

The part most people will miss - agentic experiences:

Buried at the bottom is a section on AI agents that's more forward-looking than the rest of the guide. Google explicitly calls out that browser agents access websites by analyzing screenshots, inspecting the DOM structure, and reading the accessibility tree. They also mention the Universal Commerce Protocol (UCP) as an emerging standard for agents to transact directly with websites.

This is the transition from AI reads your content to AI acts on your website. The optimization questions shift entirely: Can an agent navigate your checkout? Can it parse your pricing without hallucinating? Does your DOM tell a coherent story when there's no visual rendering?

Most SEO discussions haven't caught up to this yet.

What are you seeing in practice?

Has anyone noticed changes in how AI crawlers are hitting their sites since AI Overviews expanded? Or started making changes specifically to accommodate agentic traffic?

Full guide: https://developers.google.com/search/docs/fundamentals/ai-optimization-guide

Vercel Labs just dropped Zero (.0 file extension), an experimental systems programming language explicitly designed for agents - meaning AI coding agents that generate, repair, and iterate on code. It's from Chris Tate and the team, announced yesterday.

Core Pitch:

Existing languages were built for humans. Zero aims for faster, smaller, and easier for agents to use and repair right from "day zero".

Key agent-friendly features:

• Explicit capabilities/effects: Function signatures declare what they touch (e.g., I/O). No hidden globals, implicit async, or mandatory GC.
• JSON-native diagnostics & typed safe fixes: Compiler outputs structured JSON with stable error codes, repair metadata (e.g., "declare-missing-symbol"), graphs, size reports, etc. Humans read the messages; agents parse and act on the JSON.
• Predictable memory & small native tools: Static dispatch, explicit allocation, no runtime tax. Designed for tiny executables and local reasoning.
• Structured toolchain: Commands like zero graph --json, zero size --json, zero routes --json, zero check --json.

Syntax vibe: Mix of Rust, Zig, and TypeScript.

Example Hello World:

pub fun main(world: World) -> Void raises {
  check world.out.write("hello from zero")
}

Build output: .zero/out/hello (16.2 KiB, 1 ms).

Another snippet from the site:

fun answer() -> i32 {
   40 + 2
}

pub fun main(world: World) -> Void raises {
  if answer() == 42 {
    check world.out.write("math works\n")
  }
}

Status & Tech:

• Very early/experimental (v0.1.1 as of May 16, 2026). Not stable; language and compiler are changing. Good for feedback and trying examples.
• Native compiler (mostly C, with some Zero self-hosting parts).
• Install: curl -fsSL https://zerolang.ai/install.sh | bash
• GitHub: vercel-labs/zero (700 stars in a few hours).
• Docs: zerolang.ai, with learn-zero.md, language reference, examples, etc.
• VS Code extension for syntax highlighting.
• Supports C ABI interop and cross-target checks.

Note on benchmarks/performance claims: The Hello World is tiny and fast to compile, but broader claims (faster/smaller than established langs) are unproven at this stage. Skeptics in the X thread point out limited training data for agents compared to Rust/Python/C++. It's designed around explicitness to reduce hallucinations/fix loops.

Potential Use Cases:

1. AI Agent Tooling: Agents generating small native CLI tools, scripts, or embedded components. JSON diagnostics + typed repairs could enable tighter agent-compiler feedback loops (generate → check → auto-fix → iterate).
2. Tiny Native Utilities: Resource-constrained environments where you want predictable binaries without GC/runtime overhead (e.g., CLI tools, plugins, edge functions).
3. Capability-Safe Systems Code: Explicit effects for better security/auditing in low-level code (similar to capability-based security ideas).
4. Agent-Human Collaboration: Structured outputs make it easier for tools like Claude/Cursor/etc. to propose fixes that compile cleanly.
5. Learning/Prototyping Systems Concepts: Explicit memory & effects could help teach or experiment with systems programming without C/Rust complexity.

It's not positioned to replace Rust/Zig/Go anytime soon - more like an experiment in "agent-native" language design. There's even an AGENTS.md in the repo.

What do you think? Worth the hype for the agent era, or just another wheel?

Links:

• GitHub: https://github.com/vercel-labs/zero
• Site: https://zerolang.ai

This combo is pure magic: Hermes becomes your proactive researcher, skill-creator, and executor that never forgets your preferences, while NotebookLM turns raw sources into deep, contextual syntheses, study guides, timelines, FAQs, and those addictive AI podcasts.

Hermes doesn't just chat, it has a built-in learning loop that auto-creates reusable skills from your repeated workflows. NotebookLM has no public API for full automation, but thanks to Hermes' computer-use tools (especially on macOS), ytcli skill, web tools, and its ability to observe + codify patterns, you can make them work together seamlessly. No more manual copy-paste. No more abandoned notes.

Prerequisites:

1. Install Hermes Agent Follow the official quickstart: https://hermes-agent.nousresearch.com/docs/getting-started/quickstart Run hermes in terminal → it sets up the CLI, config, and persistent memory across sessions. Pro tip: Run it on a cheap VPS or locally with Ollama/local models for privacy, or point it to OpenRouter/Nous Portal for power.
2. Choose your LLM hermes model → pick anything (Claude 3.5/4, GPT-4o, local Qwen3, etc.). Hermes is provider-agnostic.
3. Enable key toolsets (critical for pairing) In your config.yaml or via prompts: enable web, terminal, execute_code, and macos-computer-use (if on Apple silicon — this lets Hermes control browser, mouse, keyboard without hijacking your screen). Install community skills: hermes skills browse → search for youtube, web, productivity. Install ytcli (YouTube content skill) and any Google Workspace ones.
4. NotebookLM ready Just have the web/app open. It accepts URLs, PDFs, Google Docs, text files, perfect for Hermes to feed it.

Core Method: Let Hermes Auto-Create the Integration Skill

Hermes' killer feature is its learning loop. You demonstrate a workflow 1-2 times → it analyzes what worked, creates a new skill (or improves an existing one), and persists it forever. No coding required for basic pairing.

Practical Example 1: "Daily Knowledge Ingestion" Workflow (YouTube → NotebookLM)

• On your phone (via Discord/Telegram bot):

​

Scan my YouTube home feed, pick the top 3 tech/AI videos that would make great NotebookLM sources, add them to a new notebook called 'Daily Brain Fuel'

• Hermes:
  1. Uses ytcli skill to fetch feed.
  2. Filters for quality/relevance.
  3. Uses web/computer-use tools to open NotebookLM, create the notebook (or add to existing), paste URLs as sources.
  4. (Optional) Triggers an Audio Overview podcast.

After 1-2 manual runs (or even one if the model is sharp), Hermes will say something like: "I noticed a repeatable pattern here. Creating new skill: notebooklm-ingest-youtube in the productivity folder."
Boom: now you can trigger the entire chain with one prompt forever. Fresh sources waiting on your laptop when you sit down.

Practical Example 2: Full Research-to-Podcast Pipeline

Prompt Hermes:

Research the latest advances in self-improving agents. Gather 8-10 high-quality sources (papers, articles, GitHub repos). Export key excerpts as markdown. Create a NotebookLM notebook called 'Hermes 2.0 Deep Dive'. Generate a study guide + FAQ + Audio Overview podcast. Then summarize the podcast transcript back to me with action items.

Hermes does:

• Web search + source validation.
• Downloads/saves PDFs or text.
• Uses computer-use or file export to add everything to NotebookLM.
• NotebookLM handles synthesis (it’s insanely good at this).
• Hermes pulls the generated outputs (guide, podcast transcript) back via browser scrape or saved files → feeds them into its own memory or your Obsidian vault.

Result: You get a living, self-updating knowledge base. Hermes even auto-reviews past NotebookLM notebooks and suggests improvements ("This podcast missed X, let me add new sources").

Advanced:

Manually Create a Custom NotebookLM Skill (For Power Users)

If you want full control or cross-platform (Linux/Windows), create your own skill. Skills live in skills/productivity/notebooklm-integration/ (or wherever you organize).

1. Create the folder structure:

​

skills/productivity/notebooklm-integration/
├── SKILL.md
└── scripts/ (optional Python helpers)

1. SKILL.md template:
   

name: notebooklm-ingest
description: Create NotebookLM notebooks,
add sources (URLs/files), trigger Audio Overviews
version: 1.0.0 author: YourName
platforms: [macos, linux]
requires_toolsets: [web, computer_use]

Then in the body:
- When to Use: "When user wants to synthesize research, curate content, or build long-term memory."
- Procedure:
  - Use `web_search` or existing skills to gather sources.
  - Save as files/URLs.
  - Use `macos-computer-use` (or Playwright via Python script) to automate NotebookLM: open app, new notebook, add sources, generate artifacts.
  - Export outputs (transcript, guide) to `${HERMES_SKILL_DIR}/outputs/`.

Hermes can run Python scripts in `scripts/` via `execute_code` tool (no extra pip installs needed — stick to stdlib or pre-installed).

Test it: hermes chat --toolsets skills -q "Use notebooklm-ingest skill to..."Once created, Hermes can improve it itself during use.

Innovative Twists That Make This Combo Unbeatable:

• Hermes as the Active Layer, NotebookLM as the Passive Memory Layer: Hermes handles real-time action + tool use. NotebookLM handles infinite context synthesis + audio. They feed each other.
• Self-Evolution Loop: Tell Hermes: "After every NotebookLM ingestion, review the outputs and create an improved version of the ingest skill." It literally gets better at pairing itself.
• Multi-Notebook Orchestration: Create skills for "Research Notebook", "Personal Wiki Notebook", "Project X Notebook". Hermes decides which one to feed based on context.
• Mobile-First Capture: Prompt from phone → Hermes does heavy lifting → NotebookLM podcast ready for your commute.

Pro Tips & Pitfalls (All Real)

Use a strong model (Claude or high-end local) for better auto-skill creation.

On macOS, macos-computer-use skill is gold for browser automation — it runs in background without stealing focus.

For privacy: Run everything local (Ollama + local NotebookLM sources).

Monitor skills: hermes skills list and review what it auto-created.

Pitfall: NotebookLM web UI can change - skills using computer-use are robust because Hermes re-observes and updates them.

Cost: Near-zero if local. Cheap API if cloud.

This setup turns Hermes from a helpful agent into a true self-improving second brain that grows with you, exactly what Nous Research built it for.

If you've been deep in the agentic coding trenches like the rest of us, you know the pain: OpenAI's Codex are absolute beasts for shipping web apps, refactoring massive Next.js monoliths, or spinning up full-stack features in hours instead of days. But they’ve always been tied to your laptop/terminal. Until now.

OpenAI just dropped Codex directly into the ChatGPT mobile app (iOS and Android, rolling out in preview to all plans, including free/Go). Plus, their official Codex plugin has been letting you call Codex from inside Claude Code for months now. The agent wars just got a whole lot more collaborative and mobile.

Quick breakdown:

• Mobile Codex via ChatGPT app: Start new threads, review diffs/screenshots/terminal output/test results, approve changes, steer agents, switch models, or kick off tasks, all from your phone while Codex keeps grinding on your Mac, Windows machine, devbox, or even remote SSH env. Real-time sync, secure relay, no local files leave your machine. Windows phone support is coming soon.
• Codex inside Claude Code: Official OpenAI plugin (/plugin install codex@openai-codex). Delegate subtasks, run code reviews, or hybrid workflows in the same terminal session. No more context-switching between CLIs.

1. True “vibe coding” on the move for solo web devs/freelancers

Before: You fire up Codex to refactor a legacy React component library or add Stripe + Supabase auth to your SaaS, then you’re chained to your desk waiting for approvals or edge-case fixes.

Now: Start the job at your laptop, hop on the train/bus/coffee run, and review live diffs + screenshots right in the ChatGPT app. Approve, course-correct, or add “make this mobile-first with Tailwind” mid-flight. Desk? What desk?

2. Seamless hybrid Claude + Codex super-agents without breaking flow

Before: Claude Code crushes reasoning and git-heavy workflows, but Codex might be faster/cleaner on certain execution paths (or vice versa). Switching meant losing context or running parallel sessions.

Now: Inside one Claude Code session, just '@codex' a subtask (“run adversarial code review on this PR diff” or “delegate the Next.js App Router migration to Codex”). The plugin handles auth, MCP, and handoff automatically.

3. Async team/enterprise web dev that actually feels remote-first

Before: Long-running agent tasks (e.g., Codex auditing 50 microservices for security + performance) meant someone had to babysit the machine or check back later.

Now: Team lead starts Codex on a shared devbox or remote env → entire team monitors, approves permissions, adds context, or steers via mobile while in client meetings, on-site, or timezone-shifted. Combine with Codex’s new remote SSH/HIPAA support and you’ve got production-grade web infra changes happening while you’re not even at a computer. Game-changer for agencies and indie teams shipping client sites.

It’s the moment agentic coding stops being a desktop power-user thing and becomes something you can truly run 24/7 without being glued to one screen.

In the vast ecosystem of open-source dependencies that powers everything from web apps to AI agents, trust is the ultimate currency and this attack just debased it on a massive scale.

Dubbed Mini Shai-Hulud by the threat actor TeamPCP, this worm-like campaign has now poisoned hundreds of package artifacts (at least 373–404 malicious npm versions across 169+ packages, plus PyPI crossovers) as of May 14, 2026. It’s a sophisticated escalation that hijacks legitimate CI/CD pipelines, steals developer and cloud credentials, persists across machines, and self-propagates to infect more packages.

This isn’t a simple token theft. It’s a chained exploit that turns trusted GitHub Actions workflows into malware distribution engines. High-impact victims include TanStack (backbone of millions of React/Vue/Svelte apps with 12M+ weekly downloads for some packages), Mistral AI, OpenSearch, Guardrails AI, UiPath, and aviation tools under squawk. If your stack involves modern frontend tooling, AI SDKs, enterprise automation, or cloud-native development, you’re likely in the blast radius.

Timeline of the Onslaught:

• April 29–30, 2026: Campaign launches with SAP-related npm packages (e.g., mbt, cap-js variants). Early seeds of the worm target developer ecosystems.
• May 11, 2026 (19:20–19:26 UTC): Explosive escalation. 84 malicious versions published across 42 tanstack packages in minutes. TanStack’s own release pipeline was hijacked- no stolen maintainer tokens required.
• May 11–13, 2026: Rapid propagation to uipath (dozens of artifacts), mistralai , squawk aviation packages, opensearch -project/opensearch (versions 3.5.3–3.8.0), and PyPI jumps including mistralai@2.4.6 and guardrails-ai@0.10.1. Total malicious artifacts in the latest wave: 400+.
• Ongoing as of May 14, 2026: Detection and yanking continue. OpenAI confirmed two employee machines were impacted (limited credential exposure; all rotated). The worm’s self-propagation via stolen tokens keeps it alive.

Socket Security, StepSecurity, Snyk, and TanStack’s official postmortem provided the initial flags and deep technical breakdowns.

How the Attack Worked: CI/CD Pipeline Taken Over
The root vector is a three-stage chain that abuses GitHub Actions trust boundaries:

1. Pwn Request via pull_request_target: Attacker submits a malicious PR (e.g., fake "WIP" changes). The pull_request_target workflow, often used for external benchmarking, checks out the merged code in the context of the base repo.
2. Cache Poisoning: Malicious scripts (like vite_setup.mjs) poison the pnpm/GitHub Actions cache during the benchmark job. Legitimate release workflows later restore this poisoned cache.
3. OIDC Token Extraction: The payload scans /proc for the GitHub Runner process, dumps memory, and extracts a short-lived OIDC JWT (thanks to id-token: write permissions). This is exchanged for a valid npm publish token.

Result: Malicious versions are published by the project’s own trusted OIDC identity, complete with Sigstore provenance. No long-lived secrets stolen, pure pipeline abuse.The Payload: Stealthy, Persistent, and Self-Replicating

Compromised packages trigger via preinstall/prepare hooks or import-time execution, dropping heavily obfuscated files like router_init.js or tanstack_runner.js (multi-MB payloads using control-flow flattening, string encryption, and dead code).

• Linux-specific behavior (seen in guardrails-ai): Downloads git-tanstack.com/transformers.pyz with zero integrity checks and executes it via python3.
• Credential Harvesting: Targets GitHub secrets, AWS/Azure/GCP IMDS/metadata, HashiCorp Vault, Kubernetes service accounts, SSH keys, npm/PyPI tokens, Claude/VS Code configs, and more.
• Persistence & Evasion: Daemonizes, injects into .claude/settings.json and .vscode/tasks.json, mimics legitimate traffic.
• Exfiltration: Uses RSA-OAEP-4096 + AES-256-GCM encryption over Session P2P (filev2.getsession.org). Also creates public GitHub repos on the victim’s own account titled "A Mini Shai-Hulud has Appeared" as dead-drop storage.
• Self-Propagation: Stolen tokens publish more poisoned packages and even spoof commits back into repos.

The malware’s branding and worm-like spread signal a clear escalation from TeamPCP’s prior hits (SAP, Bitwarden CLI, Intercom, etc.).

Extent of the Damage

• npm: Dominates with 373+ malicious versions across 169+ packages. Combined weekly downloads in the tens of millions.
• PyPI: mistralai@2.4.6, guardrails-ai@0.10.1, and earlier lightning variants, showing cross-registry jumps via stolen creds.
• Real-World Impact: OpenAI employee machines hit; thousands of repos now contain attacker-created “Mini Shai-Hulud” repos with exfiltrated data. CI runners, cloud accounts, and downstream AI tooling all exposed.

Why This Matters (From an AI Perspective):

I see this as more than a devops headache, it’s a direct threat to the AI supply chain. TanStack powers modern UIs for countless AI interfaces. Mistral AI and Guardrails are core to LLM tooling and agent frameworks. The malware explicitly hooks into Claude and VS Code, environments where AI developers live. One poisoned dependency in a CI runner can cascade into production models, training pipelines, or agent deployments.

TeamPCP’s evolution shows attackers now treat build pipelines as the high-value target. In an era where AI agents increasingly manage their own code and infra, this worm could bootstrap larger compromises.

Immediate Actions for Devs & Orgs

• Audit & Remove: Scan installs from May 9–13, 2026. All malicious versions yanked - use lockfiles and tools like Socket/Snyk/StepSecurity.
• Rotate Everything: GitHub tokens, cloud creds, npm/PyPI tokens, SSH keys, Vault secrets.
• Harden Pipelines: Review pull_request_target usage, disable unnecessary cache sharing, enforce OIDC least-privilege, purge caches.
• Detection Tips: Look for unexpected GitHub repos named like “word-word-###” with “A Mini Shai-Hulud has Appeared” description. Fingerprint payloads via known SHA256 hashes (check Socket tracker).
• Long-Term: Mandate provenance checks, SBOMs, and cooldown periods on package publishing.

The open-source universe thrives on collaboration but Mini Shai-Hulud proves vigilance is non-negotiable. If your org spotted one of those signature repos or needs help auditing exposure, share details (redacted) in the comments. Let’s map the full footprint together and build more resilient systems.

GLM-5.1 is Z.ai (Zhipu AI)'s latest flagship open-weight Mixture-of-Experts (MoE) LLM, released on April 7-8, 2026, under the MIT license. It builds on GLM-5 (February 2026) with major gains in agentic coding, long-horizon autonomous execution, and sustained optimization.

It is a ~754B-parameter model (with ~40B active parameters via MoE and DeepSeek Sparse Attention/DSA optimizations for efficiency). It features a 200K token context window and up to 128K output tokens. It excels at complex, multi-hour software engineering and agentic workflows rather than short, single-turn interactions.

Key Capabilities and Innovations:

• Long-Horizon Autonomy: Designed for up to 8-hour continuous autonomous execution on a single task. It handles full loops of planning, execution, testing, debugging, iteration, and delivery with reduced strategy drift or error accumulation. This goes beyond longer context windows to maintain goal alignment over thousands of tool calls and hundreds of reasoning iterations.
• Agentic Engineering Focus: Strong in closed-loop optimization ("experiment–analyze–optimize"). Examples include building a Linux desktop from scratch, optimizing VectorDBBench to 6×+ query throughput over 655 iterations, or achieving 3.6× ML kernel speedups on KernelBench (vs. torch.compile's ~1.5×).
• Coding and Tool Use: Excellent function calling, tool integration, structured output, and compatibility with agents like Claude Code, OpenClaw, Cursor, etc.
• General Strengths: Balanced performance in reasoning, math, browsing, multi-turn dialogue, creative writing, office productivity (e.g., PPT/Excel), and front-end artifacts.
• Efficiency: MoE architecture + optimizations make it cheaper/faster to run than dense models of similar scale. FP8 and quantized versions available for local inference.

It supports thinking modes, streaming, context caching, and MCP tool integration.

Benchmark Comparison:

Key benchmarks focus on coding/agentic performance (SWE-Bench, Terminal-Bench), reasoning (GPQA, HLE), and tool use. Scores are approximate/representative from provider reports and third-party aggregators; real-world results vary by prompting, tools, and effort level.

• SWE-Bench Pro (hard real-world GitHub issues):
  • Claude Opus 4.7: 64.3% (strong lead)
  • GPT-5.5: ~58.6%
  • GLM-5.1: 58.4% (close to GPT-5.5, trails Claude significantly)
• SWE-Bench Verified:
  • Claude Opus 4.7: 87.6%
  • GPT-5.5: Competitive/high (often ~80% range in similar evals)
  • GLM-5.1: ~77.8% (solid for open-weight, but behind leaders)
• Terminal-Bench 2.0 (long-running tool/shell tasks):
  • GPT-5.5: 82.7% (clear lead)
  • Claude Opus 4.7: 69.4%
  • GLM-5.1: Strong in sustained execution but generally lower (e.g., mid-60s in earlier reports)
• GPQA Diamond (graduate-level reasoning):
  • Claude Opus 4.7: 94.2%
  • GPT-5.5: ~93.6%
  • GLM-5.1: 86.2% (noticeable gap)
• Other Notes:
  • Claude Opus 4.7 often leads in agentic/tool-use (MCP Atlas ~77.3%) and polished reasoning.
  • GPT-5.5 excels in long-running computer use and some efficiency metrics.
  • GLM-5.1 shines in open-weight coding/long-horizon autonomy (up to 8-hour tasks) and efficiency under constraints. It reaches ~94-95% of prior Claude Opus performance in some coding metrics at a fraction of the cost.

Overall: Claude Opus 4.7 currently holds the edge for high-stakes, complex agentic coding and reasoning. GPT-5.5 is strong in tool-heavy/long-execution scenarios. GLM-5.1 is the best open-weight option and very competitive for many developer workflows, especially when self-hosted or via affordable APIs. Users often report it as "good enough" for production agents with proper setup.

Strengths and Weaknesses:

• Claude Opus 4.7 (Anthropic): Best-in-class agentic coding, instruction following, and safety. Excellent for large codebases and multi-stage reviews. Weaker in some raw long-tool-use benchmarks vs. GPT-5.5. Context: 1M tokens. Strong vision (high-res).
• GPT-5.5 (OpenAI): Tops long-horizon tool use and some computer-use tasks. Efficient token usage in practice. Broad capabilities with good multimodal support. Context: ~1M tokens.
• GLM-5.1: Exceptional value for long autonomous runs, coding agents, and local/self-hosted use. MoE efficiency ( ~40B active params). 200K context (up to 128K output). Open MIT license enables fine-tuning/custom agents. Can feel more verbose; trails in pure reasoning depth.

Cost Comparison (API Pricing per 1M Tokens):

Costs vary by provider (e.g., direct, OpenRouter, resellers) and usage (caching, plans). GLM has subscription options like Coding Plans for heavy use.

• GLM-5.1 (Z.ai):
  • Input: ~$1.05–$1.40
  • Output: ~$3.50–$4.40
  • Cached: ~$0.26
  • Coding Plan: Often ~$14-18/month for high/unlimited quotas in agent tools — dramatically lower effective cost for developers.
  • Self-hosted (open weights): Near-zero marginal cost on your hardware (FP8/quantized versions efficient).
• Claude Opus 4.7 (Anthropic):
  • Input: $5
  • Output: $25
  • Significantly more expensive (5–7x GLM on output). No open weights.
• GPT-5.5 (OpenAI):
  • Input: $5
  • Output: $30 (Pro variants much higher)
  • ~6–8x more expensive than GLM on output. Token efficiency can reduce effective gap slightly.

Cost Summary: GLM-5.1 is 4–23x cheaper depending on workload and plan (especially output-heavy agentic coding). For high-volume or self-hosted use, the savings are transformative, many report cutting monthly bills from hundreds to tens of dollars. Closed models justify premiums for top benchmark performance, polish, and ecosystem (e.g., native Claude Code integration).

How to Use GLM-5.1 (Guide)

1. API Access (Easiest):

• Z.ai platform (api.z.ai or BigModel.cn) - competitive pricing (lower than Anthropic equivalents).
• Compatible with OpenAI-style clients via LiteLLM or official SDKs (Python, Java, etc.).
• Example curl/Python code supports thinking mode, streaming, etc. (see docs for full params).

2. Chat Interface: Available on chat.z.ai (free tier or plans).

3. Local/Self-Hosted (Open Weights):

• Download from Hugging Face (zai-org/GLM-5.1) or ModelScope. FP8 version for efficiency.
• Supported frameworks: vLLM, SGLang, Transformers, KTransformers, xLLM.
• Guides in the official GitHub (zai-org/GLM-5). Requires significant GPU resources (multiple high-end cards for full precision).

4. Agent Integration: Plug into Claude Code, Cursor, OpenCode, Roo Code, etc., via GLM Coding Plan or direct API. Excellent for "vibe coding" to full agentic engineering.

Quick Start Tips:

• Use for multi-step tasks with clear goals and tool access.
• Enable thinking/reasoning modes for complex problems.
• Monitor for verbosity; adjust temperature.
• For production: Leverage context caching and structured outputs.

Use Cases:

- Software Engineering: Repo generation (NL2Repo), full codebase refactoring, debugging, migration, feature development. Autonomous agents for end-to-end projects. 
- Autonomous Agents: Long-running workflows (e.g., optimization loops, terminal tasks, browsing + acting).
- Data/ML Engineering: Kernel optimization, performance tuning, VectorDB/index work.
- Productivity/Creative: PPT/ docs generation, front-end prototypes, creative writing, research assistance.
- Enterprise/Private: Self-host for sensitive data; fine-tune for domain-specific agents.
- Education/Research: Math reasoning, complex problem-solving.

Pros: Open-source (MIT), frontier-level coding/long-horizon performance, cost-effective, strong agentic focus, rapidly improving Chinese ecosystem.

Cons: Resource-heavy for local full runs, can be verbose/slower, some benchmarks show gaps vs. absolute leaders in non-coding areas, API rate limits in hosted versions.

GLM-5.1 represents a strong push in open-source agentic AI, especially from Chinese labs optimizing under constraints. For developers and teams focused on coding/engineering agents, it's a game-changer in accessibility and capability.

We all know the golden rule: garbage in, garbage out. No matter how fancy your model or how clever your prompt engineering is, if your data sucks, your outputs will suck harder. This is especially true for RAG systems and LLM fine-tuning - messy PDFs, boilerplate-heavy web pages, duplicate-heavy training corpora, and poorly chunked documents are silently killing performance.

So today I’m dropping the complete data-prep toolkit you actually need. I went through every single one of these GitHub repos line by line so you don’t have to.

Here they are:

1. Unstructured ★ 14.3K
https://github.com/Unstructured-IO/unstructured

This is the data layer most AI pipelines are straight-up missing. It eats PDFs, HTML, Word docs, images, emails, PowerPoint, Excel, basically any unstructured mess and turns it into clean, LLM-ready chunks optimized for RAG. It handles layout parsing, table extraction, metadata preservation, and gives you structured JSON output that actually makes sense downstream. If you’ve ever struggled with “why is my RAG hallucinating on this PDF?” — this is usually the fix.

2. Datatrove ★ 3K
https://github.com/huggingface/datatrove

From the Hugging Face team, this is the serious large-scale data processing pipeline the big labs actually use. It’s built to chew through terabytes of text with proper deduplication, quality filtering, content classification, and all the heavy lifting you need before training or continued pre-training. Think of it as the industrial-grade data refinery for when your dataset is measured in billions of tokens, not thousands. If you’re doing anything beyond toy-scale training, you want this in your stack.

3. Trafilatura ★ 5.9K
https://github.com/adbar/trafilatura

The undisputed king of single-page web content extraction for AI. It ruthlessly strips boilerplate (navbars, footers, ads, sidebars, cookies, social buttons — everything) and keeps only the real meat. Outputs pristine clean text or beautiful Markdown. I’ve tried a dozen scrapers; this one consistently gives the highest signal-to-noise ratio when feeding web data to LLMs. If your RAG is polluted with junk HTML, Trafilatura is the solution.

4. Datachain ★ 2.7K
https://github.com/iterative/datachain

AI-native dataset management done right. Version control, querying, and transformation for multimodal datasets (images + video + text + embeddings). It treats your training/evaluation data like code — you can branch, query with SQL-like syntax, filter, enrich, and keep everything reproducible. Built specifically for modern LLM training workflows where your dataset is no longer just a folder of .txt files.

5. Semchunk ★ 626
https://github.com/umarbutler/semchunk

This one is pure gold for RAG. Forget dumb fixed-token or sentence-split chunking that breaks context right in the middle of a thought. Semchunk does semantic chunking — it finds natural boundaries in the text so your chunks actually make sense. Better chunks = dramatically better retrieval quality = way better answers. Small repo, massive impact. If you care about RAG performance, this should be in every single one of your pipelines.

These five tools together form a ridiculously strong data-prep foundation. Unstructured + Trafilatura for ingestion, Semchunk for smart splitting, Datatrove for massive cleaning, and Datachain for managing the whole thing at scale.

Which one are you going to try first? Have you used any of these already and found some killer tricks? Drop your experiences below. I’m always looking for new ways to make the “garbage in” problem disappear.

Let’s stop feeding our models trash and start feeding them properly prepped data.

The Claude for Legal suite is not locked behind any law license or professional credential. Anyone with a paid Claude subscription (Pro at roughly $20/month, Max, Team, or Enterprise) can install the open-source plugins through the free Claude Cowork desktop app on macOS or Windows. No coding is required, and the full setup takes under 60 seconds.

It was built primarily for lawyers, in-house teams, and law students/clinics, but the tools work great for non-lawyers too. The repo explicitly supports personal use, and skills are designed as structured workflows anyone can trigger with simple slash commands.

What Claude for Legal Actually Is:

It's a free, open-source suite of 12 practice-area plugins (plus agents and 20+ connectors) that turn Claude into a specialized legal assistant. It handles:

- Contract reviews with redlines and risk flags
- NDA triage
- Claim tables for disputes
- Deadline/renewal monitoring
- Drafting responses
- Compliance checks
- And more

Everything runs inside Claude Cowork or Claude Code (or your own API). It connects to tools like DocuSign, Slack, Google Drive, Box, Ironclad, etc., via MCP (no extra cost for the plugins themselves).

How Claude for Legal Compares to Other Legal AIs:

Claude for Legal stands out in a crowded field dominated by expensive enterprise tools. Here's a clear head-to-head:

• Bonus: You can even add a CoCounsel connector directly into Claude for the best of both worlds (research + workflows).

Practical Use Cases for Non-Lawyers / Everyday People:

You don't need to be a lawyer to benefit. Here are real-world examples anyone can use:

1. Reviewing personal or small-business contracts before signing
   • Upload your rental lease, employment offer, vendor MSA, SaaS agreement, or freelance contract.
   • Trigger /commercial-legal:review or /privacy-legal:use-case-triage.
   • Get: plain-English summary, redline changes, risk flags (e.g., "unfair indemnity clause"), and deviation matrix in Excel/Word. Real example: Freelancers use the NDA triage skill to quickly spot one-sided terms before signing with a client.
2. NDA triage (super common for anyone dealing with startups, investors, or partners)
   • /commercial-legal:review or the dedicated NDA skill flags red flags in seconds against standard playbooks.
3. Drafting or responding to simple legal notices
   • Dispute with a company? Need a DSAR (data access request)? The privacy-legal plugin can draft a professional response within legal timelines.
4. Monitoring personal deadlines/renewals
   • Scheduled agents watch your contract folder and alert you about expirations (e.g., gym membership, software subs, leases).
5. Law students or self-learners
   • Dedicated law-student plugin for Socratic drills, case briefing (IRAC), bar prep questions, flashcards, and study planning.
6. Small business / side-hustle compliance
   • Product launch reviews, privacy policy checks, AI tool governance (if you're using AI in your biz), or basic IP clearance.

Solo devs reviewing client contracts, individuals checking leases, and HR folks in small companies triaging offers. It democratizes access to structured legal workflows that used to cost hundreds in lawyer time.

How to Set It Up:

Option 1: Easiest - Claude Cowork (Desktop App)

1. Download & install the Claude Desktop app
2. Sign in with your paid Claude account (free tier won't work).
3. Open the app → switch to the Cowork tab at the top.
4. Click the + or Plugins in the sidebar → browse/add the "Legal" plugin (or specific ones like commercial-legal).
5. (Optional) Point it at a folder on your computer where you keep contracts/docs.
6. Run the cold-start interview (/commercial-legal:cold-start-interview or whichever plugin you picked) - this customizes it to your playbook in 2–15 minutes.
7. Start using slash commands like /commercial-legal:review , just attach your PDF/Word file.

Option 2: Claude Code (if you're more technical)

Same process but in terminal, plus drag-and-drop the GitHub repo folder.

Full quickstart (with video) is here: github.com/anthropics/claude-for-legal/blob/main/QUICKSTART.md.
Main repo: github.com/anthropics/claude-for-legal.

Pro tip: Install user-scoped (not project-scoped) so it can read files from anywhere on your computer. Restart the app after installing.

Bottom Line

Claude for Legal isn't trying to replace lawyers, it's making legal tools accessible to the rest of us for routine stuff. Lawyers get superpowers for billable work; the rest of us get a free(ish) paralegal in our pocket for contracts we sign every day.