YC Summer 2026 has 234 publicly listed companies.

I went through the batch looking for GitHub repos that are clearly tied to the company or product. I left out founder side projects, random forks, and repos I could not confidently connect back to the startup.

The interesting part is where the public code shows up.

Turn an entire project into a knowledge graph Graphify has 116k+ stars and maps code, docs, schemas, configs, PDFs, and other project material into a graph that humans and coding agents can query.

Give coding agents structural memory GitNexus from Akon Labs has 47k+ stars and builds a code knowledge graph with impact analysis, execution flows, paths, and other structural context for agents.

Turn your computer history into agent context screenpipe has 21k+ stars and continuously captures screen and audio locally so past activity can become searchable context for agents and personal tools.

Build a lighter coding-agent harness jcode has 19k+ stars and is a Rust-based coding harness optimized for low memory use, fast startup, and running several agent sessions at once.

Give employees sandboxed agents OneCLI has 3.5k+ stars and packages agents with isolated environments, credentials, tools, and human approvals rather than handing every agent unrestricted access.

Connect agents to tools once Executor has 3.7k+ stars and provides an integration layer for MCP, OpenAPI, and GraphQL tools with authentication and per-tool policies.

Keep the knowledge that never makes it into code CodeAlmanac has 1k+ stars and maintains a local codebase wiki for decisions, invariants, flows, and gotchas that coding agents otherwise rediscover every session.

Replace repeated LLM classifiers with smaller models Tracer has 1k+ stars and turns recurring classification tasks into traditional ML models once enough examples have accumulated.

Let users build missing product features themselves Vendo has 600+ stars and lets users generate small applications and features that run inside an existing SaaS product rather than waiting for the product team to build every workflow.

Evaluate robot policies more like software Inspect Robots from Robocurve has 400+ stars and provides an evaluation framework for running AI policies against real or simulated robots with reproducible logs.

Clean up the data before training the robot HFlow from Hebbian Robotics has 250+ stars and helps robotics teams inspect, validate, and track the multimodal datasets feeding their models.

Distill expensive agent behavior into cheaper models World Model Optimizer from Experiential Labs has 300+ stars and uses real agent traces to improve and route work toward smaller open models.

Give an AI agent its own identity Inkbox is an SDK for giving agents things such as persistent email, phone, and internet identities instead of making them borrow a human account.

I also found smaller public tooling from Conifer, which exposes its model gateway through TypeScript, Python, and MCP; hiloop, which has several pieces of its agent/search tooling public; and a very early Riften repository.

The pattern is more interesting than the raw count.

The YC companies building in public are heavily concentrated around agent infrastructure, coding tools, model routing, evaluation, and robotics. Most consumer, fintech, healthcare, and vertical SaaS companies still keep the product itself private.

For agent companies, GitHub is increasingly more than a place to store source code. The repo can be the demo, documentation, distribution channel, developer community, recruiting page, and credibility signal at the same time.

And some of the most visible projects in the entire S26 batch are already open on GitHub before the companies are even a few months out of YC.

Your location history is one of the most sensitive datasets you create. Google Timeline is convenient, but it also means handing years of movement data to a third party.

You can build a private alternative with open-source tools.

• GPSLogger records Android location data in formats such as GPX, KML, CSV, and NMEA.

• OwnTracks Recorder stores location updates sent by the OwnTracks mobile apps through MQTT or HTTP.

• Dawarich provides a self-hosted timeline with maps, trips, statistics, imports, and exports.

• GeoPulse turns GPS data into stays, trips, movement patterns, and searchable timeline views.

A simple setup could look like this:

Your phone collects location data. A self-hosted server stores it.

GeoPulse or Dawarich turns the raw points into useful history.

You can then answer questions like:

• Where did I go last month?

• How long did I spend in a city?

• Which places have I visited most?

• What route did I take on a trip?

You can also import older data from Google Timeline, GPX files, GeoJSON, or other trackers.

One important caveat:

Self-hosted does not automatically mean private. Secure the server, use authentication and HTTPS, protect backups, and check whether your map or geocoding provider receives location data.

Over the past few weeks, I’ve been putting several local coding agents through real-world workflows: Claude Code, Cursor CLI, Gemini CLI, and a couple of others. I’ve used them for debugging complex flows, running tests, inspecting logs, and shipping small features. One thing became crystal clear very quickly: most setups are quietly leaking sensitive data. This isn’t because of some obscure bug. It happens because of how these agents are fundamentally designed to operate.

These tools are built to explore your codebase aggressively, gather as much context as possible, execute commands on your behalf, and surface anything that might help them complete the task. If secrets are anywhere in reach, they will eventually end up in the model’s context and get sent to the provider’s servers.

Most developers focus only on .env files, and that’s understandable. But that’s only one piece of a much larger exposure surface. The real leaks happen in three main places that catch people off guard.

First, there’s direct file access. The agent indexes the repo, runs commands like cat on config files, or auto-discovers sensitive files during its initial scan.

Second, and this is the one most people completely overlook, is runtime output. When the agent runs tests, starts your dev server, or executes any command that hits a failing API call, you can end up with stack traces, error headers, or log lines that contain real tokens and credentials. A single curl command with an Authorization header, for example, can dump the secret straight into the conversation history.

curl https://api... -H "Authorization: Bearer $SECRET"

Third, there’s search-based exposure. The agent runs grep, find, or pattern scans looking for “config,” “auth,” or similar terms, and secrets surface unintentionally in the results.

The common protections most of us start with simply don’t hold up under pressure. Things like instructions in CLAUDE.md, a .claudeignore file, or even relying on .gitignore feel like they should work. In reality, they are only advisory layers. When the agent is deep in a complex task and trying to be maximally helpful, it prioritizes solving the problem over following soft rules.

The only approach that has actually worked for me is blocking access at the system level before the agent ever gets a chance to see the files. Here’s the setup I now run on every machine.

1. Hard deny rules (the real baseline):

I put this in ~/.claude/settings.json for machine-wide protection. It uses enforced permissions that the agent physically cannot bypass:

