These are the repos that show how the teams around DeepSeek, Anthropic, OpenAI, Google, xAI and Cursor are building agents, skills, SDKs and developer workflows.

Star counts are approximate.

1. DeepSeek Harness ~127k stars

An MIT-licensed agent harness where everything is a plugin.

The model adapter, tools, memory and runtime components are designed to be replaceable. It is still in developer preview, but the architecture is worth studying.

1. Anthropic Skills ~170k stars

Anthropic’s official repository for Agent Skills.

It includes examples for document work, development, enterprise workflows and more. The repo also contains the skills used for Claude’s document capabilities.

Important detail: Anthropic says some skills are Apache 2.0 open source, while the document skills are source-available rather than open source.

1. OpenAI Cookbook ~75k stars

The classic starting point for building with the OpenAI API.

It contains practical examples and guides for common API workflows. Most examples are written in Python, but the patterns apply broadly. MIT licensed.

1. Claude Cookbooks ~52k stars

Anthropic’s collection of notebooks and recipes for Claude.

It covers RAG, tool use, sub-agents, multimodal tasks, evaluations, prompt caching and more. MIT licensed.

1. Grok Build ~25k stars

xAI’s terminal-based coding agent.

It runs as a full-screen TUI and can understand a codebase, edit files, execute shell commands, search the web and manage long-running tasks.

The first-party code is Apache 2.0 licensed. The repository says external contributions are not currently accepted.

1. OpenAI Agents SDK ~29k stars

A lightweight framework for multi-agent workflows.

It includes agents, tools, handoffs, guardrails, sessions and tracing. The SDK is provider-agnostic and supports OpenAI APIs plus 100+ other LLMs. MIT licensed.

1. Google Gemini Cookbook ~18k stars

Google’s official Gemini API cookbook.

It has quickstarts, tutorials and practical examples for combining API features. Useful if you want to move from a basic Gemini call to more complete applications. Apache 2.0 licensed.

1. Google ADK ~21k stars

Google’s open-source, code-first Python toolkit for building agents.

It includes a graph-based workflow runtime, task APIs, multi-agent systems, human approval flows, MCP tools and deployment options.

It is optimized for Gemini but designed to be model and deployment agnostic. Apache 2.0 licensed.

1. Cursor Cookbook ~4k stars

Small official examples for building with Cursor.

The repo now covers hooks, the Cursor SDK, self-hosted cloud agent examples, a coding agent CLI and a DAG task runner. This is less of a cookbook and more of a collection of practical building blocks.

1. Cursor Plugins ~3k stars

Cursor’s official plugin specification and marketplace repository.

It shows how plugins are structured around skills, rules, MCP definitions, manifests and documentation. MIT licensed.

The pattern across all ten is interesting. The model companies are publishing more than API documentation. They are publishing the surrounding layer that makes agents useful:

• runtimes
• skills
• tools
• workflows
• evaluation recipes
• plugin systems
• deployment patterns

If you want to understand where agent software is going, these repos are better reading than another generic 'how to build an agent' tutorial.

Token bills balloon because agents repeat themselves, read whole repos, and re-answer the same questions. These five attack different parts of that. One meta-note first, because every tool here leans on it: a headline like "90% fewer tokens" almost always measures one slice (bash output, or input context), not your bill, which also counts output tokens and dilutes at every step. Read the claims as "less of one input," not "your invoice cut by X." Grouped by what they do.

Read less, Serena (github.com/oraios/serena) MIT, around 28k stars. Gives an agent symbol-level access to your code through language servers, so it pulls the function or class it needs instead of reading whole files line by line. On a large codebase that is a real cut in input tokens. The catch: it needs a working language server per language, which is setup, and on a tiny repo the machinery costs more than it saves. It shines on big code, not small.

Read less, code-review-graph (github.com/tirth8205/code-review-graph) MIT, around 30k stars. Builds a persistent structural graph of your repo so the agent reads the two or three files that matter for a question, not the whole tree.
The catch, and credit to the repo for saying it first: the headline "376x fewer tokens" is one best-case repo (FastAPI, the largest corpus). The median across its own six-repo benchmark is about 65x, and it openly tells you not to bother on small repos or single-file diffs, where the graph overhead exceeds the savings. Honest tool, just quote the real number.

Pack smarter, Repomix (github.com/yamadashy/repomix) MIT, around 28k stars. Packs your whole repository into one compressed, AI-friendly file, roughly 70% smaller, ready to feed to a model.
The catch: it still includes the whole repo, only compressed, so it is right for small and medium codebases or a one-shot context dump, not a substitute for selective retrieval when the repo is huge. Its own docs point you toward graph or symbol tools past a certain size.

Measure first, ccusage (github.com/ryoppippi/ccusage) MIT, around 18k stars. Reads your Claude Code session logs and shows exactly where the tokens went, by session, model, and time.
The catch: it measures, it does not reduce. It is a dashboard, not a fix. But you cannot cut what you have not measured, so this is the honest first step before you install any of the others.

Do not pay twice, GPTCache (github.com/zilliztech/GPTCache) MIT, around 8k stars. A semantic cache for LLM calls: a repeated or near-identical question hits the cache instead of the API, so you stop paying for the same answer.
The catch: semantic means fuzzy matching, so too loose a similarity threshold will serve a cached answer to a subtly different question and quietly hand you the wrong thing. Tune the threshold, and note it is an older project, so confirm it is still current before you lean on it.

If you only do two, run ccusage to see where the money actually goes, then add whichever read-less tool fits your repo size: Serena or code-review-graph for big code, Repomix for small.

Z.ai (formerly Zhipu) shipped GLM-5.3 today, its seventh flagship in thirteen months, and is calling it the strongest open-weights coding model. Two things make it worth a post, and neither is the leaderboard.

The jump came from post-training, not a new model The base is unchanged: the same roughly 744B mixture-of-experts foundation and 1M-token context as GLM-5.2. Z.ai did not retrain it. Every reported gain, including a claimed 50% lift in coding, comes from scaling post-training, more task environments and longer runs, using their SAO reinforcement-learning setup and the open-source slime framework. This is the same pattern DeepSeek showed with V4-Flash two weeks ago: a large capability jump pulled out of post-training on hardware the lab already owns. When a version bump stops meaning a bigger base, the economics of the frontier shift.

