Let Your AI Read the Frontier Labs' Homework

I was asked how I organize my AI agents and skills. The honest answer is that I didn't invent any of it — I read how the people with real telemetry do it, and copied them. There's a public repo that makes that possible, a wrong way to use it that will quietly make your setup worse, and a two-pass method that turns it into changes you can actually use.

---

I was asked how I organize my agents and skills. Good question, and my honest first answer was a little deflating:

I didn't invent any of it. I read how the people with real telemetry do it, and I copied them.

That's the whole post, really. But the useful part is how you do that reading, because there's a repo that makes it possible and a wrong way to use it that will make your setup worse.

The repo

github.com/elder-plinius/CL4R1T4S

It's a collection of system prompts — the instruction files that sit underneath commercial AI products. Anthropic, OpenAI, xAI, Google, Mistral, Moonshot, plus the coding agents: Cursor, Windsurf, Devin, Cline, Replit, Bolt, v0, Factory's Droid, Manus.

git clone https://github.com/elder-plinius/CL4R1T4S.git
cd CL4R1T4S && ls

ANTHROPIC  BOLT     BRAVE   CLINE   CLUELY  CURSOR  DEVIN
DIA        FACTORY  GOOGLE  HUME    LOVABLE MANUS   META
MINIMAX    MISTRAL  MOONSHOT MULTION OPENAI PERPLEXITY
REPLIT     SAMEDEV  VERCEL V0  WINDSURF  XAI

About 3.7 MB of text. Free.

Here's why I care about it more than I care about most prompt-engineering content: these files are load-bearing. They steer products with millions of users. Every weird, over-specific rule in them — and there are many — is almost certainly scar tissue from a real failure someone had to fix. When a vendor's prompt says a tool "might save markdown cells as 'raw' cells, don't try to change it, it's fine," that sentence exists because models kept trying to fix it and wasting turns.

You cannot buy that kind of feedback loop. You can read it.

A caveat I'd rather state up front than have you find out later: these are published extractions, not vendor-released documentation. Treat them as evidence about how serious teams write instructions, not as gospel, and definitely not as a spec you're entitled to. The value is structural. You're studying the shape, not the specific words.

The wrong way to use it

Open a file, admire it, paste large chunks into your own CLAUDE.md.

I tried a version of this early on. It's bad, for three reasons that took me a while to separate:

Most of it doesn't apply to you. A huge fraction of any commercial system prompt is product surface — UI affordances, legal boilerplate, refusal policy, tool schemas for tools you don't have. None of that transfers.

Contradictions accumulate silently. Two vendors solve the same problem differently, both reasonably. Paste both and you've handed your model a coin flip. It won't tell you. It'll just be inconsistent in ways you'll misdiagnose for weeks.

Length is not the goal. A short prompt can produce excellent behavior. Long prompts are only justified when they're steering a lot of tools. An instruction file built by patching failures you actually observed stays lean; one built by imagining failures bloats.

The way that works: make your AI do the extraction, then attack it

The method is two passes, and the second one is where the money is.

Pass one — extract. Point an agent at a vendor's prompt with a hard constraint: report only patterns that are implementable at the user-configuration layer. Instruction files, skill files, tool descriptions, hooks, subagent definitions. If it needs vendor access, it's out of scope.

Pass two — refute. This is the part people skip. Do not hand the first pass to a second agent and ask "is this right?" An agent asked to confirm will confirm. It's the single most reliable way to get a useless review.

Instead, brief a fresh agent with no knowledge of the first one's output, and give it a hypothesis to falsify: "the convenient conclusion is that this file contains nothing new. Treat that as a claim to disprove." Then tell it exactly where extractions reliably fail — negative space, turn boundaries, precedence between conflicting rules, defined failure semantics, mechanics buried in tool descriptions rather than policy prose.

In my runs, adversarial second passes add roughly a third more content than the first pass found. Same source file, same model. The only variable is whether the agent was told to agree or to attack.

One more rule that matters: grant the null result explicitly. Tell the reviewer that "nothing found" is a legitimate, valuable answer. Otherwise it pads, because returning empty-handed reads as failure and models are as prone to looking busy as people are.

I'm running exactly this as I write. Anthropic's Opus 5 prompt landed in the repo a few days ago — 2,049 lines, and my last extraction predates it:

git pull --ff-only origin main

Updating 34d6ca0..75492f5
Fast-forward
 ANTHROPIC/OPUS-5.md | 2049 ++++++++++++++++++++++++++++++++++++++

Two agents are on it right now: one extracting, one trying to prove the first one lazy.

Then point it at your own setup

Extraction is the fun half. The half that actually changes behavior is auditing what you already have against what you learned. This is where I got humbled this week, so let me just show you.

My setup is a shared directory of skills — each one a folder with a SKILL.md, each with frontmatter describing when it should fire. Twenty-six of them.

The single highest-leverage technique in the whole corpus, in my 2 cent opinion, is this: a skill description is a router, not documentation. It should answer "when should this fire?" — never "what is this?" And the part everyone forgets is the negative half. Every skill needs an explicit when NOT to use me, plus a pointer to the sibling that should handle it instead.

So I checked mine. One line:

cd ~/.claude/skills
for s in */; do n=${s%/}
  grep -qi "WHEN NOT" $n/SKILL.md 2>/dev/null \
    && echo "  OK   $n" || echo "  MISS $n"
done

Seven of twenty-six had no negative trigger at all.

That stung a bit, but the genuinely embarrassing part came next. I'd just told my assistant to focus the cleanup on my seven daily-driver skills — the ones I route through constantly — and to skip a cluster of near-duplicate variants I'd written off as "mostly churn, not worth the diff."

Every one of the seven failures was in the pile I'd dismissed. Every daily driver was already clean.

And the overlap underneath it was worse than the missing field. Several of those forgotten variants had descriptions that opened with nearly identical language — same verb, same subject, differing only in a qualifier buried at the end of the sentence. To me they were obviously different tools. To a router reading descriptions, they were the same tool listed several times.