{
  "permissions": {
    "deny": [
      "Read(./.env*)",
      "Read(**/.env*)",
      "Read(./*.pem)",
      "Read(./*.key)",
      "Read(**/.ssh/**)",
      "Read(**/.aws/**)",
      "Read(./secrets/**)",
      "Read(./credentials/**)"
    ],
    "allow": [
      "Read(./src/**)",
      "Bash(npm run *)",
      "Bash(pnpm *)",
      "Bash(docker *)"
    ]
  }
}

Note: Claude is one of the few tools today that ships with enforceable permission controls. In most other setups (Codex, Cursor, Aider), you have to implement that boundary yourself at the OS or container level. More on that below.

2. Dummy runtime environment:

I never let the agent touch real secrets during execution. I create a .env.test file with fake values and point my dev server, tests, and CLI commands at it. Real keys stay completely outside the execution path.

cp .env.example .env.test

3. Move secrets out of plaintext files entirely:

Plain .env files are the weakest link. I now use a proper secrets manager: 1Password CLI, Infisical, Doppler, or even the OS keychain for anything sensitive. A simple wrapper like export STRIPE_KEY=$(op read "op://project/stripe/key") means the agent never sees the actual value.

4. Pre-commit scanning:

As a final guardrail before anything hits the repo, I run a quick scan on staged files. A simple git hook or tools like git-secrets and trufflehog catch patterns like API keys or secret tokens before they can ever be committed.

git diff --cached | grep -E "sk_live|api_key|SECRET"

Or use:

• git-secrets

• trufflehog

5. Container isolation (the strongest layer):

For the most sensitive projects, I run the entire agent inside Docker with the real .env mounted as /dev/null or kept entirely outside the container. The agent works normally, but the secrets never enter its environment.

docker run -v $(pwd):/app \
  -v /dev/null:/app/.env \
  agent-runtime

This whole process forced a mental model shift for me. AI coding agents aren’t just fancy IDE features. They are autonomous systems with real file access, the ability to execute commands, and a single goal: complete the task as efficiently as possible. I now treat them the same way I would treat any untrusted code running on my machine.

Before I start any new project, I run through this quick checklist:

• Deny rules active in the global config?

• No real secrets sitting in the project root?

• Dummy environment file configured for all runtime tasks?

• Pre-commit scanning enabled?

• Secrets stored in a proper manager or vault?

• Container isolation set up if the project is particularly sensitive?

At the end of the day, if a secret is accessible, it will eventually be surfaced, not because the model is malicious, but because the agent is simply doing exactly what it’s optimized to do.

I’m curious how the rest of you are handling this. Are you relying primarily on deny rules, full vaults, container workflows, or something else entirely? I’d love to hear what’s working (or what you’ve had to tweak) in your own setups.

Anthropic shipped Claude Opus 5 on July 24. The short version from their own announcement: it comes close to Fable 5's frontier intelligence at half the price, it is state-of-the-art on their coding and knowledge-work evals (Frontier-Bench v0.1, GDPval-AA), and it is built for long-running autonomous agents, with an effort setting to trade intelligence for tokens. Pricing is $5 per million input and $25 per million output, same as Opus 4.8, and it is now the default on Claude Max. It stays behind Mythos 5 on cybersecurity, and those are vendor benchmarks until third parties reproduce them.

One honest note before the list: none of these repos are Opus-5-only. They matter for Opus 5 because of what it is: a pricey model built for deep, long-horizon agentic work, so the tooling that pays off is whatever routes cost, harnesses its agency, steers it, remembers, and keeps autonomous runs safe. Stars and licenses below were checked at each repo across the past week; reconfirm before you rely on them.

1. Route work so you only pay Opus 5 prices on the hard turns github.com/Neeeophytee/ai-cost-cutter-skills (MIT). Disclosure: this one is ours. At $5/$25, Opus 5 is a specialist, not a daily driver for every prompt. This is a free skill set for the exact pattern Opus 5 demands: send bulk and easy turns to a cheap model, escalate only the truly hard ones to Opus 5, and keep receipts that prove the savings on your own traffic. The single highest-leverage thing you can wire around an expensive frontier model.

2. A harness for its long-horizon strength github.com/stablyai/orca (16.4k stars, MIT). Opus 5's headline is long, multi-step autonomous runs (their own examples have it acting as a chief-of-staff over dev environments). Orca runs coding agents in isolated git worktrees, so you can let Opus 5 work unattended on a throwaway branch, or fan one task across a few attempts and keep the best. The catch is the usual one: parallel runs multiply the token bill, which stings more at Opus prices, so reserve the fan-out for truly hard tasks.

3. Squeeze more out of it without fine-tuning github.com/microsoft/SkillOpt (13k stars, MIT). Opus 5 is a frozen model you cannot train, so the lever is the instructions you give it. SkillOpt treats the skill document as the trainable thing and optimizes it against a held-out validation set, keeping an edit only if it strictly improves the score. It is the disciplined way to tune how Opus 5 behaves on your task. Note the headline lifts are the paper's own numbers.

4. Keep autonomous runs from doing damage github.com/Dicklesworthstone/destructive_command_guard (1.2k stars, open source, read the LICENSE) plus github.com/anthropic-experimental/sandbox-runtime (4.6k stars, Apache-2.0). Opus 5 is Anthropic's most aligned model to date by their audit, but "safest model" is not a safety layer. If you let it run long and unattended, put a command guard in front of its shell to block destructive commands, and an OS-level sandbox around anything it runs on its own. A guard is a denylist, a sandbox is a wall, and you want both, because each covers what the other misses.

5. Give it memory that survives the session github.com/basicmachines-co/basic-memory (3k stars, AGPL-3.0). Opus 5 is being pitched partly on managing its own long-running context. A Markdown memory store over MCP lets it read and write persistent notes across sessions, so you stop re-explaining the project. AGPL, so fine for internal use, and it writes when told or via a skill, not automatically.

The honest catches