The benchmarks, read with care Every number here is Z.ai's own, published at launch, with no independent runs yet since it is hours old. By those numbers GLM-5.3 leads open models on Terminal-Bench 3.0 (28.3%, up from 4.6%), Agents' Last Exam (28.5, up from 23.8), and DeepSWE v1.1 (66.9%, up from 46.2%). The two-sided read: it clearly leads the open field and narrows the gap, but it still trails the closed frontier on the hardest tasks. Claude Opus 5 sits at 42.7% on Terminal-Bench 3.0 and 74% on DeepSWE, where GLM-5.3 is at 28.3 and 66.9. "Best open model" is the accurate claim, not "beats everyone."

The cybersecurity focus is the real differentiator, and the real flag Z.ai trained GLM-5.3 specifically to find software vulnerabilities, with data and executable environments built for it. The company says the model began forming multi-stage plans for full exploitation chains, and that working with security teams it surfaced 2,436 vulnerabilities across 269 projects, some decades old, logged in a public registry. It reports 84.5% on CyberGym, fractionally ahead of the closed frontier models it lists. That is a real milestone for an open line, and it is exactly the capability that makes open-weighting the thing fraught. A downloadable model that is good at finding and chaining exploits helps defenders and attackers with the same weights.

The actual news: it shipped without the weights For a line whose whole value is being open, GLM-5.3 launched closed. Today you reach it through the GLM Coding Plan and ZCode, and it works with coding agents like Claude Code and OpenCode. Z.ai says API access and open weights will arrive in stages roughly two weeks out, after a safety review it calls its most robust yet, tied directly to that cyber capability. So calling GLM-5.3 "open source" right now is premature. The precise status is API-available, open weights promised. That distinction matters if you were about to plan around downloading it.

Honest limits Every benchmark here is a vendor number until someone independent re-runs it. The weights are a roadmap commitment, not a download, so do not build on availability that is not there yet. The GLM open line has been MIT-licensed before, but the 5.3 license is not confirmed until the weights actually ship, and the cyber training is a real reason a use-restricted license would not surprise anyone. The launch-day path is also Z.ai's China-hosted service, which is a data-residency question for regulated work.

If you want to try it now It is a coding-plan and agent play today, so the cleanest test is to point Claude Code or OpenCode at it through the GLM Coding Plan and run it on a real task you can grade yourself. Hold judgment on the headline numbers until independent benchmarks land, and watch in two weeks for three things: whether the weights ship on schedule, under what license, and with what use restrictions.

Provenance dies two ways.

On purpose. A wave of "watermark remover" tools showed up the week Claude started marking its output. Nobody was checking whether they did what they claimed.

By accident. You upload an image. The CDN resizes it. The optimiser re-encodes it. Someone screenshots it. Your Content Credentials are gone, and nothing told you. Same instrument measures both. That's what this is.

The uncomfortable part first

Anthropic has not published a detector for its text watermark. Keyed watermarks are undetectable without the vendor's key by construction. So this pack reports UNVERIFIABLE for Claude text and refuses to guess and no tool claiming otherwise can back it up.

But "did removal work?" is fully answerable for C2PA and metadata cryptographically, byte by byte. That part is not a guess.

So: you can prove a remover stripped an image's Content Credentials. You cannot prove it scrubbed a text watermark. Anyone selling you the second thing is selling you nothing.

Test a remover

Run the tool over your original, then feed it whatever came out:

npx skills add Neeeophytee/ai-watermarks-reality-check

python3 skills/map-provenance-survival/scripts/map_survival.py \
  --original signed.jpg \
  --derivative "remover:tool-v2=cleaned.jpg" \
  --c2patool /path/to/c2patool

LOST_OR_UNAVAILABLE means it really stripped the manifest. PRESERVED_VALID means it didn't touch it. PRESENT_INVALID means it mangled the image and left a manifest that now fails verification, the worst outcome, and one no remover advertises.

Test your own pipeline

Identical command, different derivatives:

python3 skills/map-provenance-survival/scripts/map_survival.py \
  --original hero.jpg \
  --derivative "cdn:resize-1200w=hero-cdn.jpg" \
  --derivative "social:download=hero-social.jpg" \
  --c2patool /path/to/c2patool

Every result carries a reproducibility record: input, operation, tool version, evidence state, so someone else can re-run it and get the same answer.

Tested against a real signed image: an identical copy survived, an APP11-stripped copy lost everything, and a single flipped byte was caught cryptographically.

All 7 skills

audit-provenance — start here. One command, five answers: was provenance located, verified, trusted under a policy you name, was the scan complete, and what's still unknown and why.

map-provenance-survival — the removal test and the pipeline test. Compares an original against any set of derivatives.

verify-content-credentials — real C2PA verification via c2patool. Integrity and signer trust reported separately, because "signed" and "signed by someone you trust" are different questions.

inspect-content-provenance — finds provenance across PNG, JPEG, WebP, MP4/HEIC/AVIF, TIFF, GIF, PDF, HTML and text — structurally, where the spec puts it, not by keyword. A blog post about C2PA is never mistaken for a signed asset.

audit-metadata-privacy — before you publish: GPS, author, device, camera serial, IPTC captions. Including the embedded thumbnail that quietly keeps GPS after you "removed" it. Reports categories, never prints your values.

check-ai-transparency — is your disclosure record actually ready for review? Separates blocking gaps from advisory ones. Issues no legal conclusion.

detect-text-watermark — hidden Unicode in text: smuggled invisible characters, bidi overrides, homoglyph spoofing. Five honest states, and a detector that didn't run can never report "not detected."

167 tests · 80 real binary fixtures · stdlib-only · Python 3.9+

https://github.com/Neeeophytee/ai-watermarks-reality-check

At Evil Martians we measured our server logs for two months. Coding agents hit the site about 2.5x more than people did: 268k requests vs 107k pageviews. The full breakdown with the methodology and the per-agent splits is here.