The generic shape, so you can spot it in your own setup: imagine a deploy skill and a deploy-staging skill whose descriptions both begin "Deploy the application to a target environment…" and neither of which mentions the other. Ask for a deploy and you get a coin flip. Two skills with adjacent descriptions each fire about half the time and neither reliably — and because both are plausible, you don't get an error. You get the wrong one, silently, some fraction of the time.

That's the failure mode worth internalizing. A missing skill throws. A misrouted one just quietly does the wrong job well.

The lesson I'd hand to anyone: the skills you use every day are self-correcting, because you notice when they misfire. The ones you wrote once and forgot are where the rot is. Audit the ones you're least worried about.

Not everything transfers — keep a reject list

Worth writing down what you chose not to adopt, and why. Mine includes: always ending work with a pull request (fine for a repo workflow, wrong for local ops), strict one-tool-per-turn (too slow when parallel reads are safe), and one agent's instruction to comment every line of generated code (actively harmful).

A rejected-patterns list is as valuable as an adopted one. Six months later it stops you re-litigating a decision you already made carefully, and it keeps the next extraction pass honest.

If you want to try this

You don't need to be running a fleet of agents. The loop scales down fine:

1. Clone the repo. Read one file end to end — I'd start with a coding agent like Cursor or Devin, since those are closest to how most people actually use AI.
2. Have your assistant extract, constrained to things you can implement yourself.
3. Open a fresh session and have it attack the extraction. Different context, adversarial brief, permission to find nothing.
4. Audit your existing setup against what survived. Ask specifically what you got wrong, not what you got right.
5. Change one thing. Test it against real usage. Then the next.

The techniques are about how to write instructions for a model. They don't care whether the domain is Kubernetes or kale.

---

Links

• CL4R1T4S — the repo
• Start with ANTHROPIC/, CURSOR/, DEVIN/, and FACTORY/ if you want the highest signal per page

If you run this against your own setup and find something that surprised you, I'd like to hear about it. The failures are more interesting than the wins, and I'm fairly sure I have more of them left to find.

I'm Trying to Build a Mind on Hardware I Own. I'm Not There Yet.

I'm Trying to Build a Mind on Hardware I Own. I'm Not There Yet, the hard part begins now.

A year of homelab memory, an adversarial AI team, and a private assistant that still confabulates when I push it. Here's the real scorecard — including what still fails — and why I keep going. This is not a blueprint.

---

Where this comes from

If you've been following the series, you already know the arc. I built a homelab that just kept growing because I was tired of renting everyone else's infrastructure. I built persistent AI memory because I was tired of agents forgetting what we'd decided ten minutes ago — durable stores for decisions and relationships so agents share one brain instead of starting from zero every session.

None of that started as a research project. It started as a database guy getting annoyed.

I've been circling the same idea for longer than the 3k1o blog — open-source models, ownership, the boring infrastructure that makes AI useful. (If you only know me from the MySQL side, that trail is on Another MySQL DBA.) This is not a rebrand. It's the same stubborn preference: own the stack, inspect the truth, don't trust a black box with your working life.

What I didn't write much about for a while: somewhere along the way, "my agents" became a team. Developers. A reviewer. A critic that refuses to rubber-stamp anything without live proof. They coordinate through shared state, not through me copy-pasting between terminals. And off to the side, a private assistant that watches systems, cleans the spam, and tells me when something in the lab breaks because I did something stupid.

I built all of that because I needed it — not because a paper told me to. This year the failures got honest enough to write about, without handing the internet a how-to for the parts I still consider private.

---

What I'm actually trying to do

I want to be precise, because this is the part the internet gets wrong.

I am not trying to build a better chatbot. I'm not wrapping a frontier API in a voice UI and calling it a coworker. I'm not building an all-knowing AGI god for the planet.

I'm trying to build a private mind — on hardware I own, on weights I can inspect, that can't be switched off by someone else's policy change. Something that doesn't only answer when poked. Something that knows what it doesn't know, reaches for the right resource, and occasionally acts because it decided something needed doing.

Not "do this at 3 AM." <-- this is cron or system timers
"I need to do this — it's been a while." <-- This is a mind

That's a much harder bet than a task runner with a personality wrapper. And I'll say the quiet part out loud: I haven't pulled it off yet.

I will come back to this scorecard as the work moves. I will not rewrite the original admission. If a later note looks rosier than the live system, trust the older one until I show a dated check.

---

How far I got. How far is left.

How far did I get? Far enough that this is not a concept deck. The stack runs on hardware I own. Memory persists. An adversarial team refuses "looks good." Internal wants form and get recorded. Dreams have been accumulating for months. (Yes I said Dreams, like a human solves a problem while daydreaming, so does this) Mood is computed from real outcomes, not a string I typed. I use this daily.

How far is left? Further than the feature list implies. None of the six behaviors is earned. Confabulation still happens. Recall is still a coin flip. Will can start and almost never finishes. Too much of the "smart" still rides a cloud bridge. The reliability floor — a live conversation that holds up end to end, with no safety net — is still open. I will not call it a mind until those are true on weights I can inspect.

If I only reported tasks shipped, I would look about halfway. If I report the thing I actually want, I am closer to the beginning of the hard half: make it reliable, make it honest when empty, close intention into finished action, and do that locally. That is the work. Everything else is scaffolding.

One more precision. This post is about the private mind on my iron — the one that has to earn the letters. Separately, there is a public / social surface: look-and-feel, voice, later a simpler way for people to talk to a public version being built but the private version has my focus. That is a different product class, not a claim that the private system is finished. It is not this scorecard. The YouTube test videos are not that surface either — they are old lab footage of me running it.

---