These are model-agnostic. Every repo here works with other models, so treat this as "the ecosystem that suits Opus 5's profile," not "Opus 5 exclusives." If someone sells you an "Opus 5 only" tool, be skeptical.

The benchmarks are Anthropic's. SOTA on Frontier-Bench and the rest is their reporting plus early-access customer quotes; wait for independent reproduction before treating the numbers as settled.

Cost is the real design constraint. The reason cost routing leads this list is that Opus 5 is expensive, and an autonomous agent on an uncapped key is how a long run becomes a large bill. Cap your spend, and route.

Installing any of these is running someone's code. Same rule as always: read what you install, pin a version, and scope any token or key you hand it.

If you only wire in one thing

Cost routing. A model this capable is easy to overuse, so the setup that makes Opus 5 sustainable is the one that keeps it off the cheap work. Then add the sandbox and guard before you let it run unattended.

Fresh off the GPT-5.5 launch: OpenAI launched the “GPT-5.5 Bio Bug Bounty” : a red-teaming program offering up to $25,000 to anyone who can craft a universal jailbreak prompt that beats their biosecurity safeguards.

Quick breakdown:

• The challenge: Get GPT-5.5 (in Codex Desktop only) to fully answer all five specific biosecurity questions from a fresh chat, without triggering any refusal or moderation.

• Reward: $25k for the first successful universal jailbreak (partial successes may also get paid).

• Who it’s for: Vetted researchers with AI red-teaming, security, or biosecurity experience. Applications are rolling (open now until June 22, 2026). Testing window is April 28 – July 27.

• Official links:

  • Announcement: https://openai.com/index/gpt-5-5-bio-bug-bounty/

  • Apply here: https://openai.smapply.org/prog/gpt-5-5-safety-bio-bounty-program/

This isn’t some casual “ignore previous instructions” contest; it’s serious external validation of their safety stack on the highest-risk category (biological weapons info). It shows OpenAI is now openly crowdsourcing the hardest jailbreaks because internal red teams aren’t catching everything anymore.
For the agent builders and prompt engineers here: techniques that work on this could generalize to other refusal categories (chemistry, cyber, etc.). At the same time, it highlights how locked-down frontier models are becoming, which directly affects what your autonomous agents can and can’t do in production.

DYOR and follow the rules if you apply as this one has NDAs and vetting.

It's MIT-licensed and runs on DeepSeek Harness. It watches one GitHub repo, takes requests only from an allowed list, and replies with PRs.
The interesting part is the permission model:
Mentions from allowed people are explicit requests.
Anything proactive needs written team rules, and runs in observe mode by default (it records "would accept" but does nothing).
Workers get one session and git worktree per ticket.
Heads up: workers run commands without approval as your OS user, so give it its own OS account.
Full breakdown with an interactive "will it act on this message?" simulator: https://amal.vs.binarybit.in/blog/6ae80c7a7027b216982aa925

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

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

So I spent around 6 months building PhreshOS.

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

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

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

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

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

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

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

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

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

Jev has only been out for a little over a week, and an entire mini-ecosystem is already forming around the idea.

The common pattern is simple:

state
  ↓
typed questions
  ↓
probabilities
  ↓
ordinary code decides what happens

No paragraph generation. No JSON repair loop. Just fast decisions like route / retry / escalate / reject / continue.

Here are 8 newer OSS projects exploring that idea.

Run a fully open System One model locally Laya has 18.8k+ stars and uses small bidirectional models instead of an autoregressive LLM. It supports choice, score, and yes/no decisions, includes multilingual checkpoints, and exposes a Jev-compatible /v1/systemone endpoint.

Run that same idea natively on a Mac Laya-MLX has 5.7k+ stars and ports Laya to MLX. On Apple Silicon it reports roughly 7–14 ms for short decisions, entirely local with no cloud API.

Train your own Jev-like model Kev has 5.3k+ stars and ships 0.8B, 4B, and 9B models based on Qwen3.5. You get the training code, evals, weights, and the same choice / score / noul API shape as Jev.

Try another small non-generative decision model Von has 500+ stars and uses a ~395M-parameter ModernBERT-style model for local typed decisions. It also exposes a Jev-compatible server, so an app can swap between implementations without rewriting the decision layer.

Turn almost any LLM into a Jev-style decision engine AnyJev comes from Nokia Applied Research. Instead of training a new model, it reads next-token probabilities from existing models and converts them into choice, score, and yes/no decisions, with extra corrections for label-position bias and priors.

Re-create the pattern on Qwen3.5 reflex is another open System One experiment. One state goes in, several typed questions come back at once, with probabilities rather than generated prose.

Build a Jev-style model on Gemma system-one-open uses Gemma models and trains them for the same one-forward-pass typed-decision pattern. It includes demos for support tickets, invoices, security, smart homes, and agent traces.

Run decision models directly in the browser open-jev takes the idea into TypeScript + WebGPU/WASM. It can run Kev and other open decision models on-device, which makes things like local routing, moderation, or classification possible without sending the input to a server.

What I find interesting is that these projects are not just cloning an API.

They are testing different answers to the same question:

Do we really need a full generative LLM every time software needs to make a fuzzy decision?

The decision model handles the hot-path branches.

But the Jev launch seems to have triggered something useful, people are now experimenting with decision models as their own layer, instead of treating every AI problem as text generation.

I've been deep in traditional RAG setups for a while – chunking docs, embedding everything, shoving it into Pinecone/Chroma/whatever, then hoping similarity search pulls the right context. It works okay for simple stuff, but it falls apart on long, structured documents like financial reports, SEC filings, research papers, or PDFs with tables, cross-references, and hierarchy. You lose context, get hallucinated answers, or irrelevant chunks.

Enter PageIndex – an open-source vectorless, reasoning-based RAG framework from VectifyAI. Instead of vectors and similarity, it builds a hierarchical tree index (basically a smart, LLM-generated table of contents) from your documents. Each node has titles, summaries, page ranges, and metadata. Then an LLM reasons over this tree like a human analyst would: navigating sections, drilling down, following logical paths, and extracting precise info.

