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

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

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

Install in Claude Code (tested, works):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How to pick if you only try one

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

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

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

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

One-time setup

Install Hermes and reload your shell:

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

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

Hermes Agent + GLM-5.2

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

Route A: direct from Z.AI (recommended)

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

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

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

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

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

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

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

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

Route C: the flat-rate GLM Coding Plan

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

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

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

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

Verify it actually works

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

hermes

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

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

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

How to pick your route

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

The catches (and the soundness notes)

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

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

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

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

→ The verified setup, with CI proof & readymade prompt

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

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

1. In-context (working) memory

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

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

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

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

Verified recipe: letta-agent-managed-memory

2. Semantic memory

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

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

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

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

Verified recipe: cognee-knowledge-graph-memory

3. Episodic memory

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

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

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

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

Verified recipe: graphiti-temporal-graph-memory

4. Procedural memory

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

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

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

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

Verified recipe: voyager-skill-library-pattern

5. External / retrieval memory

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

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

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

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

Verified recipe: llamaindex-retrieval-memory-rag

6. Parametric memory

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

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

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

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

Verified recipe: unsloth-parametric-finetune-config

7. Prospective memory

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

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

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

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

Verified recipe: reme-prospective-schedule

Which ones you actually need

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

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

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

What it is, in one line

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

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

Where to run it (hosted)

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

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

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

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

What it costs versus Opus 4.8

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

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

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

How close is it to Opus 4.8, really

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

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

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

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

How to pick if you only try one route

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

→ The verified setup, with CI proof & readymade prompt

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

Setup

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

/model default --provider moa
/moa

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

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

Manage presets from the terminal:

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

Mixture of Agents (MoA) in Hermes

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

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

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

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

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

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

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

The catch:

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

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

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

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

→ The verified setup, with CI proof & readymade prompt

How to pick if you only try one thing

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

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

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

What it actually is

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

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

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

Setup

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

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

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

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

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

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

The useful part

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

The catch (and the soundness caveats)

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

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

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

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

→ The verified setup, with CI proof & readymade prompt

How to pick if you only try one thing

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

Hey everyone,

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

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

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

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

1. Synthetic Grounding (Canvas AI Accessibility)

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

2. True Local Episodic Memory (LanceDB + FastEmbed)

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

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

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

3. Execution & Security

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

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

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

Repo:https://github.com/rush86999/atom

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

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

Job 1: Write the agent loop without a heavy framework

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

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

→ The verified setup, with CI proof & readymade prompt

Job 2: Stop hand-tuning prompts

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

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

Job 3: Give the agent real tools through one protocol

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

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

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

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

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

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

Job 5: Test and red-team before you ship

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

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

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

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

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

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

How to pick if you only try one

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

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

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

Cut your token bill: codebase-memory-mcp

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

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

Cut your agent-infra bill: flue

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

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

Cut your creative-tool bill: OpenMontage

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

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

How to actually use this

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

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

One-time setup

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

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

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

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

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

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

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

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

The four shapes it takes, from the docs:

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

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

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

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

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

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

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

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

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

Then review staged writes before they land:

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

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

→ The verified setup, with CI proof & readymade prompt

If you only try one thing

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

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

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

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

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

Extend with vetted skills: agent-skills

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

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

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

Give it reach: Agent-Reach

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

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

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

Scan before you trust: SkillSpector

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

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

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

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

The rule that ties it together

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

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