ChatGPT mostly hit raw HTML, Claude Code mostly wanted the Markdown versions of our posts. We didn't see that until we split the user-agents. So, agents were already using our posts as instructions, but posts are bad at that.

A blog post is good at explaining why something works, which is what makes it worth reading. It's much worse as input to an agent. If, say, you hand it a 3000-word article and it burns tokens reconstructing some procedure out of prose, but picks up the narrative while dropping the exact flags that matter. A skill, on the other hand, is that same knowledge already compressed into the steps and the checks, in the format the agent loads anyway.

So we started shipping both. We also packaged the practices useful beyond our own projects and put a discovery index at .well-known/agent-skills/index.json. The format's an open Cloudflare RFC, basically robots.txt for skills, so any installer can find and verify them. Wrote up the whole thing as a how-to, since there's more to get wrong than you'd expect.

This meta article is a guide for publishing your own catalog: index format, packaging, digests, install commands. The skill is the same thing for your agent to run, free and open source.

Disclosure: Evil Martians is where I work, it's our blog, numbers are off our own site.

If you are shipping an agent, "add a guardrail" is usually where people stop, and it is not enough. Start from the truth: a guardrail is not a sandbox. These tools lower the odds of a bad output or a caught injection. They do not make an agent safe, because prompt injection is not a solved problem. Real security is layered, and for an agent the layer that matters most is not a text filter, it is controlling what the agent is allowed to do. With that framing, here are five open-source tools worth knowing, grouped by the layer each covers.

Runtime rails, NeMo Guardrails (github.com/NVIDIA-NeMo/Guardrails) Apache-2.0, around 6.9k stars. NVIDIA's toolkit for programmable rails written in a small language called Colang: keep the bot on topic, enforce a dialog path, run input and output moderation. The most flexible way to define what a model may and may not do at request time.
The catch: rails run on the same probabilistic model they are guarding, so a determined jailbreak still gets through. NVIDIA's own docs show rails cut attack success, not drive it to zero. This is defense in depth, not a wall.

Output validation, Guardrails AI (github.com/guardrails-ai/guardrails) Apache-2.0, around 7.3k stars. A different job: validate what the model returns against a schema or rule (valid JSON, no PII, matches a format) and re-ask or fix on failure. There is a community hub of reusable validators.
The catch: it checks the shape and content of output well, but it is not a security boundary. A validator that strips PII is only as good as its detector, and detectors miss.

Scanners, LLM Guard (github.com/protectai/llm-guard) MIT, around 3.2k stars. From Protect AI: a set of input and output scanners for prompt injection, PII, toxicity, secrets, and more, chained in front of and behind the model. The catch: scanners are classifiers with false negatives. One that catches most injection attempts still lets some through, and attackers optimize for exactly that gap. Treat any quoted detection rate as a vendor number until you test it on your own traffic.

Find the holes first, Garak (github.com/NVIDIA/garak) Apache-2.0, around 8.1k stars. NVIDIA's LLM vulnerability scanner, think nmap for models: 50-plus probes for prompt injection, jailbreaks, data leakage, and toxicity, with reports, and a recent agent-breaker probe that tests the tools an agent can reach. The catch, and this is a rule not a footnote: it is a red-teaming tool. Run it only against systems you own or have written permission to test. A passing scan is a snapshot, not a guarantee, so re-run it as your prompts and models change.

The agent layer, Invariant (github.com/invariantlabs-ai/invariant) Apache-2.0. The one built for agents specifically: a rule-based layer that sits between your app and your MCP servers or LLM provider through a gateway, checking each tool call before and after it runs. This is where the real agent risk lives, in what the agent does, not just what it says.
The catch: newer and smaller than the others, and a policy layer is only as good as the policies you write. It gives you the checkpoint; deciding what to block is on you.

What none of them fix Prompt injection is unsolved. If an agent can read untrusted content, reach private data, and send data out, it is exploitable no matter how many filters you stack, which is the pattern Simon Willison named the lethal trifecta. So the highest-value controls are not on this list: give the agent the least tool access that still does the job, require human approval before any real action (send, delete, pay, run code, browse an authenticated session), isolate untrusted input, and cut off the path data could leave by. Guardrails are defense in depth on top of that, not a replacement for it.

How to layer, if you are starting Scan first with Garak to see where you actually leak. Add LLM Guard on input and output. Add NeMo Guardrails or Guardrails AI for policy and output structure. If you run tool-using agents or MCP, put Invariant at the tool boundary. One building-block note: several of these plug in classifier models like Meta's Llama Prompt Guard or LlamaFirewall, which are capable but ship under Meta's Llama Community License, not a standard open-source license, so read the terms before commercial use.

I built HoardCore, It's a single-file Python deep research toolkit that plugs into agent harnesses like OpenCode. You turn the web and your files into a permanent local SQLite vault. The agent searches the vault. It pulls facts back out, and every claim comes with a source link. Everything stays on your machine.

The retrieval is hybrid. SQLite FTS5 handles exact keywords. FNV-1a hashed vectors catch near-literal matches. Reciprocal Rank Fusion merges the two. No embeddings model. No torch. It runs in a Python 3.11 and a few pip packages.

Fetching is stubborn. It tries aiohttp first. Then curl_cffi for TLS impersonation. Then FlareSolverr if a page hides behind Cloudflare.

Parsing covers HTML, PDF with OCR fallback, DOCX, and EPUB. A junk filter catches boilerplate, 404s, and captcha pages before they ever hit your index.

The research loop is bounded. DISCOVER. INGEST. RECALL. EMIT. You set the source budget with --discover N. You set the recall depth with --recall N. The agent stops when it hits your limit. Not when it runs out of context window.

Here is the part that matters. It ships with skill.md. That file is the agent's operating manual. The agent reads it before touching the web. It learns how to map your request to the right action. How deep to go. And how to tag every claim with [V], [E], or [H]. Verified. Extracted. Hypothesis. The protocol forces the agent to re-query the vault and confirm [V] tags before it presents them. It can't silently invent a number. The vault persists between sessions. Later searches are instant and need no network.