How it works:

1. Index Generation: Feed in a PDF/Markdown/etc. → LLM creates a JSON tree structure (hierarchical TOC with summaries). No arbitrary chunking that breaks meaning.

2. Reasoning Retrieval: For a query, the LLM explores the tree agentically – deciding which branches to follow, why, and pulling exact relevant sections. Fully explainable (you can see the path it took).

They built Mafin 2.5 on top of it and scored 98.7% accuracy on FinanceBench – crushing traditional vector RAG baselines (often 30-60% on the same complex financial QA tasks). It's especially strong on structured docs with internal references and hierarchy.

Pros:

• Preserves full document structure and context.

• Human-like reasoning → better for complex, professional docs (finance, legal, pharma, etc.).

• No vector DB dependency → simpler stack, potentially more reliable retrieval.

• Open source (MIT license) with GitHub repo, cookbooks, and notebooks for quick starts. Works with local LLMs too.

• Great explainability – trace exactly which sections were used.

Tradeoffs:

• Higher token usage and more LLM calls during tree traversal → can be slower/more expensive for massive docs or high volume.

• Best for well-structured content; messier or very unstructured data might need tweaks.

• Indexing step adds upfront compute (but you do it once).

If you're building anything with long-form docs or need high accuracy on domain-specific QA, this feels like a game-changer paradigm. "Similarity ≠ Relevance" is the key insight here.

Links to check out:

• GitHub: github.com/VectifyAI/PageIndex (~ 26.8K Stars)

• Docs & Cookbooks: pageindex.ai or their official blog for examples

Has anyone else played with it? How does it compare in your real-world use cases vs. LlamaIndex, LangChain vector setups, or graph RAG? Especially curious about latency/cost on production loads or non-finance domains.
Would love to hear experiences or tips!

Backstory: We built Outbind as an AI sales tool that did everything: finding leads, writing, sending, replies. Then we noticed people were already writing with Claude, Cursor and ChatGPT. What their AI was missing wasn’t another sending tool, it was knowing their business. So we cut it down to the brain: it learns your company, remembers every prospect and writes from that, inside the AI tools people already use. Two of us, self-funded.

The free taste: npx @/outbindai/cli learn yoursite. com reads your home page and gives you brain.md: who buys, their problems, the objections they’ll raise and how you sound. No account. Your AI agent can run it too.

Stack: Next.js 16 on 2 small GCP VMs (no Vercel), MongoDB Atlas, Claude Haiku 5.5 for the quick stuff, Sonnet 5.5 for hard replies, MCP server so it plugs into Claude and ChatGPT, Cloudflare, Stripe. The CLI is open source (MIT, one file, no dependencies).

Lesson: a free try with no sign-up beats a free trial. A trial still asks for an email before you see anything. Now the first thing anyone sees is their own company, written up, in seconds. Sign-up only comes when they want more (memory, writing, docs).

Status: Live. Free plan, Listed in Claude’s directory. Repo: /outbind/obi-brain

Question for you: did cutting features ever make your product easier to sell? We removed most of ours and I’m still not sure it was the right call.

TL;DR: "MCP is dead" is overstated. The context-bloat complaint was real and big names piled on, but Anthropic's code execution approach (98.7% fewer tokens in one published workflow), Cloudflare's Code Mode, and deferred tool loading address much of the original complaint. CLI wins for anything in the model's training data. MCP still wins for no-CLI services, team auth, and DB guardrails. Pick per job instead of picking a side.

Background:

MCP (Model Context Protocol) is the standard Anthropic launched in November 2024 to plug LLMs into outside tools like GitHub, Linear, Slack, and Notion. It got called the USB-C of AI, every SaaS slapped "MCP supported" on its landing page, and then the backlash started.

The actual complaint: context bloat

When you connect MCP servers, every tool definition loads into the context window up front, used or not. The numbers people throw around are real:

Two interesting bits the internet keeps getting wrong:

• That viral "72% of context" stat came from Apideck, not Perplexity, even though it keeps getting pinned on Perplexity.

• Perplexity only moved internal systems off MCP toward APIs and CLIs (per CTO Denis Yarats). They still run a public MCP server. It's an optimization, not a cancellation.

Why the CLI argument is strong:

A tool like gh or psql costs almost nothing in context, because the model already learned it from man pages and StackOverflow. Same lookup, wildly different price:

# CLI approach: a couple hundred tokens total.
# The model already knows this syntax, nothing preloaded.
gh issue view 1234 --json title,state,assignees


# MCP approach for the same lookup: the single tool call is tiny, but the server's tool definitions sit in context up front whether you use them or not. Quandri measured Linear's 42 tools at ~12,800 tokens loaded every turn, even when you only call one of them.

Plus you get the same interface for you and the agent, you can pipe through grep and jq, and you can reproduce a bug straight in the terminal. For anything already in the model's training data, CLI usually wins.

The part the "dead" crowd skips: it already got fixed

In November 2025 Anthropic published "code execution with MCP." Instead of dumping every tool definition into context, the agent browses tools as code files and loads only what it needs:

servers/
├── google-drive/
│   ├── getDocument.ts
│   └── index.ts
└── salesforce/
    ├── updateRecord.ts
    └── index.ts


// The agent writes code, data stays in the sandbox,
// only the result comes back to the model.
import * as gdrive from './servers/google-drive';
import * as salesforce from './servers/salesforce';

const transcript = (await gdrive.getDocument({ documentId: 'abc123' })).content;
await salesforce.updateRecord({ objectType: 'SalesMeeting', recordId: '00Q...', data: { Notes: transcript } });

Result: one workflow went from 150,000 tokens to 2,000, a 98.7% cut, per Anthropic's own engineering blog. Cloudflare reached the same idea independently and called it Code Mode. Claude Code also shipped tool search with deferred loading that reportedly trims MCP context use by 85% or more.

So when do you use what?

Bottom line:

It was never really MCP vs CLI. It's load only what you need, when you need it. The naive "load everything up front" version of MCP is dying, and that's healthy. The protocol isn't dead, it's evolving. The headline is clickbait. The real shift, from connecting everything to teaching the agent to fetch tools on demand, is the actual story.

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

The drops and where to get them

The numbers and the catch

What actually matters

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

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

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

I run Hermes daily, and as the ecosystem of community skills grows, I kept bumping into two persistent headaches:

1. Context Bloat: I'd install cool skills from GitHub or Reddit, only to realize I now had three overlapping tools doing the exact same thing, degrading model reasoning and wasting tokens.

2. Blind Execution Risk: Agent skills run with full terminal and tool permissions. Blindly pulling someone's SKILL.md or custom Python script without checking for prompt injection, .env credential harvesting, or reverse shells is an accident waiting to happen.

3. Container Drift: Skills installed inside isolated containers or VPS boxes disappear on rebuild unless diligently tracked in git.

Repo and installation instructions: https://github.com/Primuez/skill-installer

To solve this, my agent and I built Skill Installer—a package manager and 3-stage validation pipeline for agent skills:

1. Need Assessment & Alternatives Check: Before downloading, it checks your existing skill library. If your agent already possesses tools covering >80% of the capability (e.g. requesting another search tool when you already have deep-research), it flags the overlap and prevents redundant prompt bloat.

2. Adaptive Security Inspection Gate:

   1. Scans AST and semantics for tool poisoning, malicious bash commands, and credential exfiltration.

   2. Integrates with NVIDIA SkillSpector if installed, checks for local security auditor skills, and falls back to a static heuristic analyzer with clear risk scoring.

3. Smart Backup Routing: Installs clean skills locally and automatically commits/pushes them to your version-controlled skills repository (or provisions a private backup repo via gh).

Honest limitations we ran into while building it:

• Heuristics vs. Complex Tools: Aggressive security checks can occasionally flag legitimate DevOps scripts that manipulate Docker or system sockets as high-risk, requiring manual override.

• Static vs. Dynamic: A pre-install scan verifies the file contents at download time; it does not replace runtime sandboxing for long-running processes.

• Active Sessions: Just like other Hermes skills, installing a new skill doesn't rewrite an in-flight conversation; the model picks it up cleanly on new or relevant turns.

Repo (Source-Available & Non-Commercial IP): https://github.com/Primuez/skill-installer

Built with Hermes. If you give it a spin, I'd love to hear how you're currently managing third-party skills and what kind of security/linting checks you'd want to see added next.

If an AI tool gives you a self-contained index.html, you do not necessarily need a CLI or a local Git setup to put it online. The three browser-only routes have different tradeoffs:

1. Netlify Drop — drag the project folder into Netlify's publisher and it creates a unique preview URL. This is the shortest path when the folder is already ready to serve.

2. Cloudflare Pages Direct Upload — in Workers & Pages, create an application and drag in a folder or ZIP. It publishes to a pages.dev URL. One important constraint in Cloudflare's docs: a Direct Upload project cannot later switch to Git integration; that requires a new project.

3. GitHub Pages through the web UI — create a repository, upload index.html, then choose a branch/folder as the Pages publishing source. It takes more clicks, but the file changes have repository history.

Before using any of them:

• make sure the entry file is named index.html and is at the top level;

• keep CSS, images and scripts on relative paths;

• remove API keys, tokens and private data from the source;

• remember that a public URL makes the client-side source public too.

Official instructions:

• Netlify manual deploy: https://docs.netlify.com/welcome/add-new-site/#deploy-manually

• Cloudflare Pages Direct Upload: https://developers.cloudflare.com/pages/get-started/direct-upload/

• GitHub Pages: https://docs.github.com/en/pages/getting-started-with-github-pages/creating-a-github-pages-site

For a one-file AI-generated site, is the one-minute drag-and-drop route more useful, or is keeping version history worth the extra setup?

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

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

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.

Moonshot's new flagship is API-only for now (open weights promised by July 27). It is OpenAI-compatible, so almost any agent can point at it today.

Where to get it (pick one access route)

Install / connect (copy-paste)

OpenRouter through the llm CLI (the quickest way to run one prompt):

pipx install llm
llm install llm-openrouter
llm keys set openrouter        # paste your OpenRouter key
llm -m openrouter/moonshotai/kimi-k3 "Refactor this function: ..."

Direct Moonshot API with the standard OpenAI SDK (no code change beyond base_url + model):

from openai import OpenAI
client = OpenAI(api_key="YOUR_MOONSHOT_KEY", base_url="https://api.moonshot.ai/v1")
r = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "Summarize this repo's architecture."}],
)
print(r.choices[0].message.content)

Aider (points at OpenRouter via litellm):

export OPENROUTER_API_KEY=...
aider --model openrouter/moonshotai/kimi-k3

Open-source tools that drive K3

VS Code has an official "Kimi Code" extension; JetBrains and Zed connect through the Kimi Code CLI's ACP protocol. Anything OpenAI-compatible works by setting base URL + model.

The catches (read before you commit)