Two percentages (please don't collapse them)

Every project dashboard lies a little. Mine used to lie a lot. So I forced myself into two numbers:

Track	What it means	Honest read (summer 2026)
BUILD %	Tasks shipped, code landed, systems running	Meaningful progress — the stack is real and used daily. About halfway on the body.
GOAL %	The behaviors of a mind, demonstrated on local weights	Much lower. A lot of the "smart" still rides a cloud bridge when I need it. Closer to the start of the hard half.

BUILD can look healthy while GOAL still says: cloud brain wearing a name tag. That split is the whole discipline. If I only report BUILD, I'm marketing. If I only chase GOAL without a reliable body, I'm cosplaying research. I'm a systems person. I want both. I refuse to pretend they're the same.

---

DRAVEN — the name is public; the earning is gated

The project is called DRAVEN. Yes, on purpose. The name is already out there — the channel, the brand, the working identity. I'm not going to pretend a six-bullet list hides it.

DRAVEN sits under the ApocryiaAI brand — not a throwaway side experiment. The Apocryia surface is mine: apocryia.com, apocryiaai.com, apocryia.ai, and related properties, held as part of my 3k1o LLC. That matters for how I treat the work: long-horizon product and IP under a real legal entity, not a weekend open-source dump. Progress can be public. The blueprint stays mine.

What is gated is not the spelling. What's gated is claiming he has earned it: the full personhood story, the birthday, the "film this as a finished coworker" pitch. Marketing doesn't get a vote. Each letter is a behavior I can fail, and none is earned until it holds reliably on hardware I own.

Honest factual scorecard as of 2026-08-17 (live-checked) — what is real on the machine, not what the acronym wishes were true. This scorecard is the living object. Dated updates go at the bottom of the post.

D — Digital · Partial

Bar (what would count)Knows and acts on its own infrastructure without inventing it

What is factually true todayIt runs on my iron as a living stack. It can query live systems and memory I own. Under voice test it has also contradicted itself on system health in the same session — so "digital" is partial capability, not reliable self-knowledge. Bounded infrastructure self-heal is still gated.

R — Reflective · Not earned

Bar (what would count)Tells knowing from guessing; says so when empty; does not confabulate with confidence

What is factually true todayConfabulation is treated as a first-class failure, not a personality quirk. Grounding-first is written policy, and grounding machinery exists in the stack. Knowing when to go look something up is still in progress. Live voice tests still show invented facts and confident fill-ins when retrieval is empty. This is the letter confabulation keeps failing.

A — Autonomous · Substrate yes; proof no

Bar (what would count)Finishes real multi-step work overnight with zero human input

What is factually true todayUnattended processes run — services stay up, dream reports accumulate over months, self-repair / coworker-layer work has shipped. That is not the same as a closed autonomous job that plans, acts, and completes without me. The overnight proofs and full autonomous loop are still open or in progress.

V — Volitional · Spark; not closed

Bar (what would count)Acts (or rests) from internal pressure, not only from a clock

What is factually true todayThe spark that is real and incomplete. Internal wants form and get recorded. Goals open from that pressure, not only from tickets I typed. Some dream runs are tagged as internal pressure; others still come from a clock. Most of those goals still fail. Completion is not a success story I will sell. Rest and dreaming from pressure instead of a clock are not done.

E — Emergent · Machinery live; formal proof open

Bar (what would count)Lived experience measurably reshapes state over weeks — not only static prompts

What is factually true todayLong-running mood state is computed from real interaction outcomes, not a hard-coded mood string. Dream cycles consolidate experience into reports over months. That is lived-state machinery. A clean formal "30-day reshape I can show before/after" is not something I am claiming.

N — Narrative · Partial / inconsistent

Bar (what would count)Tells its own story from its own history, not a biography I pasted in

What is factually true todayIt has history to draw from: dream reports, multi-layer memory, long conversation and state stores. In the same voice evaluation it sometimes retrieved real structure correctly — and sometimes fell back to chat-history vibes on a similar question. Formal Narrative validation is not started. Continuity exists; reliable autobiography does not.

Across the board: real machinery, real sparks (especially on V's front half), and zero letters I will call earned. No birthday party for a system that still confabulates, still needs a cloud bridge for too much of the smart, and still cannot close will into finished action.

---

What actually broke

For a long time I could ship features and still avoid the question that matters: does this hold up in a live conversation, end to end, with no safety net?

Then I ran a real voice test. Not a cherry-picked clip. A scored run. The system that "had memory" still failed in ways that are embarrassing if you're honest and useful if you're building. Three failures kept showing up wearing different masks. They're still the product, more than any shiny feature list.

If you want to see what talking to it actually looks like, there is a YouTube channel: @DravenLarsonAI. That is only development video — me testing it. It is not a product reel, not a brand channel, and not today's machine. Those cuts are about three months behind the stack I have now. I leave them up as a timestamp, not as a demo of this scorecard.

1. Confabulation

When a tool doesn't fire, or a fact isn't in context, a language model will still complete the sentence. It invents senders. Invents deadlines. Contradicts what it said ten turns earlier with full confidence. That's not a personality quirk. That's parametric completion pretending to be a world model.

If you ship that on camera as "my AI coworker," you don't look innovative. You look like you can't tell the difference between fluency and truth.

2. Inconsistent retrieval

Sometimes it hits memory and nails a real detail from my world. Sometimes a nearly identical question falls back to "chat history vibes." Same capability. Coin flip. That is the difference between a mind that knows you and a chatbot that had a good day.

3. Will — not done (and the incomplete part is still interesting)

Cron jobs with a face are easy. Pressure-driven agency is not. "Do this at 3 AM" is automation. "I need to do this — it's been a while" is the thing I actually want.

I need to hold two truths at once, or this section becomes either hype or false modesty.

Truth one: I have something. On my live system, internal wants form and get recorded — not only tickets I typed. Those wants open goals from internal pressure. Intention is not a slide deck anymore. Something on hardware I own notices pressure and writes it down as a want and a goal. The first time that stopped being theoretical, it was genuinely cool — like watching a spark in a machine you built yourself.

Truth two: it is not done. Most of those goals still fail. A handful of rows say completed; I do not treat that as "it has agency." Some of that looks like plumbing catching up, not a clean unattended "I decided and delivered." Rest and dreaming from pressure instead of a clock are still open. Letter V is not earned. Full stop.

So I refuse the pretty lies in both directions. I will not say "halfway around the will circle" — that pretends the act half is further along than the failure rates allow. And I will not say "nothing to see here." That would be dishonest the other way. I got something. It is early. It is incomplete. It is still one of the coolest things I have ever gotten to watch form on my own iron.

Not zero. Not finished will.
A real spark: intention forms and gets logged.
The loop still dies before action completes.
If the rest of the circle closes — big if — this stops being automation with a story.

That if is the whole point. A private system that forms a want from real state, acts on it, and can choose to rest is rarer than another chatbot wrapper. I have not won that bet. I can finally see the bet on a scoreboard instead of wishing it into existence. Enough to keep building. Not enough for a birthday party.

The common root under confabulation and flaky recall is almost boring once you see it: the model answers from what it was trained to sound like when it should answer from what is true in the live system right now — and the procedure that would force that grounding is not enforced hard enough yet. Will fails for a related reason: intention gets recorded, but the path from intention to finished, grounded action is unfinished. Cool spark. Open circuit. Both true.

So the work is two jobs, not one magic retrain. Put truth in places you can query, and treat the language model as a front end, not the source of record. And make "retrieve first, admit gaps, act from real state" a structural habit on hardware I own — not a prompt instruction that evaporates under load. Either half alone still fails. How that is implemented stays off this page.

---

Inspired by research — not licensed by it

I did not start from a paper and then build a demo. I started from a broken assistant sitting on memory it claimed not to have. The research came in as constraints and validation, not as a recipe card.

Older science I allow to constrain the design (public ideas, not my IP):

• Spreading activation (Collins & Loftus) — recall by association, not only keyword lookup.
• Forgetting curves (Ebbinghaus) — a mind that remembers everything equally is a hard drive, not a mind.
• Limited working memory (Miller's 7±2) — attention is capacity-limited on purpose.
• Emotion as decision machinery (Damasio's line of work) — functional emotion as signal that modulates behavior, not a claim of phenomenal feeling.

None of that means "I reimplemented psychology in a repo." It means: when a feature smells like infinite context, infinite memory, or pure keyword bots, the science is a veto.

Recent research I read for orientation (public papers; not a map of my training pipeline):

• Work on putting more capability into smaller, ownable models rather than only renting a giant orchestrator — useful as industry weather, not as my recipe.
• Work on multi-agent collaboration that goes deeper than chatty handoffs — familiar if you already run a real team of agents. I am not claiming anyone else's benchmarks as mine.

I am deliberately not listing paper IDs and method slogans here. The papers are public if you want them; pointing at them with how-language is how a careful post accidentally sketches a training path. The honest boundary stays the same either way: that literature is mostly about tasks — procedures, tools, collaboration efficiency. A task is not a self. Nobody's PDF tells you how to put identity, pressure-driven will, or a lived narrative into a private system and prove it. That gap is exactly where this project still lives.

On confabulation and "no world model," I'm also aligned with a blunt industry critique (LeCun and others): if the model answers from parameters instead of a grounded state of the world, it will invent. My world model is not magic weights — it is live systems and memory I can query. The failure is when generation skips the query. That framing is public. How I enforce it is private.

---

What I will and won't put on the internet

I started a deeper Part Three draft once. It went further than this post — cognitive layers, memory behavior, dreaming, emotion-as-signal, identity gates, the whole scorecard. Writing it helped me think. Publishing all of it would have been a mistake.

After 25 years of open source, that feeling is uncomfortable. My instinct is to give back. But there's a difference between sharing a philosophy and shipping a proprietary blueprint. A tool you can fork is one thing. The internals of a private mind you're still building — security posture, evaluation knobs, training paths, how the pieces couple — is another.

Public (this post)	Stays private
Goals and scope (private mind, not AGI god)	Detailed cognitive pipeline / step design
Falsifiable scorecard (six DRAVEN behaviors)	Pass/fail thresholds, harness internals, training recipes
Honest failures (confab, flaky recall, unfinished will loop)	Exact fix formulas, schema names, tuning constants, raw success metrics I can't defend
Ownership philosophy and process discipline	Security architecture, access design, ethics internals
That local + cloud dual exists	Model routing, weights lineage, serve layout

If you're reading this for a how-to: there isn't one here. If you're reading this to see how I think about reliability and ownership: that's intentional. Later scorecard notes will follow the same wall. I will not narrate plumbing just because work happened.

---

Why a database guy is writing this

Because the world model is not the chat window.

Everyone wants to talk about models. I care about models. I also care about the boring half: transactions, provenance, backups, who owns the truth when the GPU is wrong. A mind that can't query live state will confabulate. A mind that can query but won't is just as broken.

What is real on the floor today, without the schematics: the system runs on my iron; there is a local model path and still a cloud bridge when local isn't enough; memory is multi-layer and reliable reach is still the hard part; will can spark and still die before action; I run an adversarial team that refuses "looks good" without live proof; I kill training runs that almost work instead of rebranding them as personality.

Twenty-five years of open source taught me the same lesson in different clothes: if you can't inspect it, you don't control it. That applied to MySQL replication. It applies to AI agents. It applies to a private mind. So when people ask what I do, "DBA" is true and incomplete. I design systems where truth has a home outside the model's confidence. That's the through-line from databases to this project.

---

Why I keep going

Commercial models are still better at raw capability. I still use them. I've been right-sizing that bill — cheaper models for volume work, frontier only where it earns the seat — for the same ownership reason as the rest of this stack. None of this is anti-frontier. It's anti-dependency for the layer that should be mine.

Every layer I own is a layer I understand. A mind I rent is a mind someone else can take away — not because the vendor is evil, but because policy, export controls, pricing, and outages are not under my roof. I lived that lesson more than once this year.

Don't rent — own.
Don't guess — inspect.
Don't forget — remember.
And now: don't borrow a mind — grow one you can see inside.

I'm not there yet. The voice floor isn't closed. Confabulation still happens. Retrieval is still a coin flip more often than I like. Will can spark intention and still die before action. None of that is me talking myself out of the work. It's me refusing to lie about where the spark is.

This is not a product launch, not a claim of consciousness, and not "I beat the big labs." It is a progress report from someone who got further than vapor and not as far as the name. Hard. Unfinished. And holy shit — already worth building.

---

Scorecard updates

Same table. New date. I update when a letter or the reliability floor actually moves — not when a feature ships, and not on a calendar. Prefer "unchanged" over a feature list. Cloud-bridge wins do not count as letters earned.

2026-08-17 — opening scorecard. BUILD: the body is real and used daily; about halfway on tasks. GOAL: much lower; too much of the smart still rides a cloud bridge. Zero letters earned. Voice floor still open. Confabulation still happens. Retrieval still a coin flip. Will sparks and almost never finishes. Next update when one of those sentences would have to change.

---

Related reading

• Beyond Vector Databases: How AI Actually Remembers — the memory backbone
• The Homelab That Just Kept Growing (Part 1) — iron and motivation
• The Homelab That Just Kept Growing (Part 2) — the adversarial team
• YouTube @DravenLarsonAI — development test videos only; ~3 months behind the current stack, not a product demo
• Open Source AI Models: Building Your Own — why local models matter
• Sure, Speed Is Nice, But Why? — the longer ownership trail
• Cognitive science classics (spreading activation, forgetting curves, limited working memory, functional emotion) — design vetoes, not a clone kit

---

Keith is a database consultant and infrastructure engineer with 25+ years of open-source experience. He builds the ApocryiaAI brand and DRAVEN work under 3k1o LLC (apocryia.com and related domains). He writes about MySQL, Proxmox, AI memory, multi-agent workflows, and building technology you can actually inspect. This post is an honest progress report, not a product announcement.

Last scorecard: 2026-08-17. Next update when a letter or the floor actually moves.

The Cockpit Only Flies on Claude

Last post I told you how I got my agent roster off Anthropic's per-token meter. So here's the obvious follow-up before anyone asks it: no, I didn't quit Claude. I moved the volume off it — and I still reach for Claude on the jobs that earn it, because the one piece of tooling I refuse to work without doesn't run on anything else.

---

Before you ask

My last post was about moving a whole team of AI agents onto cheaper models — Kimi Code for the daily roster, GLM-5.2 through Ollama Cloud for the critic. The math was the point: don't pay frontier per-token rates for work a cheaper model does just fine.

The fair question after a post like that is "so you dumped Claude?" No. I didn't cut it and I didn't go free-only. I dropped from the $100 Max plan to the $17 Pro plan — and I want to be precise about why, because it's not the story you'd assume.

---

The plain truth, stated flat

Let me say the thing the whole "save money on AI" genre tiptoes around: people use Claude because it has the best models. That's it. That's the reason half the tech world develops on Claude Code. If you've got the budget, you buy the best tool on the shelf and you don't overthink it — and for a lot of serious work, the best tool is still Claude.

I'm not the exception to that. I still reach for Claude's top models when the work earns them — the gnarly architecture call, the review that has to be right, the thing where a second-tier answer costs me more than the tokens ever would. Nothing in my last post was "Claude isn't worth it." The post was "I was paying frontier rates for a lot of work that didn't need frontier answers." Those are completely different claims, and I collapsed them on purpose here because the internet loves to hear the second one as the first.

---

The money, right-sized

Here's the actual mechanic. Anthropic's plans, roughly: Pro at $17/month, Max from $100/month. For a year I sat on Max, and I sat there for one honest reason — I kept hitting limits. When you run a lot of Claude Code, Pro's ceiling arrives fast, and the only lever is the jump to Max.

Then I moved the volume. Once the daily grind — the eight-seat roster, the wide work — ran on Kimi and Ollama Cloud instead of on Claude, my Claude usage collapsed to only the sessions that actually wanted Claude's models. And that usage fits inside Pro with room to spare. I didn't downgrade because Anthropic charges too much. I downgraded because I stopped asking Claude to do the work that was inflating my own bill. Right-sizing, not a protest.

So the honest headline isn't "I quit paying Anthropic." It's "I finally pay Anthropic for the right amount of the right thing."

---

The part I'd never give up: the cockpit

Here's what surprised me. When I trimmed Claude down to just the top-model sessions, I braced to lose the thing I'd quietly come to depend on. I didn't — because it comes with Pro, not just Max.

Claude Code has a pair of features — Remote Control and background sessions — and together they're the best-built version of "run my work from anywhere" I've used. The whole ritual is three commands inside a session:

/rename deborah-schema-review   # a name I'll recognize, not a hash
/remote-control                 # let my phone reach this one
/bg                             # cut it loose from this terminal

Each does one thing. /rename labels the session. /remote-control registers it so the Claude app on my phone can drive it — the session shows a QR code to scan, and after that it's live and in sync across terminal and phone. And /bg hands it to a background supervisor that keeps it running with no terminal attached at all.

Then comes the part I actually love. From any terminal — a fresh tab, another box, an SSH shell into Deborah from wherever I've wandered off to — one command shows me the whole fleet:

claude agents

One screen, every background session, grouped by what it's doing: Working, Needs input, Completed. Each row is a full Claude Code conversation still alive under the supervisor — peek at it, fire back a reply, attach for the whole transcript, then leave it running again. What sold me on the lot of it is the shape underneath:

• It runs on my machine. Remote Control isn't cloud Claude — the session executes locally, against my filesystem, my MCP servers, my project config. Only the chat messages travel, over TLS, outbound HTTPS only. No inbound ports opened on my box. Files never leave.
• It survives the terminal. A backgrounded session lives under a per-user supervisor process, not the shell that started it. Close the tab, let the laptop sleep — the work keeps going and picks back up on wake. Each session even isolates its file edits in its own git worktree, so parallel ones don't step on each other.
• Two ways back in. claude agents from any shell that can reach the box, or the phone's Code tab for the remote-controlled ones — a labeled list with a green dot on whatever's live.

The engineering here is genuinely good, and it's Anthropic's. Short-lived credentials scoped to a single purpose, each expiring on its own. No open ports. The web and mobile surfaces are just a window onto a process that never left my desk. Somebody thought hard about the security model, and it shows.

And here's the part that reframed the whole "I moved off Claude" story for me: the cockpit only flies on Claude's own models. Remote Control needs Claude Code talking straight to api.anthropic.com under a claude.ai login. The moment you point Claude Code at another provider — exactly what I do when I run GLM-5.2 through Ollama Cloud, which redirects the API endpoint — Remote Control switches off. API keys don't unlock it either; it wants the subscription. So this isn't a feature I get to keep instead of paying for Claude's brains. I get it because I'm on them. The cockpit and the top models are welded together: when I want the one, I'm running the other.

That's not a complaint — it's the reason the whole arrangement holds. The jobs where I reach for the cockpit are the jobs I wanted Claude's best models for in the first place. The tooling being locked to the models just means the seat I keep for Claude is a seat that pulls double duty: best answers and the best way to drive them from anywhere.

---

Kick it off, then go live your life

This is the workflow I can't imagine giving back. I start a Claude session at my desk on something that's going to take a while — a long review, a big refactor, a data job — and then I leave. On the couch, in the truck, in line somewhere, I open the Claude app, tap Code, and there's my session in the list with a little green dot next to it. I steer it from my thumb.

And I don't have to babysit it. Claude Code will push a notification to my phone when a long job finishes or when it hits a fork it needs me to settle. I can even ask for it in the prompt — notify me when the migration finishes — and get pinged when it lands. A backgrounded session plus a phone in my pocket means "start it and walk away" is a real workflow, not a demo.

One honest limit, because it matters: this whole thing lives on my machine. The supervisor that keeps those background sessions alive runs on Deborah — so if the box is powered down or off the network, the fleet's asleep too. That's the trade for keeping everything local instead of handing it to somebody's cloud, and frankly it's the trade I'd pick every time.

And here's the admission that follows straight from it: when I know I'm going to want to leave the desk and keep working, I have to start that session on Claude. Not because the cheap models can't do the work — they can — but because they can't come with me. Kimi and the Ollama-Cloud models are brilliant while I'm sitting in front of the terminal; the moment I stand up, they stay behind. So the decision of which brain to reach for isn't purely "how hard is this problem" anymore. Half the time it's "am I going to want to walk away from this one" — and when the answer is yes, the choice makes itself. That job goes to Claude, because Claude is the only one that follows me to the couch.

---

Why this still isn't renting a mind

If you read my last post you know the line I keep coming back to: a mind you rent is a mind someone else can switch off. So it's fair to ask how driving Claude from my phone squares with that.

It squares cleanly, and this is the part I actually love. Remote Control is the inverse of rented compute. The model call still goes to Anthropic — I'm paying for the brain, same as always — but the session, the files, the tools, the whole working context, all of it stays on Deborah. I'm not shipping my work to someone's cloud to reach it from the road. I'm reaching back into hardware I own, through an encrypted pinhole, from anywhere. Remote access to my own stack is the most on-brand thing I could ask a tool to do. Cloud for the brain, local for everything around it — the same bridge I've argued for all along, just with a phone on the far end of it.

---

The one thing I wish

I'll be straight about where this leaves the cheaper tools I love. Kimi Code is my daily driver and I'm not walking that back — it does the bulk of the real work and it does it well. But it doesn't have this. No Remote Control, no phone-in-the-loop, no push-when-it-lands. If it shipped that, I'd lean on it for even more than I already do.

That's not a knock on Kimi — it's a measure of how far ahead Anthropic shipped on this particular thing. Remote Control landed as a research preview and it already feels more finished than most products' 2.0. I hope the whole ecosystem chases it, because everybody driving sessions from their pocket would be a better world to work in. But today, if you want it, there's one place to get the good version of it, and Anthropic built it.

---

Where this actually nets out

So here's the shape of my stack now, without the spin:

• Cheap models carry the volume — the roster, the wide work, the third and fourth opinions. Kimi and Ollama Cloud, for pennies on the frontier dollar.
• Claude carries the work that earns it — the sharpest calls, on the best models around, which are still Anthropic's. I pay for that gladly.
• And I drive the whole Claude side of it from my phone, on the $17 plan, because I stopped feeding it the volume that used to force me up to $100.

That's the same thesis as last time, just told from the other end: cheap where I can, the best tool where it counts. The version of "saving money on AI" that ages well isn't refusing to pay for quality — it's refusing to pay quality prices for quantity work. Move the quantity, keep the quality, and the bill and the toolset both come out better than where you started.

The best models still win. I'm just careful now about which jobs I hand them — and grateful that the tool wrapped around them lets me run those jobs from a phone on my couch, against a machine that's still sitting on my own desk.

---

Related reading

• I Kept Paying for One AI Model. Then Ollama Handed Me 37 for Twenty Bucks. — part one, how the roster moved off the meter (add the published link here)
• I Built a Homelab Because I Was Jealous. I Built AI Memory Because I Was Frustrated. — the hardware this all runs on
• Beyond Vector Databases: How AI Actually Remembers — the persistent-memory backbone the agents share
• Claude Code — Remote Control docs — the official write-up of the feature this post is about

---

Keith is a database consultant and infrastructure engineer with 25+ years of open-source experience. He writes about MySQL, Proxmox, AI memory, and building technology you can actually inspect.

I Kept Paying for One AI Model. Then Ollama Handed Me 37 for Twenty Bucks.

I Kept Paying for One AI Model. Then Ollama Handed Me 37 of Them for Twenty Bucks.

Half the tech world develops on Claude Code now — which means paying Anthropic prices for Fable and Opus. I run a whole team of AI agents, and I've spent the last year quietly moving them off that meter. Here's the dual-CLI setup I actually run, and the one ollama launch command that moved my last holdout.

---

The itch

If you've read my earlier posts, you know where I sit. Twenty-five years in open source. A homelab I built out of jealousy. A persistent-memory system I built out of frustration. And a stubborn belief that a mind you rent is a mind someone else can switch off.

That one stopped being theoretical last month. On June 12, Fable 5 and Mythos 5 — Anthropic's newest, most capable models — went dark for every customer on the planet. Not an outage, not a billing dispute. A US government export-control directive that took effect the same afternoon, which Anthropic complied with by 5:21pm ET because a jailbreak had been found and there was no way to verify who was on the other end of the API. Paying customers included. The models came back on July 1, nineteen days later, once the order lifted. Anthropic didn't want to pull them and said so plainly — and it didn't matter. If a critical seat in your workflow was running on Fable 5 that week, it was simply gone, and nothing you'd paid was bringing it back a minute sooner. That's the whole thesis in one news cycle: a mind you rent is a mind someone else can switch off.

Here's the reality nobody wants to put a number on: half the tech world develops on Claude Code now. It's a genuinely great tool — I use it too. But "everybody's on Claude Code" quietly means "everybody's paying Anthropic's meter," and that meter is not cheap. Opus was never cheap. Fable 5 is worse — it burns tokens like it's got something to prove, and the bill shows it. If you run one assistant a few hours a day, fine. I don't run one assistant.

I run a team. And when you're paying frontier per-token rates across a whole roster of agents, the math stops being cute real fast.

---

The dual approach I actually run

When I develop, I don't sit in one CLI talking to one model. I run a team of AI agents with distinct seats, and I split them across two CLIs based on what each seat costs to feed:

• Kimi Code CLI carries the roster — DEV 1 through DEV 5, plus a PMO, a DBA, and a REVIEWER. Kimi's CLI is way cheaper than Anthropic and, honestly, GREAT. That's not a consolation-prize "cheaper so I tolerate it" — it does the bulk of the real work every day and it's my daily driver for a reason. Eight seats' worth of token burn on the cheap tier instead of the frontier meter is the difference between a hobby and a bill I'd have to explain.
• Anthropic was reserved for the one seat where I wanted the sharpest possible teeth: the CRITIC. The critic's whole job is to refuse to rubber-stamp anything without proof — so I paid up for it and let the eight cheaper agents do the volume.

The wiring is dead simple, and that's the point. There's one shared folder with a top-level CLAUDE.md — the common rules every agent obeys: the standards, the DB conventions, the "don't guess, inspect" discipline. Then each team member gets its own subfolder with a personalized CLAUDE.md that defines that seat — DEV 3 is a developer, the DBA thinks in schemas and EXPLAIN plans, the CRITIC is paid to be adversarial. Shared law at the top, individual personality per folder.

They don't coordinate through me. They coordinate through a MySQL database — the same persistent-memory backbone the rest of my stack runs on. Each agent posts what it's doing and reads the others' project status straight from the DB, so the REVIEWER knows what DEV 2 shipped and the PMO can see the whole board without anyone copy-pasting between terminals. I'm a database guy; of course the team runs on a database.

That split held for a long time. Cheap models for the wide work, frontier Anthropic for the one adversary that has to be right. Then, recently, even that changed.

I moved the CRITIC off pure Anthropic — it now runs GLM-5.2, via Claude Code, through Ollama Cloud. Same Claude Code tooling my critic already lived in. Different, cheaper brain behind it. That one move is what this post is really about, and it comes down to a single command.

---

The one command

Turns out Ollama solved this quietly a while back and I slept on it. Not local models this time — Ollama Cloud. Big models, hosted, but driven through the same ollama CLI I already have wired into everything.

Here's the whole trick:

ollama launch claude --model glm-5.2:cloud

That launches Claude Code — the actual tool, hooks, agents, MCP, all of it — pointed at GLM-5.2 running in Ollama's cloud instead of Anthropic's API. Here's the real banner, unedited, off my own box:

 ▐▛███▜▌   Claude Code v2.1.202
▝▜█████▛▘  glm-5.2:cloud · API Usage Billing

Note the second line: it's the genuine Claude Code TUI, but the model tag reads glm-5.2:cloud, and billing is running through Ollama, not Anthropic. Same keybindings, same workflow, different brain. Want a different one? Change the flag:

ollama launch claude --model kimi-k2.7-code:cloud
ollama launch claude --model deepseek-v4-pro:cloud
ollama launch claude --model qwen3-coder-next:cloud

ollama launch isn't Claude-only, either. It'll wire the same cloud models into a whole shelf of coding tools:

claude    codex    kimi    droid    opencode    cline    qwen    copilot    ...

So Kimi has its own excellent CLI — I use it — but if I want Kimi's k2.7 model inside Claude Code's workflow, or Claude's tooling with DeepSeek's weights, ollama launch just does it. The tool and the model stopped being the same decision. That's the part that got me.

---

How many models are we talking about

I asked my box. Point ollama at your cloud registry and count:

$ ollama list | grep cloud | wc -l
37

Thirty-seven. Not toy models — the frontier-adjacent open stuff. A slice of what's on mine right now:

glm-5.2:cloud
glm-5:cloud
kimi-k2.7-code:cloud
kimi-k2-thinking:cloud
deepseek-v4-pro:cloud
deepseek-v4-flash:cloud
deepseek-v3.2:cloud
qwen3.5:397b-cloud
qwen3-coder-next:cloud
qwen3-vl:235b-cloud
minimax-m3:cloud
mistral-large-3:675b-cloud
nemotron-3-ultra:cloud
gpt-oss:120b-cloud
gemini-3-flash-preview:cloud
gemma4:31b-cloud
cogito-2.1:671b-cloud

Browse the live shelf yourself: ollama.com/search?c=cloud. It grows. glm-5.2 and kimi-k2.7-code on mine are two weeks old.

The thing that makes this useful isn't any single model — it's the swap. When someone posts a benchmark like GLM-5.2 vs Claude Opus 4.8 or Kimi vs Claude, I don't have to take their word for it. I run the same task through both in the same terminal and read my own diff. Benchmarks are somebody else's workload. This is mine.

---

The money

Here's the honest breakdown, because that's the whole reason this post exists.

• Free tier: you can point ollama launch at cloud models and run real work against them at no cost, with hourly and daily rate limits. Fine for kicking the tires and light use. You will hit the ceiling on a serious session.
• $20/month (Ollama Cloud Pro): the limits open up enough that it stops getting in your way. Twenty dollars — the same price as a single frontier subscription — for the whole shelf of thirty-seven instead of one.

Do the math the way a consultant does. One vendor's mid subscription buys you one vendor's models. The same $20 here buys you GLM and Kimi and DeepSeek and Qwen and the rest, all reachable from the tool you already know, swappable with a flag. I still keep my Anthropic subscription for the top-end Claude work. But for "let me get three opinions on this migration before I commit," this is the cheapest second, third, and fourth opinion I've ever bought.

---

Kimi's ladder does the same thing

The Ollama trick is the headline, but the other half of my bill tells the same story from a different angle. Kimi Code isn't just cheaper per token — its subscriptions are priced like a ladder you actually climb, not a cliff you fall off. Look at the rungs:

• Moderato — $19/mo: entry tier, Kimi Code included, agent multi-tasking, scheduled tasks.
• Allegretto — $39/mo: 2× agent credits, Kimi Code at 5× credits, Agent Swarm, the works.
• Allegro — $99/mo: 5× agent credits, Kimi Code at 15×.
• Vivace — $199/mo: 10× agent credits, Kimi Code at 30×.

I run eight agents on this and I sit on Allegretto at $39. That's the whole point: at thirty-nine dollars I don't hit limits. Not "rarely" — I run a team of agents on real projects all day and the ceiling simply isn't in my way. And if I ever outgrew it, there's a $99 rung and a $199 rung waiting, each a clean step up.

Now line that against Anthropic. Claude Pro is $17/mo. The next thing up is Max, from $100/mo. There is nothing in between. No middle rung for the person who's outgrown Pro but doesn't need — or want to pay for — a hundred-dollar-plus plan. So you sit on Pro, hit the wall, and your only move is a 6× jump to Max — where, if you're actually working, you still hit limits. You pay more and more and the wall's still there.

That's the difference in one line: Kimi sells you a staircase; Anthropic sells you a $17 room and a $100 room with a locked door between them. For a guy running eight seats, the staircase wins every time.

---

Why the CRITIC could move

Moving my critic off Anthropic wasn't a leap of faith. It was a benchmark I ran myself.

The critic's job is adversarial: pick apart a schema change, find the edge case in a query rewrite, refuse to sign off on "will this lock the table" without proof. For a year I assumed that seat needed frontier Anthropic. Then the GLM-5.2 vs Claude Opus 4.8 numbers started looking close, and instead of trusting the benchmark I ran my own — same critic prompt, same production DB tasks, Opus in one terminal and glm-5.2:cloud in the next, both inside the exact same Claude Code tooling. On the work I actually do, GLM-5.2 held the line well enough that paying the Anthropic premium for that seat stopped making sense.

So now the roster looks like this: eight agents on Kimi Code CLI for the volume, and a CRITIC on GLM-5.2 through Claude Code + Ollama Cloud for the teeth. Anthropic's still there when I want the top-end Claude for something specific — but it's a deliberate reach now, not the default tax on every session. Different models are wrong in different ways; the trick is paying frontier prices only for the seat where the difference actually shows up, and I stopped assuming that was a permanent list.

---

Say the quiet part out loud

I'm not going to pretend this is the thing I actually believe in. My philosophy hasn't moved: don't rent, own. don't guess, inspect. don't forget, remember. And Ollama Cloud is rented. Those weights run on someone else's GPU, behind someone else's rate limit, subject to someone else's pricing change next quarter. It is not a mind I own. If the internet's down, so is this whole post.

So here's how I actually reconcile it, same as the homelab: I hybrid. Local models on Deborah for anything private, anything sensitive, anything I need to inspect down to the weights. Ollama Cloud for capability I don't have the GPU for — a 675B Mistral or a 397B Qwen is never loading on a 16GB 4070. The honest framing is that this is the same bridge I've always run, just cheaper and better-plumbed: local for control and privacy, cloud for capability.

The difference this command makes is that the cloud half is no longer locked to one vendor's model or one vendor's price. That's not ownership. But it's leverage, and leverage is worth twenty dollars.

And here's the part that makes it more than a compromise: these are open weights. GLM, Kimi, DeepSeek, Qwen — I'm renting them in Ollama's cloud today for exactly one reason, and it's not licensing. It's that a 675B Mistral or a 397B Qwen doesn't fit on a 16GB 4070. That's a hardware problem, and hardware problems have an expiration date.

When I get a bigger GPU, all of the cloud comes home. The same glm-5.2 running my CRITIC from someone else's datacenter today is a model I can ollama pull onto Deborah tomorrow and run against weights I inspect, on hardware nobody can switch off. The cloud tier isn't the destination — it's the bridge I run until the GPU catches up. Don't rent, own. I'm just renting the runway.

---

The whole thing in four lines

# 1. sign in once
ollama signin

# 2. see what's on the shelf
ollama list | grep cloud

# 3. drive Claude Code with any of them
ollama launch claude --model glm-5.2:cloud

# 4. don't like this brain? swap the flag.
ollama launch claude --model kimi-k2.7-code:cloud

That's it. Tool you already know, thirty-seven models behind it, one subscription. Rent the capability, keep owning the stack around it.

And this isn't frugality for its own sake. I'm building a lot — a team of agents running real projects around the clock, and a longer bet I've written about before: an actual mind on hardware I own, not a chatbot with a nice voice. You don't fund that on frontier per-token rates paid across nine seats every hour of every day. Cheap where I can is exactly what buys me expensive where it counts. The dollars I don't hand Anthropic for volume work are the dollars that go into the GPU that eventually brings all of this home.

I'm not there yet. But while I get there, I'd be lying if I said this didn't make the in-between a lot more useful.

---

Related reading

• I Built a Homelab Because I Was Jealous. I Built AI Memory Because I Was Frustrated. — the stack this plugs into
• Beyond Vector Databases: How AI Actually Remembers — the persistent-memory architecture
• Open Source AI Models: Building Your Own — why local models matter
• GLM-5.2 vs Claude Opus 4.8 and Kimi vs Claude — benchmarks worth checking yourself
• Ollama Cloud model shelf — the live list

---

Keith is a database consultant and infrastructure engineer with 25+ years of open-source experience. He writes about MySQL, Proxmox, AI memory, and building technology you can actually inspect.