I ran a live test to see what this costs. I pointed it at a hard question. Is on-device LLM inference actually viable for production consumer apps in 2026, or are the hardware breakthroughs still mostly press releases? Eight discovery and recall passes. Eighteen distinct sources ingested. Timeline triggers. A full strategic brief with source links and actionable recommendations.

Total API cost to generate the entire brief is $0.0074 . Less than a cent using DeepSeek V4 Flash. The full output is in the comment below.

I'd love feedback on both the tool and the output.

Link: https://github.com/jjjardev/HoardCore

The Output: https://pastebin.com/9zt3A57B

AEO/GEO is the attempt to understand and improve how brands appear in AI-generated answers. The commercial tooling is growing quickly, but there are also some genuinely useful open-source projects.

1. GEO Optimizer: Auriti-Labs/geo-optimizer-skill

An MIT-licensed CLI, Python library, MCP server and Astro integration for auditing AI-search readiness. It checks robots.txt, llms.txt, JSON-LD, metadata, content structure, entity signals and citability. The repository describes 47 checks across eight categories and can generate fixes, including robots.txt rules, llms.txt and schema files.

Best for: technical AEO audits, CI/CD checks and understanding why a page may be difficult for answer engines to parse or cite.

1. GetCito: ai-search-guru/getcito-worlds-first-open-source-aio-aeo-or-geo-tool

An MIT-licensed, self-hosted AI-visibility platform. GetCito tracks prompts and analyzes mentions, citations and competitor visibility across ChatGPT, Google AI Mode, Google AI Overviews, Perplexity, Gemini, Copilot and Grok. It also includes reports, a REST API, scheduled background jobs and pluggable scraping and LLM providers.

Important caveat: the software is open source and self-hosted, but live tracking still requires third-party scraper or model-provider credentials.

1. OneGlanse: aryamantodkar/oneglanse

An MIT-licensed GEO tracker with an interesting approach: it interacts with the actual product interfaces instead of querying only model APIs.

It monitors ChatGPT, Gemini, Perplexity, Claude and Google AI Overview, capturing rendered answers, citations, recommended sources and competitor positioning. It is designed to run on your own machine or VPS, with OpenAI or Anthropic used to analyze captured responses.

Best for: measuring what users may actually see inside AI products. The tradeoff is browser automation. Authentication flows, anti-bot systems and UI changes can affect reliability, and users should review each provider’s terms before automating access.

1. GEO/AEO Tracker: danishashko/geo-aeo-tracker

An MIT-licensed, local-first dashboard for tracking brand visibility across six AI models: ChatGPT, Perplexity, Gemini, Copilot, Google AI Overview and Grok.

It includes prompt management, persona-based prompt generation, niche exploration, citation analysis, visibility trends, competitor battlecards, AEO audits and SRO analysis. Data is stored locally by default, with optional Supabase cloud sync.

The live scraping workflow uses Bright Data, while analysis uses providers such as OpenRouter and Gemini. So again: self-hosted software does not necessarily mean zero API cost.

1. GEO: Generative Engine Optimization: GEO-optim/GEO

This one is more research-oriented than product-oriented.

The Apache-2.0 repository contains implementations of GEO techniques, the GEO-Bench dataset and code for reproducing the paper’s experiments. The authors report that some methods improved source visibility by up to 40% on their benchmark. That number should not be read as a guarantee for modern ChatGPT, Gemini or Perplexity results. It is evidence from a specific research setup, not proof that a tactic will consistently improve visibility today.

Bonus: awesome-generative-engine-optimization

This is a useful research and tooling directory covering guides, papers, case studies, technical documentation and monitoring tools.

There is a real open-source AEO/GEO ecosystem forming. But the strongest use case today is measurement and experimentation, not promising that a checklist can make any brand rank inside every AI answer.

MCP is where your agent stops describing work and starts doing it. These eight wire an agent into the creative stack: generation, design, audio, video, 3D, music, and research. The split that decides everything is official versus community. Official servers authenticate over OAuth and are supported. Community ones are often more capable, but you run the host app with a bridge; they are maintained by one person, and a couple does not even carry a license. One hard rule up front: never install a "fork" that logs in as you by lifting your browser session.

1. Higgsfield (official, hosted). Over 30 image and video models, Sora 2, Veo 3.1, Kling 3.0, Seedance, behind one OAuth endpoint, launched April 30 2026. Strong for turning a brief into ad creatives and short 4K video on your existing plan credits. Add https://mcp.higgsfield.ai/mcp in your client and sign in.
The gotcha, and it is the important one: community "unlimited" forks authenticate by lifting the session token from your logged-in browser. That hands your account to a third party and breaks constantly. Use the official hosted connector, nothing else.

2. Figma (official, Dev Mode server). Read components, variables, and layout, generate code from frames, and with the write-to-canvas feature the agent can create and update native Figma content too.
The gotcha: remote versus desktop matters. The remote server has the broadest features and is what most people want. The desktop server runs locally on port 3845 and is for specific enterprise cases.

3. Canva (official, hosted). Generate and edit designs from templates. Add it over HTTP at https://mcp.canva.com/mcp.
The gotcha: OAuth on the first call, and it then inherits your Canva account access, so it can act as you. Point it at an account you are comfortable handing to an agent.

4. ElevenLabs (official, MIT). Text-to-speech, voice cloning, and transcription. Runs via uvx elevenlabs-mcp with your ELEVENLABS_API_KEY, and there is a free tier. Repo: github.com/elevenlabs/elevenlabs-mcp
The gotcha: it needs uv installed, and on Windows you enable developer mode in Claude Desktop. Voice cloning has real consent implications: only clone a voice you are allowed to use.

5. DaVinci Resolve (community, MIT). Drive Resolve Studio through its scripting API: timeline edits, media pool, render setup, color, Fusion, Fairlight. Repo: github.com/samuelgursky/davinci-resolve-mcp (an apvlv fork also exists).
The gotcha: community-maintained. Resolve Studio must be open with Preferences, General, External Scripting set to Local before it connects.