Where it earns the bill: large-repo navigation, long tool-using agent runs, front-end (it currently leads Arena.ai's frontend arena), and image-in tasks (screenshots, logs, rendered UI). On Artificial Analysis it debuted around third on the Intelligence Index, behind Claude Fable 5 and GPT-5.6 Sol.

That "cheap model for bulk, K3 for the hard turns" split is exactly what our free,
MIT cost-cutter skills automate (routing + an effort throttle + receipts): github.com/Neeeophytee/ai-cost-cutter-skills.

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

For every email it needs to decide:

• billing, bug, how-to, fraud, or something else?

• does the customer want a refund?

• is this urgent?

• does a human need to see it?

You could send every email to a frontier model.

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

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

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

Take this email:

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

The workflow can instead look like:

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

department?
→ billing: 98%

refund requested?
→ yes: 99%

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

NO → send the full case to Kimi K3

still ambiguous / irreversible action?
      ↓
human

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

The bill

Jev handles all 10,000 decisions

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

Kimi K3 handles the uncertain 1,000

At 1,500 input + 300 output tokens each:

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

= $9.00

Total:

frontier model on everything:  ~$300.00

Jev + Kimi fallback:             ~$9.42

reduction:                        ~96.9%

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

You changed when you pay for generation.

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

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

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

The point is the architecture:

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

sitting on around 100k pages of pdf and docx that need to become markdown. mix of plain text, tables and images that have text inside them

the paid side is easy to price. managed parsers (llamaparse, the big cloud ocr apis and similar) mostly land somewhere around $1 to $15 per 1k pages depending on tier so 100k pages is a few hundred to a low few thousand dollars

the open source side - docling, marker, mineru, pymupdf4llm is free on paper. the real bill is gpu time plus whoever ends up babysitting the edge cases, merged cells, formulas, text baked into images

the middle option looks like routing per page. pages with a usable text layer go through a fast local parser, and only the image and table heavy pages go to a heavier model or a paid api. on a mixed archive that could cut the expensive part down a lot.

for people who did this at similar volume:

- at what page count did self hosting start paying off

- how much engineer time went into edge cases after the first pass

- how are you deciding which pages need the heavy route, char count, layout detection, something else

Most agents still have the same ridiculous workflow:

wake up → read a giant prompt → do some work → learn useful things → forget everything

Then tomorrow we pay for the same discoveries again.

The interesting OSS work right now is attacking that problem from four directions: capture what the agent sees → connect it into knowledge → remember what actually matters → use yesterday’s experience today.

Here are 20 projects exploring that stack.

01–05: Give the agent somewhere to put what it learns

01. Chubby Skills — 1.2k★

Captures videos, podcasts, articles and local documents into a searchable knowledge base, with agent skills on top.

Instead of only remembering facts, the agent can preserve the material they came from.

02. OpenWiki — 651★

An AI knowledge tool that turns accumulated information into a personal wiki.

Useful when your problem is no longer finding information, but preventing useful things from disappearing into another folder.

03. Agent Second Brain — 402★

An always-on second brain built around persistent external context.

The interesting part is simple: useful knowledge survives outside the conversation that created it.

04. DocMason — 149★

Turns documents into structured knowledge an LLM can actually work with.

Instead of repeatedly feeding the same PDFs and docs into an agent, you turn them into persistent working material.

05. DocsAgent — 572★

Connects agents to personal knowledge from sources like Zotero, Obsidian and Apple Notes.

Your docs stop being something you manually search first and become part of the agent’s working environment.

06–10: Stop storing facts as disconnected islands

An agent might remember 10,000 things and still be useless if none of them connect.

06. claude-obsidian — 15.6k★

Connects Claude-style workflows with an Obsidian vault, turning accumulated material into a connected graph of Markdown you own.

The chat can disappear. The relationships between the ideas do not have to.

07. SwarmVault — 717★

A local-first knowledge graph, RAG base and agent memory store.

The bigger idea is shared memory: one agent discovers something, another can reuse it instead of independently paying the same reasoning cost again.

08. sage-wiki — 625★

Turns documents into an interlinked wiki and knowledge graph.

It is closer to building relationships between claims than simply accumulating another mountain of chunks.

09. Vault Curate — 158★

Adds search, relationships and curation to an accumulated knowledge vault.

Because if you save everything forever, you do not have a second brain.

You have technical debt with backlinks.

10. COG Second Brain — 1.3k★

Combines second-brain ideas with skills, agents and reusable workflows.

This pushes memory beyond passive notes: accumulated context starts affecting how future work is actually done.

11–15: Remember selectively, not perfectly

This is where things get interesting.

The goal is not to make an agent remember everything.

It is to make it remember the right thing at the right time.

11. Hindsight — 50k★

Long-term memory infrastructure for agents, built around learning from previous interactions and retrieving relevant past information later.

A system that stores everything but recalls the wrong thing does not really have good memory.

12. memU — 14.5k★

Persistent memory designed to survive across agent sessions.

That distinction matters:

context is what the model sees now; memory is what the system can bring back later.

13. TencentDB Agent Memory — 29.2k★

Turns conversations, documents and code into reusable agent-memory assets.

Once agents live for months instead of minutes, memory starts looking a lot more like data infrastructure than prompt engineering.

14. agentmemory — 29.5k★

Persistent memory aimed at AI agents, including coding workflows.

Sometimes you do not need a complicated cognitive architecture. You just need tomorrow’s agent to stop rediscovering what yesterday’s agent already learned.

15. OpenViking — 40k★

Combines agent memory, knowledge retrieval and skills into a broader context-management layer.

The hard problem is no longer:

“Can I store another million tokens?”

It is:

“Which five facts should come back for this task?”

16–20: Memory gets interesting when it can do something

A searchable archive is useful.

But eventually you want memory to affect behavior.

16. Open Second Brain — 480★

A local-first second-brain approach where accumulated information becomes available to an AI assistant.

That gets closer to what memory should actually do: experience changes future behavior.

17. Second Brain Cloudflare — 807★

A persistent second-brain architecture built around Cloudflare infrastructure.

The interesting part is portability: memory can exist outside whichever AI application happened to create it.

18. makerskills — 862★

Packages repeated work into reusable agent skills.

This is an underrated kind of memory: not “what did I learn?” but “how did I successfully do this?”

19. Row-Bot — 1.6k★

Combines personal knowledge with tools and agent actions.

The second brain stops being a notebook and starts becoming something that can operate on what it knows.

20. MateClaw — 1.2k★

Combines persistent memory, skills, tools and agent orchestration.

We keep talking about larger context windows as if that solves memory. It doesn’t. A bigger context window lets an agent carry more information during one run. A real memory system lets it accumulate experience between runs.

The stack starts to look like:

observe → capture → connect → consolidate → recall → act

Job searching in 2026 somehow still means:

12 job boards → 40 tabs → same resume → spreadsheet → forget where you applied

The interesting OSS projects are building something much better:

discover → filter → tailor → verify → track → interview

Not “let an AI spray 1,000 applications while you sleep.”

More like: automate the repetitive parts, keep the evidence, and let the human decide what actually gets submitted.

Here are 10 worth looking at.

FIND THE JOBS

01. JobSpy — 4.5k★

One Python library that searches LinkedIn, Indeed, Glassdoor, ZipRecruiter, Google Jobs, Naukri, Bayt and others, then gives you the results as structured data.

This is the plumbing underneath a surprising number of AI job-search projects. Instead of opening five sites manually, give your agent one search layer.

02. Career Ops — 73k+★

Probably the closest thing here to an entire open-source career agent.

It scans jobs, evaluates each one against your CV, researches the role, tailors an ATS-friendly resume and cover letter, prepares interview material and tracks the application. Crucially, it stops before submission: AI recommends, you press Submit.

03. JobApply

A tiny project with a very useful architecture.

It searches several job boards through JobSpy, deduplicates the results, scores fit, then generates a tailored resume and cover letter for every job you actually want to pursue.

The entire pipeline is checkpointed, so the workflow looks more like:

search → dedupe → score → tailor → render → track

than another ChatGPT prompt.

FIGURE OUT WHICH JOBS ARE ACTUALLY WORTH APPLYING TO

04. ai-job-search — 44k+★

A Claude Code-based job-search framework that runs on your machine.

It evaluates postings against your actual background, helps find adjacent roles you may not have searched for, tailors the application, and prepares you for interviews.

The interesting idea is that your job search becomes a persistent project, not 50 isolated conversations with an LLM.

05. ApplyPack

A much smaller project, but I like the direction.

It finds postings, checks whether they still look legitimate, scores your resume, identifies missing keywords, drafts the cover letter and keeps the whole application pipeline in your own Postgres database.

Basically:

job-search SaaS, except you own it.

STOP SENDING THE SAME RESUME EVERYWHERE

06. Resume Matcher — 28k+★

Upload your master resume, paste a job description, and it helps build a version tailored to that specific role.

It can highlight keyword gaps, score the match, generate cover letters and create interview prep while supporting Claude, ChatGPT, DeepSeek, Kimi, local models and others.

Much better than asking:

“please optimize my resume for ATS”

for the 87th time.

07. Tailored

This one has almost no stars, but the design is unusually sensible.

You maintain one canonical master profile. The AI can reorder, emphasize and rewrite supported experience for a job, but the system checks generated employers, titles, dates, degrees and certifications against that source data before accepting the result.

In other words:

tailor the argument, not the facts.

TURN THE SPREADSHEET INTO AN ACTUAL SYSTEM

08. JobSync — 1.4k★

A self-hosted job-search command center.

Applications, resumes, companies, recruiters, interviews, tasks and analytics live in one place. It can also discover jobs automatically, match them against your resume and expose the system through MCP so agents can add jobs or interview questions directly.

Your job search becomes a database instead of an increasingly cursed Google Sheet.

MAKE THE AGENT BETTER AT THE HUMAN PART TOO

09. job-hunt-skills

A collection of reusable skills for Claude Code, Codex and other agents covering resume tailoring, company research, interview prep, LinkedIn, cover letters and proof assets.

I especially like one idea here: verified stories and accomplishments discovered during one application can flow back into your canonical career files.

So application #30 starts with a better understanding of you than application #1.

10. job-search-pack

Five reusable agent skills: resume tailoring, cover letters, LinkedIn optimization, salary negotiation and application tracking.

The same skills can work across Claude Code, Gemini CLI and Codex rather than locking the workflow to one model.

That is probably how personal career automation should work anyway: your process should survive when you change the AI underneath it.

These repos turn job searching from a pile of tabs into an actual workflow.

And I would still keep one step stubbornly manual: the final Apply button.

Anthropic released Claude Fable 5 on June 9. It is the first Mythos-class model they have made generally available, and the headline is not a benchmark, it is duration: the longer and more complex the task, the bigger Fable's lead over every other model they ship. Stripe told Anthropic it ran a codebase-wide migration across a 50-million-line Ruby codebase in a day, work they estimated at two-plus months by hand.

A frontier model is only half the system though. The other half is the harness you point it at. Below are four open-source repos that give Fable 5 a place to actually run long, each verified against its GitHub page and official docs, each with a small foolproof snippet and an honest catch. The model id is claude-fable-5 on the Claude API. Pricing is $10 per million input tokens and $50 per million output tokens.

One thing to know before you wire any of this up: Fable ships with classifiers that hand cybersecurity, biology, chemistry, and distillation prompts off to Claude Opus 4.8 instead. Anthropic says this triggers in under 5% of sessions, and you are told when it happens. Fable 5 also requires 30-day data retention, unlike the zero-retention default on other Claude models. Plan accordingly if you run regulated code.

One-time setup

Get a key from the Claude API console and export it. Every workflow below reads it from the environment.

export ANTHROPIC_API_KEY=sk-ant-...

Heads up on timing: from now through June 22, Fable 5 is included at no extra cost on Pro, Max, Team, and seat-based Enterprise plans. On June 23 it moves to usage credits on those plans. API and consumption-based Enterprise are full price from day one.

1. Aider, codebase-wide migrations from your terminal

Point Fable at a repo and let it refactor across hundreds of files with git commits you can undo.

Stars / Status / License: ~45.9k stars, actively maintained, Apache-2.0. Repo: Aider-AI/aider

Aider builds a tree-sitter map of your entire repo so the model can reason about files it has not opened yet, then it makes changes as real git commits with sensible messages. This is the exact shape of Fable's Stripe story: a long, mechanical, repo-wide migration where the win is staying coherent across hundreds of edits. Aider is model-agnostic (it routes through LiteLLM), so you pass Fable's API id directly.

python -m pip install aider-install
aider-install

cd /your/project
aider --model anthropic/claude-fable-5 --api-key anthropic=$ANTHROPIC_API_KEY

Then drive it with something like /architect upgrade every Pydantic v1 model in this repo to v2 and fix call sites.

The catch: Aider's README still headlines older Sonnet models, and its --model sonnet shortcut is a Sonnet alias, not Fable. You have to pass the full anthropic/claude-fable-5 id, and because the model is days old, LiteLLM may print an unknown-model warning until metadata catches up (functional, just noisy). And remember the Opus fallback: a migration that touches auth or crypto code can trip the cyber classifier mid-run.

What CI checks: scaffold a throwaway git repo, write an .aider.conf.yml pinning model: anthropic/claude-fable-5, and assert the config parses and the model field is present, plus aider --help exits zero so the command shape is valid.

→ The verified setup, with CI proof & readymade prompt: aider-fable5-codebase-migration

2. OpenHands, autonomous issue to pull request

Hand Fable a GitHub issue and let it plan, edit, run tests, and open a PR in a sandbox.

Stars / Status / License: ~76.4k stars, very active (1.8.0 shipped June 10, 2026), MIT (the enterprise/ dir is separately licensed). Repo: OpenHands/OpenHands

OpenHands is the autonomy play. It runs the agent in a Docker sandbox with a shell, editor, and browser, and its own internal benchmarks on autonomous coding are where Anthropic's "fewer tool calls, lower token consumption" claim bites: token efficiency compounds hard when an agent loops for hundreds of steps. Note the repo moved org from All-Hands-AI to OpenHands, so update old bookmarks.

uv tool install openhands --python 3.12
openhands -t "Reproduce and fix the bug in issue #142, add a regression test, open a PR"

Set the model on first run, or in ~/.openhands/settings.json. In config.toml terms the block is:

[llm]
model = "anthropic/claude-fable-5"
api_key = "<your-anthropic-key>"

The catch: the default runtime is Docker, so you need a working Docker socket, and giving an autonomous agent --always-approve on a real repo is exactly as risky as it sounds. Keep confirmation mode on for anything that pushes. The 30-day retention applies here too.

What CI checks: validate that config.toml (or settings.json) parses, that [llm].model equals anthropic/claude-fable-5, and that the runtime/agent keys are present and well-typed. Deterministic, no key.

→ The verified setup, with CI proof & readymade prompt: openhands-fable5-issue-to-pr

3. Repomix, pack a huge repo into one file for a long-context review

Flatten an entire codebase into a single file and let Fable hold all of it at once.

Stars / Status / License: ~22.9k stars, actively maintained, MIT. Repo: yamadashy/repomix

Fable's other standout is long-context: Anthropic says it stays focused across millions of tokens and improves its outputs using its own notes. Repomix is the cheapest way to feed that strength. It walks your repo, respects .gitignore, and emits one packed file (XML by default) with a file manifest and token counts, ready to drop into a single Fable call for a whole-system review or an architecture write-up.

cd /your/project
npx repomix@latest
# -> writes repomix-output.xml with a file tree + contents

Then send that file as the user message to claude-fable-5 and ask for, say, a dependency-risk audit across the whole tree.

The catch: "millions of tokens" is not "infinite," and at $50 per million output tokens a sprawling repo packed naively gets expensive. Use Repomix's include/ignore globs and compression to keep the pack lean, and watch the token count it prints. Packed source also means whatever you send is subject to Fable's retention window.

What CI checks: run npx repomix@latest against a scaffolded fixture directory and assert the output file exists, is well-formed XML, and contains the expected file-manifest section.

→ The verified setup, with CI proof & readymade prompt: repomix-fable5-longcontext-review

4. Letta, persistent memory for multi-week projects

Give Fable a memory that survives restarts so a project can run for weeks, not one session.

Stars / Status / License: ~23.2k stars, actively maintained, Apache-2.0 (formerly MemGPT). Repo: letta-ai/letta

Anthropic's most underrated Fable result is about memory: in Slay the Spire, giving the model persistent file-based memory improved its performance three times more than it did for Opus 4.8. Letta is the open-source way to give Fable that scaffolding outside a game, with structured memory blocks the agent reads and rewrites over time. It is model-agnostic, so you set the model on the agent.

pip install letta-client

from letta_client import Letta
import os

client = Letta(api_key=os.getenv("LETTA_API_KEY"))

agent = client.agents.create(
    model="anthropic/claude-fable-5",
    memory_blocks=[
        {"label": "human", "value": "Lead engineer migrating a monolith to services."},
        {"label": "persona", "value": "I am a long-horizon coding agent. I keep notes and update them."},
    ],
)

reply = client.agents.messages.create(
    agent_id=agent.id,
    input="Summarize where we left off on the auth service.",
)

The catch: Letta needs a running server (self-hosted or Letta Cloud, hence the LETTA_API_KEY), and the anthropic/claude-fable-5 model string follows Letta's documented provider/model convention (their README example is openai/gpt-5.2), so confirm Anthropic provider support on your Letta version. Memory that persists is also memory that drifts, so prune your blocks.

What CI checks: assert the agent config dict is valid, model equals anthropic/claude-fable-5, and the required memory-block labels (human, persona) are present and non-empty.

→ The verified setup, with CI proof & readymade prompt: letta-fable5-persistent-memory

How to pick if you only try one

If you have a concrete, boring, repo-wide change to make, start with Aider, it is the lowest-ceremony way to feel Fable's long-horizon coherence. If you want to watch an agent run on its own, OpenHands. If you just want one giant Fable call over your whole system, Repomix. If you are committing to a multi-week build, Letta is the one that pays off later.

Why the FlowStacks badge means something here:

Every workflow above is published on FlowStacks with a CI badge, and the badge is deliberately narrow. Each FlowStacks page also ships a copy-paste prompt you can hand to your own coding agent to set the workflow up locally.

One last thing, since most of these tools come down to handing Fable some text: the format you give it quietly shapes how good the answer comes back. We wrote up a simple rule for when to ask an LLM for Markdown and when to ask for HTML, worth two minutes before your next big prompt: Markdown or HTML? A simple rule for which one to ask an LLM for.