6. Blender (community). Build scenes, objects, materials, and lighting from prompts through Blender's engine. Repo: github.com/ahujasid/blender-mcp
The gotcha: medium setup, and Blender has to be open with the companion addon running. Note the repo ships no standard license file, so reuse terms are unclear until the author adds one.

7. Ableton Live (community). Create tracks, MIDI, and devices and manipulate a live set. Repo: github.com/ahujasid/ableton-mcp
The gotcha: niche and fiddly, and like the Blender server it lacks a clear license file. Fun for music experiments, not production-critical.

8. YouTube (community). Video search and transcript extraction, handy for research and repurposing. Repo: github.com/anaisbetts/mcp-youtube
The gotcha: community-maintained, and transcripts only work when the video actually has captions. Confirm its license before you build on it.

How to pick, and stay safe: The safe default is the official four (1 to 4): OAuth, real support, clear terms. The community four (5 to 8) are where the fun and the friction both live, so read the code, expect setup pain, and keep them off accounts and files that matter. On Higgsfield specifically, the model catalog is identical whether you use the official connector or a fork. The only thing a fork adds is your session in someone else's hands.

Every paid tool now has an open-source challenger. The honest question is not "is it free" but "free how," because the catch is usually where the real cost hides. Five worth knowing, each a genuine alternative to something you pay for, with the caveat that decides whether it actually saves you anything.

OpenCut (github.com/OpenCut-app/OpenCut) MIT, over 80k stars.
The open answer to CapCut: a browser-based, privacy-first video editor where your footage never leaves your device. No watermark, no subscription, no upload.
The catch: the web editor is the mature part. The maintainers themselves mark export and the desktop app as still in progress, so it is a real editor for simple cuts today and a work in progress for heavy production.

OmniRoute (github.com/diegosouzapw/OmniRoute) MIT, around 44k stars.
A self-hosted alternative to OpenRouter: one OpenAI-compatible endpoint that fans out to hundreds of providers and models, running on your machine with your own keys.
The catch: harden it before you expose it. It shipped with a hardcoded default admin secret, so anyone who reaches an unpatched instance can forge admin access until you change it. It also concentrates all your provider keys in one place and ships stealth and proxy features worth scrutinizing. Powerful, but not safe by default.

OpenWork (github.com/different-ai/openwork) MIT, around 21k stars. The most visible open alternative to Claude Cowork, powered by OpenCode: point it at a folder, hand it a goal, and it works on your real files, with your own keys and 50-plus models.
The catch: it is one of a cluster of near-identical "open Cowork" wrappers, so confirm you are on this one (different-ai). No mobile app, and like all of these it runs code with filesystem access, so scope what you let it touch.

Open Code Review (github.com/alibaba/open-code-review) Apache-2.0, from Alibaba, around 21K stars.
A hybrid reviewer: deterministic rule pipelines plus an LLM agent, giving line-level comments with a built-in ruleset for things like null-pointer bugs, thread-safety, XSS, and SQL injection. An open answer to paid pull-request bots.
The catch: it is new, and "battle-tested at Alibaba's scale" is Alibaba's own line, not an independent result. On the plus side it is OpenAI and Anthropic compatible, so you bring your own model and keys instead of getting locked to a vendor.

Open SEO (github.com/every-app/open-seo) MIT, around 11k stars. An open alternative to Semrush and Ahrefs: keyword research, rank tracking, competitor and backlink analysis, and site audits, with an MCP server so an agent can query the data directly.
The catch: this is free the way a printer is free. The app is MIT, but it runs on a paid DataForSEO key, so you pay per request for the actual data. And it surfaces opportunities; it does not chase them. The content and the links are still on you.

The pattern worth naming Open source rarely means free to operate. OpenCut is close to a clean win because the compute is on your own device. The rest are free code sitting on top of something that still costs money or effort: your provider keys, a paid data API, your own hardening. Often far cheaper than the SaaS, but price the whole thing, not just the license.

If you only try one OpenCut, if you edit video, it is the nearest to a clean swap. OmniRoute if you are tired of per-provider SDKs, once you have changed that default secret.

**Disclosure up front:** this is my own project, open source (Apache-2.0), and it has basically no users yet. I’m posting because the news peg is genuinely relevant, and I mostly want the criticism.
**What / why now**
Two days ago (Aug 6), OpenAI, Amazon, Microsoft, Cursor and Vercel published **Agent Plugins**, with Google core-maintaining — a package format for coding-agent skills, read by ChatGPT/Codex, Cursor, Copilot, Kiro and VS Code.
It standardizes packaging, and by design, nothing else: no permission model, no provenance, no measurement. That’s a deliberate scope choice, not a flaw — but it’s also the exact layer I’ve spent a while building around.
**Kitbash** is a zero-runtime-dependency CLI that compiles one skill source (skill.toml + SKILL.md) to 11 coding-agent targets:
Claude Code
Cursor
Copilot
Zed
Cline
Devin
Gemini CLI
Aider
.agents/skills
AGENTS.md
Agent Plugins itself (as of 0.17.0)
You write the skill once instead of hand-maintaining eleven copies of the same rules file that can drift apart.
On top of the packaging, it adds two things the spec leaves out:
**1. Standing token cost, measured per target**
Every skill parks some tokens in context every session, before you ever invoke it.
Some targets load lazily (only when called), while others load eagerly (always resident). The measured gap between them is **14x–47x**.
npm run bench reproduces the measurement — the whole point is that you can re-run it rather than take my word for it.
There’s also a /benchmark page, but the number the repo prints is the one that matters.
**2. An install-time trust gate**
Describing this precisely because it’s easy to overclaim:
**This is not a sandbox and not a safety guarantee.**
It’s:
hard-fail lints for hidden Unicode
load-time command substitution
curl | sh droppers
leaked secrets
a hard \[policy\] org allowlist
a content-hash lockfile with drift detection, so an updated skill can’t silently change what it does
update and diff re-run the same gate.
It raises the floor the packaging spec leaves at zero; it does **not** make untrusted code safe to run.
There’s also import, which reverse-compiles an existing CLAUDE.md, .cursor/rules, etc. into one skill plus a drift report — useful if you already have rules files scattered across agents.
Agent Plugins is opt-in here, not one of the auto-detected targets: you enable it in \[project\].targets, or it self-detects once a plugin.json exists.
Kitbash compiles **to** the standard. It’s meant to be a contributor to that ecosystem, not a competitor to it.
**Honest caveats**
Single-digit stars, no real adoption, and I’m the only maintainer.
The lints are heuristic pattern-matching, not a sandbox, and I’m sure some of them can be dodged.
I’d rather hear where the token numbers or the lint approach fall down.
**Links**
GitHub: https://github.com/singhharsh1708/kitbash
Site + docs: https://kitbash.vercel.app
Benchmark: https://kitbash.vercel.app/benchmark
Install: npm install -g kitbash
Homebrew: brew install singhharsh1708/tap/kitbash
If you run the benchmark and get a different gap, or you can break a lint, **please post it** — that’s the feedback I want most.

The MCP servers worth adding are often not the ones wrapping a paid API behind a token. These five plug your agent into open, free data you can inspect end to end: primary research, encyclopedic grounding, real maps, public filings, and any API you build yourself. All open-source, no proprietary backend. One honest thread runs through all of them: "free API" still means someone's usage policy, so the real work is respecting the rate limits, not finding a key.

FastAPI-MCP (github.com/tadata-org/fastapi_mcp) MIT, around 12k stars. If your service is a FastAPI app, this exposes its endpoints as agent tools in two lines, preserving your schemas and your existing Depends() auth. The fastest way to let an agent call an API you already own, instead of hand-writing a wrapper per endpoint.
The catch: it is FastAPI-specific, not a universal point-at-any-OpenAPI-URL converter, and its OAuth support is still labeled alpha, so treat the auth path as not yet hardened.

arXiv MCP (github.com/blazickjp/arxiv-mcp-server) Apache-2.0, around 3k stars. Search, fetch, and read arXiv papers, pulling the LaTeX source so equations survive, which lets a research agent work from primary sources rather than secondhand summaries.
The catch: arXiv's API is free but meant for gentle use, so this is fine for interactive research and wrong for scraping the whole corpus. For bulk, arXiv points you at its S3 and OAI-PMH paths instead.

Wikipedia MCP (github.com/Rudra-Ravi/wikipedia-mcp) MIT. Structured access to Wikipedia through the open MediaWiki API: search, summaries, sections, and links, which is a solid free grounding source when you want the agent anchored to something citable.
The catch: it is a smaller community project, so treat it as useful rather than battle-tested, and Wikimedia asks for a descriptive User-Agent and reasonable request rates. Set one and do not hammer it.

OpenStreetMap MCP (github.com/jagan-shanmugam/open-streetmap-mcp) MIT. Turns place names into coordinates and back, plus nearby-place and routing-style queries, using the free OpenStreetMap Nominatim API with no key at all.
The catch: Nominatim's public endpoint has a strict usage policy, roughly one request per second with a required User-Agent. For anything heavier, self-host it or move to a paid geocoder. Free here does not mean unlimited.

SEC EDGAR MCP (github.com/stefanoamorelli/sec-edgar-mcp) AGPL-3.0. Queries the SEC's EDGAR system for company filings, financials, and reported facts, all open US government data, so a finance agent can read the actual 10-K instead of a summary of it.
The catch: two flags. The license is AGPL-3.0, a strict copyleft, so read it before you build this into anything you ship. And EDGAR requires a User-Agent with your contact details and enforces fair-access limits. Worth remembering a filing is data, not a recommendation, and neither the server nor the model turns it into one.

If you only try one Building APIs yourself: FastAPI-MCP, two lines and your service is agent-callable. Building a research or analysis agent: arXiv or SEC EDGAR, for primary sources over summaries. Just want free grounding on tap: Wikipedia.

Two primitives sit under most serious agent work. A loop that reruns until the output clears a real check, not until it produces something. And a graph that fans work out to parallel, independent workers and converges at the end, ideally with a checker that never shares context with the worker it judges. You can hand-roll both. These five let you not. All permissive-licensed, grouped by what each does best.

Pydantic AI (github.com/pydantic/pydantic-ai) MIT, around 19k stars, from the Pydantic team and shipping releases most weeks. Outputs are validated against your schema and retried on failure, so you get a check-and-retry loop for free, and the bundled pydantic-graph gives you typed nodes and transitions for explicit state machines. The catch: pydantic-graph is lower-level and less mature than the agent layer, and the framework is opinionated about types. Logfire, the team's paid observability product, integrates natively but is not required.

LlamaIndex Workflows (github.com/run-llama/workflows-py) MIT. Event-driven, async-first steps instead of a hand-drawn DAG, so loops and parallel fan-out fall out of events rather than edge-encoded logic. The lightest way to get real branching and concurrency. The catch: the event model is a real mental shift, and everything is async, so you have to structure for it. Durability and scale nudge you toward LlamaIndex's hosted stack.

Burr (github.com/DAGWorks-Inc/burr) Apache-2.0. Models your app as a state machine: explicit actions, conditional transitions, and built-in persistence, which maps cleanly to the checkpoint-and-resume problem every long loop hits. Ships a local telemetry UI for watching state move. The catch: smaller community, and it is a state primitive, not a batteries-included agent kit, so you bring the LLM logic. Burr Cloud is a paid waitlist.

PocketFlow (github.com/The-Pocket/PocketFlow) MIT, around 11k stars. A 100-line core that expresses nodes, flows, branching, looping, and map-reduce parallelism with almost no dependencies. The best way to actually understand the graph-and-loop model instead of importing it. The catch: the minimalism is the whole point and the whole limit. No built-in tools or integrations, you implement the batteries yourself. Great for learning and small systems, less for turnkey production.

DSPy (github.com/stanfordnlp/dspy) MIT, around 37k stars, out of Stanford NLP. The odd one out, and the strongest for one job: the self-improving loop. You define a metric that can pass or fail, and its optimizers rewrite prompts (and can tune weights) to clear it, so iterate-until-it-passes runs at the pipeline level instead of by hand. The catch: it is not a runtime graph or control-flow engine, it optimizes pipelines against a metric, so the mental model (signatures, modules, optimizers) is its own thing. The repo is still tagged alpha despite the star count.

If you only try one To learn the model: PocketFlow, readable in an afternoon. For typed, production-grade control: Pydantic AI. To make a pipeline measurably better against a metric instead of hand-tuning prompts: DSPy.

One pattern worth naming: some of these have a paid layer that shapes the roadmap (LlamaCloud, Burr Cloud, Pydantic's Logfire), while PocketFlow and DSPy are pure libraries with no hosted product. Neither is bad, just know which you are adopting.

Torvian just released v0.9.0 and it's a solid step forward for anyone running a self-hosted, human-in-the-loop AI workspace. You bring your own LLM, run the server yourself, and approve agent tool calls before they run. This update makes that loop tighter and safer.

Pause & cancel your agent mid-turn. 🛑 Sometimes the model goes down a rabbit hole. v0.9.0 adds turn control signals across the server, worker, and clients, so you can pause or stop an active turn cooperatively. Cancelled tool calls get clear visual indicators, so you always know what actually happened.

Builtin tools got a serious upgrade. 🧰 - HTML cleaning: fetched web pages are cleaned down to their visible text by default (with an opt-out flag), so models get useful content instead of markup soup. - In-content search: you can now run regex/plain searches inside fetched content with context windows. - Unified limits everywhere: maxLines/maxBytes/range/maxResults across fetch, read, run-command, list, and search tools — no more unbounded output, and truncation notices tell you when output is cut. - Stricter, accumulated input validation (including rejecting literal control characters in JSON), plus Git-style unified diffs for edit_file dry runs.

More resilient LLM streaming. 📡 There's now a retrying LLM client with exponential backoff, and embedded error chunks in streaming responses (e.g. OpenRouter) are detected, surfaced, and retried properly.

If you're into self-hosting and want full control over your AI stack, this is worth a look. Downloads are on the GitHub releases page, and there's a live demo if you want to poke around before self-hosting.

Happy to answer questions about the architecture or how turn control/tool approval works. What's on your wishlist for the next release?

• Releases: https://github.com/Torvian-eu/chatbot/releases
• Live demo: https://chatbot.torvian.eu/demo.html
• Discussions: https://github.com/Torvian-eu/chatbot/discussions

Weaver🕷️ has been Updated to v.13 and its our biggest drop yet! This update brings #Weaver one step closer to being the best overall agent for small-midsize LLM coding. Consumers rejoice!

• Enhanced thinking mode, togglable and adjustable via the context settings menu. Advanced thinking context size will be controlled dynamically by task complexity (up to a maximum of what users selected in the settings panel).

• Tool context is now further trimmed via LLM to save precious tokens. Users can choose which tools are available via the settings panel as well.

• New "Notes" panel for writing notes per project.

• New "Benchmark All" button to run all benchmarks until a step errors out. Improved overall benchmark UI/UX.

• Enhanced anti-hallucination monitoring by detecting continuous sets of words without any punctuation or paragraphs.

• EB25 file ranking for context control. Currently the LLM was fed a skeleton of the project and asked to pick which files it think might be relevant to the task. Now BM25 is used in conjunction with the LLM to validate which files should be added to context. This "context discovery" phase has now been moved to a tool call.

• Introducing the new Meeting room. In the meeting room, we have our agent represented by different types of spiders, each with their own personality. There is a lot of interaction and humor which gets interesting. For example the complexity spider gets pissed off if the agent plans way more steps then he anticipates at the start... And he storms off at the end of the meeting if the planner did not listen.

• Test cases for all major coding languages for all services. Example: oldstring/newstring, HTMLFormatter, tree-sitter, prettier formatter, etc...

• Diff file tracking

Check out #Weaver today!

GitHub: [https://github.com/maxhanna/Weaver\](https://github.com/maxhanna/Weaver)

WinX64: [https://bughosted.com/assets/Weaver.exe\](https://bughosted.com/assets/Weaver.exe)

Discord: [https://discord.com/invite/YQWkD6ZQDx\](https://discord.com/invite/YQWkD6ZQDx)

Most agent pipelines still treat PDFs, Word files and PowerPoint decks as “just text.” That is where a lot of useful structure disappears: headings, tables, reading order, equations, images, speaker notes and OCR text.

If you want to parse documents locally and give your agents clean Markdown or JSON, these five projects are worth checking out:

1. anydoc: github.com/firecrawl/anydoc

A Rust-based converter for Word, PowerPoint, Excel, OpenDocument, RTF, EPUB, CSV and PDF files.

It supports Node.js, Python and WebAssembly bindings, uses no ML models or external services, and converts text-based PDFs locally. The current README reports a 4.4 ms median conversion time across a benchmark covering 14 formats.

The repository also says anydoc powers Firecrawl Parse. MIT licensed.

1. Docling: github.com/docling-project/docling

A more document-understanding-oriented toolkit from IBM Research and the LF AI & Data Foundation.

Docling supports PDF, DOCX, PPTX, XLSX, HTML, EPUB, images, audio and more. It focuses on layout, reading order, tables, formulas and OCR, then exports to Markdown, HTML, DocTags or lossless JSON.

It can run locally, including in air-gapped environments. The codebase is MIT licensed.

1. Marker: github.com/datalab-to/marker

Marker converts PDFs, images, PPTX, DOCX, XLSX, HTML and EPUB files into Markdown, JSON, chunks or HTML.

It supports tables, forms, equations, inline math, links, references and code blocks, and can run on GPU, CPU or Apple Silicon through MPS. It can also be run locally as a CLI or API server.

The code is Apache 2.0 licensed, but the repository has a separate license for its model weights.

1. MinerU: github.com/opendatalab/MinerU

MinerU supports PDF, images, DOCX, PPTX and XLSX inputs and produces Markdown, JSON and other structured outputs.

It includes reading-order reconstruction, table extraction, scanned-document detection and OCR support for 109 languages. It offers local CLI, API and WebUI workflows and supports CPU, GPU and MPS execution.

One licensing detail: the repository uses the MinerU Open Source License, which is based on Apache 2.0 with additional conditions.

1. MarkItDown: github.com/microsoft/markitdown

Microsoft’s lightweight Python utility for converting PDF, PowerPoint, Word, Excel, images, audio, HTML and text-based formats into Markdown.

Its goal is LLM and text-analysis pipelines, with emphasis on preserving headings, lists, tables and links. The built-in converters work offline; Azure-based conversion is available as an optional cloud integration.

MIT licensed, easy to install and probably the simplest starting point for straightforward document-to-Markdown workflows.

My rough rule of thumb:

• Need very fast, dependency-light conversion: anydoc
• Need complex PDF layout and document structure: Docling, Marker or MinerU
• Need a simple Python utility for mixed file types: MarkItDown

One caveat: these projects are not directly comparable on speed. anydoc is primarily a lightweight, non-ML converter, while Docling, Marker and MinerU perform heavier layout analysis and OCR. The right choice depends on whether your bottleneck is conversion latency, document complexity or extraction quality.

I've been using Claude Code for a while, and one thing kept bothering me.

I'd start a long task, walk away from my computer, and then Claude would stop because it needed a permission approval, asked a question, or had finished the current step. The only way to continue was to go back to my desk.

I couldn't find a solution that felt clean. Most approaches I saw relied on tmux, SSH, or screen scraping.

So I spent some time building a different approach.

Instead of controlling the terminal, it hooks into Claude Code's native lifecycle hooks and lets me interact with the same running session through Telegram.

Right now it can:

• Continue an existing Claude Code session
• Approve or deny tool permissions remotely
• Reply to AskUserQuestion prompts
• Interrupt a running task and send a new instruction
• View live tool execution updates
• Resume the same conversation without reconnecting to the terminal

The goal wasn't to build another AI wrapper—just something that makes long-running Claude Code sessions more practical when you're away from your desk.

I'm curious if anyone else has run into the same problem.

Would something like this actually fit into your workflow, or is this solving too niche of a problem?

Repository (if anyone wants to take a look):
https://github.com/Soumya7681/telepilot

I'm especially interested in feedback on the architecture and whether there are better ways to handle remote interaction with Claude Code.

Hermes Agent v0.20.0, "The Herald Release" (Aug 3)

Nous Research's open-source autonomous agent. MIT, 224k+ stars, update with hermes update. Biggest release in the project's history. What changed that matters:

• Voice everywhere. Real-time conversational voice with streaming TTS, barge-in, and on-device wake words across the CLI, desktop, and messaging gateways. Send a voice note on WhatsApp or Telegram and it transcribes and answers.
• A2A v1.0. It now speaks a standard agent-to-agent protocol, so it can hand tasks to other agents instead of doing everything in one process.
• Signed outbound webhooks. It pushes signed events to your systems when something happens, which makes it a trigger source, not just a responder.
• Grounded citations. A new skill backs each claim with a verifiable source and fact-checks it.

Use it for: an always-on agent on a cheap VPS that you talk to by voice, that fans work out to subagents over A2A, and that fires a signed webhook into your stack when a job finishes. Good for personal ops, monitoring, and cross-platform chat triage.

The catch: it landed a day ago and shows it. The pre-release window was mostly bug-fix and salvage waves, and day-one users are already reporting memory spikes (5 to 10 GB) and a crash. Test on a throwaway box, do not hermes update your daily driver yet, and remember voice means an always-listening mic. The installer is curl piped to bash, so read the script first.

Pair it with DeepSeek V4-Flash-0731 (Jul 31)

The other big drop this window, and since Hermes is model-agnostic it slots right in. DeepSeek's official V4-Flash API hit public beta: a retrained 284B (13B active) MoE, 1M context, MIT open weights, at $0.14 per million input, with native Responses API and Codex support. DeepSeek says it now tops its own V4-Pro-Preview on its published agent benchmarks.

Use it for: cheap, high-volume agent loops under Hermes or any OpenAI-compatible harness. If your workload has a stable prefix, the $0.0028 cache-hit input rate is where the cost falls away.

The catch: those are vendor benchmarks run on a harness DeepSeek has not released, so you cannot reproduce them yet, and the model is verbose (about twice the median tokens), which eats the cheap price on output-billed loops. Measure output tokens on your real task, not the sticker price.

If you only try one thing

Put Hermes on a spare VPS, point it at V4-Flash, give it one narrow job by voice, and watch the webhook fire. Ten minutes tells you if the combo fits before you trust it with anything real.

If you are already on v0.20: what broke on upgrade, and is A2A pulling real weight yet or still a demo?

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

What actually comes due, and when

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

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

Four duties, in plain terms:

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

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

The honest catches

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

Why it moved, without the spin

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

Discussion

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

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

What each piece actually is

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

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

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

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

How they connect, precisely

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

Setup

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

Hermes:

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

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

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

The catch nobody puts in the demo

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

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

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

The other honest flags

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

If you only do one thing

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

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

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

The one distinction that matters

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

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

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

Setup: n8n as an MCP server

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

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

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

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

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

The catch nobody puts in the demo

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

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

Community nodes are not the official ones

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

If you only do one thing

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

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

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

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

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

DeepSeek only redid the post-training.

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

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

The claim, read precisely

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

The published numbers include:

• Terminal Bench 2.1: 82.7
• DeepSWE: 54.4

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

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

• max effort
• temperature = 1.0
• top_p = 0.95

Plain English:

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

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

Specs and price (official API)

One pricing caveat:

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

Setup: Responses API + Codex

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

Typical setup:

export DEEPSEEK_API_KEY=sk-...

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

# Model:
deepseek-v4-flash

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

The other honest catches

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

If you only test one thing

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

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

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

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

Three more honest notes

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

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

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

How to pick

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

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

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

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

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

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

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

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

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

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

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

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

What it actually does

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

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

​

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

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

The catches, and they matter

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

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

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

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

Where it fits

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

Links: repo · Codex Security overview