DEV Community: Malik Chohra

I compared four Claude Code memory tools, and why I still keep a Second Brain

Malik Chohra — Sat, 24 Oct 2026 17:48:22 +0000

TL;DR

Four memory tools for AI coding agents, compared on where memory lives, what it costs in tokens, how hard each is to set up and change, and how stale entries get caught. gstack and Superpowers teach the AI how to work, claude-mem records what happened, ECC stores memory files and treats them as unreviewed.
A Second Brain answers a fifth way: it keeps what is true about your project right now, with a date on every fact. The free Second Brain Starter has the files to copy.

I write Code Meet AI, the newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first.

Last time, in How to build a Second Brain that stays useful, I built one from five records and a fresh-session test. Four memory tools for coding agents keep showing up on builders' feeds. Here they are side by side, and next to it.

Four ways to compare memory tools

A new AI session starts empty. Everything it knows about your project comes from what gets loaded in the first seconds.

Developers gave the AI a memory by hand long before these four existed. The best-known version was the Memory Bank: a folder of structured Markdown files that the assistant reads at the start of a session and updates as it works. Cline's documentation describes it that way. I wrote about it for Cursor in How to Enhance Cursor AI Memory Bank and about the habit itself in Give the AI a memory.

Three things made it spread:

No tooling. The memory is ordinary Markdown files, so any assistant that can read a file can use it.
Visible. You open a file and see what the AI knows about the project.
Editable and versioned. The files live in the repo, so you correct a wrong line by hand and git keeps the history.

Memory handling is more than the start of a session. The tools below are compared on where the memory lives, what loads at the start and what waits until it is asked for, what it costs in tokens, and how a wrong or old entry gets found.

gstack: a team of roles

gstack is Garry Tan's open-source pack of Markdown slash commands. Each command turns Claude Code into one member of a small team: a CEO who challenges the plan, a designer, an engineering manager, a QA tester, a release engineer.

It has about 137,000 stars and an MIT license.

You install it by cloning the repo into ~/.claude/skills/gstack and running ./setup. It needs Bun.

Memory

/learn. Lets you review, search and prune what gstack picked up about your codebase.
Design taste. A profile of what you approve and reject that fades by 5% a week.
GBrain. An optional add-on with a separate knowledge base, which the README calls the memory your agent keeps between sessions.

Superpowers: a method the AI follows

Superpowers is a skills framework and a development method by Jesse Vincent and the Prime Radiant team. It has about 304,000 stars and an MIT license.

On Claude Code you add it with /plugin install superpowers@claude-plugins-official.

Its skills trigger on their own. Before a task, the agent checks whether a skill applies: brainstorming before building, a plan before code, a review before done.

Memory

Session start. A short startup skill, called the bootstrap, is loaded at the start of each session so the agent knows the other skills exist.
Store. The README describes no memory store. What Superpowers carries from session to session is a way of working.

claude-mem: record everything, replay what matters

claude-mem is Alex Newman's plugin. It has about 103,000 stars and an Apache-2.0 license.

Install is npx claude-mem install. The installer asks you to sign in.

The README says sign-in unlocks a 30-day free trial of its hosted memory provider, and afterwards memory runs on your Anthropic plan unless you subscribe or bring your own key.

Memory

Capture. Hooks fire at six moments in a session: start, prompt, before a tool, after a tool, stop and end. They send what the agent did to a small local service.
Storage. The service compresses it with AI and stores it in SQLite, with a vector index for search (a database index that finds notes by meaning as well as by keyword). A <private> tag keeps a passage out of storage.
Replay. At the next session start, relevant past context is put back in.

ECC: memory as unreviewed files

Everything Claude Code, now at affaan-m/ECC, is Affaan Mustafa's bundle of skills, rules, hooks and memory for Claude Code, Codex and others.

It has about 288,000 stars and an MIT license.

Install is npx ecc-universal@2.2.3 setup, the pinned form the README gives, or through the plugin marketplace.

Memory

Where it lives. A Memory Vault stores plain Markdown documents, in .ecc/memory/ for a project and ~/.ecc/memory/ for you.
Session hooks. A session-start hook loads context and a session-end hook saves it. A small set of learned patterns, called instincts, is injected at the start up to a cap.
Trust. The README calls memory unreviewed context, and it says a human promotes accepted knowledge into the project's own documents.

What a Second Brain does differently

This part is my approach. Here is how I read the gap each setup leaves:

gstack. The roles are the center of its pitch and memory is the smaller part. If the AI plans without being challenged, the roles are aimed at that.
Superpowers. It teaches the AI how to build. Your project's facts still have to come from somewhere else.
claude-mem. Say you spent Monday moving a login flow from one Supabase project to another. By Thursday it can hand the new session a summary of Monday, which is a strong answer to forgetting. The summary is a history written by a model, so if Monday's plan changed on Tuesday, the history holds both and the new session has to work out which one is current.
ECC. Someone has to decide which saved note is true, and it leaves that step to you.

A Second Brain keeps current facts in plain files you own, and it makes the review step part of the system instead of leaving it open.

The shape from Article 2 is five records per project. Rules name the route the AI follows. A facts file holds current values, each with a checked date. A decisions file holds one line per choice with its reason. A roadmap holds open work with evidence. A progress log ends with a Next line.

The AI reads rules and facts first and the rest on demand. I run a fresh-session test to prove it recovers a decision from the files alone.

At the last count, on 22 October 2026, my own vault had 645 memory files, 119 skills, 41 commands and 640 session reports. It stays usable because the project records are small, dated and reviewed weekly.

The four answers side by side

Setup	Where memory lives	Loads at session start	How a stale entry gets caught
gstack	Per-project learnings, optional gbrain knowledge base	Roles load when you call them	`/learn` lets you review and prune
Superpowers	No memory store in the README	A bootstrap skill, then skills as tasks need them	Not a memory feature
claude-mem	SQLite plus a vector index, local service	Relevant past context, injected by hooks	No stale-entry check; `<private>` only keeps passages out of storage
ECC	Markdown files in `.ecc/memory/`	Hook-loaded context and a capped set of instincts	You review and promote into project docs
Second Brain	Five Markdown records per project	Rules and facts first	Checked date on every fact, weekly review

The last column is the one I weigh most, because an old entry read with confidence is the failure that costs me the most time. Each of the four rows solves a different problem.

Tokens and answer quality

Each setup spends tokens in a different place. What follows is what the READMEs say about their own design. Measured token use and answer quality are a separate test.

gstack. It ships gstack-context-bill, a read-only audit of what an installed skills tree costs in tokens: the always-on frontmatter every session pays, against the skill text that loads when you call one.
Superpowers. The startup bootstrap loads each session and skills load when a task triggers them. The README has a diagnosing skill for sessions that burn more tokens than you expect.
claude-mem. Search works in layers: a compact index first, at about 50 to 100 tokens per result, then full details only for the results you pick, at about 500 to 1,000 each. The README claims about 10 times fewer tokens from filtering first. That figure is the author's claim.
ECC. Skills load on demand and rules are always loaded, so the README says to install rules selectively. Injected instincts are capped at 6 by default, with a minimum confidence of 0.7.
Second Brain. Rules and facts load first and the rest on demand. The records stay small because each holds one kind of thing and gets reviewed.

Which one fits which problem

The AI plans without pushback. gstack's roles are built for that. Start there.
The AI skips steps or builds before it plans. Superpowers makes the steps a habit.
The AI forgets what happened last week. claude-mem replays history automatically.
You want portable memory files across tools. ECC's vault is plain Markdown.
The AI is confident about a fact that stopped being true. A dated record makes each fact's age visible. The other setups catch stale entries through manual review or pruning.

You can run more than one. A skill pack for how to work and a Second Brain for what is true is a combination I would choose before any single one of these.

Setup and personalization

The same five, compared on how much work it is to start and how much you can change.

Tool	Setup	Personalization
gstack	Clone the repo into `~/.claude/skills/gstack` and run `./setup`. It needs Bun. Team mode adds a command that commits the setup into the repo.	The commands are Markdown files and the README says to fork it and make it yours. Model choices per host are settings, and some hooks are opt-in.
Superpowers	One plugin command on Claude Code.	The README points to forking the repo for changes and gives one opt-out setting, for telemetry.
claude-mem	`npx claude-mem install`, a browser sign-in, and a local background service with its own database.	A settings file controls the AI model, worker port, data directory and what context is injected. A `<private>` tag keeps a passage out.
ECC	An `npx` command or the plugin marketplace, across several coding tools. The README warns against stacking install methods.	A `/ecc:configure-ecc` skill reconfigures it, and a setting caps how many instincts are injected. Memory has a project scope and a user scope.
Second Brain	Copy the plain Markdown files of the free Second Brain Starter. The assistant shows the setup plan before it writes anything. The initializer needs Node.js 22 or newer.	Everything it loads is a Markdown file you open and edit. The rules file decides the route, and you add the facts and decisions yourself.

The free Second Brain Starter is plain Markdown. Open it in Claude Code or Codex and type Set this up for me.

This one came from Code Meet AI, the newsletter where I write up the setups I actually run on my own projects.

Why I keep a Second Brain for Claude Code, and why you should too

Malik Chohra — Fri, 23 Oct 2026 12:44:52 +0000

TL;DR

AI forgets, cannot see what lives in your notes and calls, and answers with full confidence anyway.
The fix is a Second Brain: plain files, one record per project and one per client, that every tool and person reads before work starts. The free Second Brain Starter is where to begin.

I write Code Meet AI, the newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first.

I use a Second Brain every day: plain files that Claude Code and my other AI tools read before they start work. Counted on 22 October 2026, it holds 645 memory files, 119 skills, 41 commands and 640 session reports. This is why I have one, and why I think you should too: six places AI goes wrong across projects, and the file that fixes each.

AI started as prompting. You typed a question, it typed back, and the whole skill was in how you asked.

Then it became context engineering. Same model, but now you decide what it reads before it answers: your files, your rules, your examples.

Then came tools. With MCP the model stopped only talking. It could open your inbox, read your calendar, run a command, and react to what came back.

That is a good place to be. AI is better than it has ever been, and every week a new tool does something that looked impossible last year.

So why does it still go wrong when you have more than one project?

One thing did not come with the upgrade: a place where the project lives. The model can read whatever you point it at, but it does not know what to point at. With three or four projects it forgets what you told it last week, it cannot find the file that holds the answer, and it fills the gap with something that sounds right.

The AI forgets too

When a team forgets why a project works the way it does, we call it a communication problem. With AI the same thing happens in three ways.

It forgets. Every new chat starts from zero, so last week's work is gone.
It has no access. The answer sits in a note, a call or someone's head, and the model never sees it.
It is confident anyway. This is the one that hurts.

A person who does not know says "I do not know". The AI says the wrong thing in the same calm voice it uses when it is right. You read a clean answer, you think it is 100% true, and you have no way to check. Worse, the wrong part goes into the chat and becomes context, so the next answer builds on it. One dumb thing, said once, gets repeated as if it was settled.

You explain the same project again and again

Say it is Monday. You open a chat to get help with your app, and you spend twenty minutes saying what the product is, who it is for, what you built last week and what must be left alone. The answers are good.

On Wednesday you switch to another tool for another job, and it knows nothing. You type the whole thing again from memory, and the detail that mattered most, the one that would have stopped the bug, is the one you forget.

The easy fix is one project record. A single file at the root of the project that says what it is, who it is for, the current state and the next action. Every tool reads it before it does anything. You write the explanation once, and each chat starts where the last one stopped.

Decisions get made and then vanish

Suppose you decide to use A instead of B. A is the payment provider with the fees you can live with, and B is the one your partner liked. You agree on a call, you hang up, and nobody writes it down.

Three weeks later the AI suggests B, politely, with good reasons. Your partner says "see?", and you spend an hour on a decision you already made.

So keep a decision file. One line per decision: what you chose, what you turned down, why, who decided and the date. Write it right after the call, in the file the next session reads.

The reason is the part people drop first, and it is the part that stops the argument from coming back.

The AI reopens what you already settled

Take the other side. You did write the decision down, in a notes app, in a doc, in a chat from last month. The AI never saw it, so it treats the question as open and argues for B again.

Writing it down is half the job. The other half is telling the model it is settled. Keep a short list of closed decisions inside the project record, each with its reason, in the part that is read first. A decision with a reason attached is much harder to reopen by accident.

Context leaves with the person

This version costs money. Take one client account. The account lead knows the client was promised a faster turnaround last spring. They know the client said no to one format, and that approvals go through one person on Fridays. None of it is in the CRM, which keeps deal values, dates and activity but has no field for the promise or the reason behind it.

Then the account lead goes on holiday, or leaves. The next person meets the client without the history, and the AI helps them no more than it helps anyone else, because it cannot read what was never written.

The fix is one client record per account. It holds the brief, the dated decisions with reasons, what the client said no to, the promises made and the next action. Whoever covers the account, person or AI, reads it first. The record outlives the person.

Each tool keeps its own copy, and the copies drift

Claude, Cursor, Codex and Gemini each want their own rules file. You change a rule in one of them on Tuesday. A month later two of the four disagree, and the AI follows the old one without telling you.

Keep one rules file as the source. Give each tool a one-line file that points to it, and link one shared skills folder into each tool's own path. The copies stop existing, so they cannot drift.

Files go stale, and the AI trusts them

Last month you moved the project from Firebase to Supabase. The record still says Firebase. The AI reads it, writes for the old database with full confidence, and the result breaks in a way that looks like a bug in your own work.

A wrong file is worse than no file, because nobody doubts it. Put a last-checked date on each section, and check the record whenever the project changes: you swap a tool, a client leaves, a decision is reversed. A rule that a script can test becomes a hook, which runs at a fixed point whether the model agrees or not. A rule that needs judgement stays in the record, as a request.

What a Second Brain is, in one sentence

A Second Brain is a set of plain files, one record per project and one per client, that every AI tool and every person reads before work starts, and that gets written back after each decision. It is a folder with a discipline attached.

The layout follows ICM, the Interpretable Context Methodology: a small routing file points the AI to the one file it needs, so it does not have to load everything.

This is mine, drawn as a graph. Every dot is a note, and the lines are the links between them. When the AI starts a session, this is what it can walk through instead of starting from zero.

What to do this week

Count the repeats. For five working days, note each time you explain the same thing to an AI tool, and which tool it was. The count tells you which record to build first.
Write the decision line. After each call or chat where something gets decided, add one dated line to the project file: the decision, the reason, the owner.
Run the leave test on one account. Pick one client. Ask whether the next person could open one file and find the promises, the no's and the next action. If not, that file is your first client record.

A plain Markdown starting point for all of it is in the free Second Brain Starter. For how to sort the folders once you have a few records, see how to organise your files for AI, Episode 11 of Using AI, properly.

This one came from Code Meet AI, the newsletter where I write up the setups I actually run on my own projects.

Second brain 101: what your AI loads at session start, and what it drops

Malik Chohra — Thu, 20 Aug 2026 08:27:19 +0000

TL;DR

An operating system for your AI is one folder it reads before it works and writes back to when it learns. The folder takes an afternoon. The write-back is the part that makes it a system.
Not all of it loads. One short index file loads at session start, and a detail file gets opened only when something in the index points at it. Past 200 lines or 25 KB the rest of the index is dropped, quietly, with nothing in the transcript to tell you.
CLAUDE.md is read first and in full, and the runtime walks up the folder tree from wherever you launched. Put it one folder down and it is not there at launch. It gets read later, on demand, the first time your AI opens a file in that folder. Mine is 41,480 bytes and lives in 00-Meta/, so 8 of my 31 commands pull it in by name and the other 23 do not.
Rules are read. Hooks are run. Anything that has to happen every time, and not most times, is a hook.
The receipt after a few months of this: 465 memory notes, 474 entries in my own decision log, 454 in both places under the same filename, 441 carrying the write-back footer. I typed none of it.

This piece is from Code Meet AI, my newsletter where I document how I actually use AI to ship real products, receipts included.

AI for techies · 10. Last time I went through how to create your own commands, which is one saved job you run again by typing one word. This one is about the place all those jobs run inside.

By now you have the pieces. An instructions file. A skill or two. A command you actually use. Maybe a second agent you hand the boring half of a job to.

Each one works. None of them is broken. And you still open a new session by explaining where things are, which project, what you settled last week, why that folder is named that.

This is mine. Every dot is one file, every line is a link between two of them, and the folders down the left are the whole filing system.

the pile of parts problem

The pieces do not know about each other.

What your AI worked out on Monday is not in the file it reads on Tuesday. It found the answer, you moved on, and the answer stayed in a chat window that is closed now. Next week you ask the same question and it starts from nothing.

So you pay for the same thing twice. Once to work it out, and once to hold it in your own head well enough to say it out loud again.

A pile of good parts is not a system. What makes it a system is that the end of one session is the start of the next one.

an operating system is one folder and one loop

One folder your AI reads before it works, and writes back to when it learns.

That is the whole sentence. The folder is the easy half and you can build it in an afternoon. The loop is the thing: read, work, write back, and the next session opens on what the last one learned.

A folder is a one way trip. The loop is what sends the next session back in.

the eight parts

Most of these you already run one at a time.

The folder. Files on disk, sorted by what you are doing with them. That is all it is.
The memory. Your AI writes its own notes and keeps them in its own folder, not in yours, which is how you give it a memory. Mine holds 465 of them.
The rules. A CLAUDE.md is the file that gets read first, in full, before any work starts, and what you write down once is most of the job.
The skills. One kind of job, saved as a folder. It costs you nothing until it is used: your AI sees the name and one line about when to reach for it, and opens the body only when a job matches.
The agents. A second AI with an empty head. It does not get the main session's memory, and that is the one that catches people out. What it needs goes in the prompt you send it, or it works blind. Six of these sit in my personal agents folder.
The hooks. Rules are read, hooks are run, and this one is where I went through them properly. A hook is a small program the tool itself runs at a fixed moment, whatever the model decides. I have seven, on four moments: before a tool runs, after a tool runs, when I send a prompt, and when the session stops.
The commands. A prompt you saved in a file, so you type one word instead of ten lines.
The write-back. At the end of a session, what was learned gets written back into the folder it was read from. Nobody writes about this one, and it is the part that turns seven good pieces into a loop.

what actually loads, and what does not

This is where the tidy version is wrong, and being exact here saves you an afternoon of wondering why your AI ignored a note you can see on disk.

Pointing it at your notes folder does not mean it reads your notes.

One short index file loads at the start of every conversation. A detail file gets opened only when something in the index points at it. So the index has a budget, and it is a hard one: past 200 lines or 25 KB, the rest is dropped. Quietly. Nothing in the transcript says a word about it. Mine sits at 117 lines and 22,252 bytes, which is closer to that ceiling than I am comfortable with.

Skill bodies behave the same way. Name and trigger line up front, body on request.

Hooks sit apart from both, because a hook is the only one of the three that is not a suggestion.

The folder holds 465 files and the index is one of them, so the detail files are 464.

where your CLAUDE.md really sits

The runtime walks up the folder tree from wherever you opened the session and reads every CLAUDE.md it finds on the way. In full, before any work starts.

So placement is load-bearing. Put it where you start, not one folder down.

Mine is 41,480 bytes and it lives in 00-Meta/. There is no CLAUDE.md at the top of my vault. When I open a session at the top, that file is not loaded at launch.

It is not invisible either, and this is the part that gets stated wrong in both directions. It gets read later, on demand, the first time my AI opens a file in that folder, which is after the work has already begun. Eight of my 31 commands pull it in by name, so those eight get it up front. The other 23 do not.

If a rule has to be in the room from the first token, the file has to sit at the level you launch from. Otherwise you are relying on the work happening to walk past it.

three ways in

The effort climbs with each one.

It already does some of this. Auto memory is on by default, and any CLAUDE.md above your working folder is read in full when you launch.

You ask for it in plain words. Say "remember that". Say "add this to CLAUDE.md". Say "save that as a skill". It writes the file, in the right place, and you never have to learn the folder layout. /init will write you a first CLAUDE.md from the project you are sitting in.

You set it up so it is always there. The docs are blunt about the difference: "Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md instructions shape Claude's behavior but are not a hard enforcement layer." So anything that must happen every time is a hook. Not a line of instructions.

A rule is read. A hook is run. That is the whole difference between rows two and three.

the loop on my own disk

My /endSession command has a phase 3, and it is a few lines of plain English. New facts about how to work with me or my projects go to memory files, plus one line in the index, plus a stub in the vault's decision log.

Here is what those few lines produced.

The memory folder holds 465 notes. My own decision log holds 474. 454 of them exist in both places under the same filename, and 441 carry the same footer line saying they were written out from the memory bank.

I did not type any of that. The session that learned the thing wrote it down on the way out, and the next one opened on it.

That is the loop. The folder my AI read from is the folder it wrote to.

where to start

Do not build the whole thing. Pick the one thing you explained to your AI twice this month.

At the end of your next session, say: write that into CLAUDE.md so you have it next time. Then open a new session tomorrow and check whether it did.

If it did, you have a loop, and everything after that is filling it in.

If you would rather not start from empty, the prompt that builds the whole folder is in my guide, Build a second brain with Obsidian and Claude Code. Paste it in and it writes the files for you.

This one came from Code Meet AI, the newsletter where I write up the setups I actually run and the numbers come off my own disk. Next episode is how to keep this working once the folder gets big.

Wire AI Is Live: Beta tester open

Malik Chohra — Thu, 30 Jul 2026 16:19:58 +0000

TL;DR: Wire AI is live and early access is open. It's an AI-native growth engineer for mobile apps: your React Native app embeds an SDK, a LangGraph backend decides what to ask each user next, and deterministic code owns the routing while the model only generates content. On one live app, activation went from 69% to 93%. 15 early-access seats, 3 taken, free and installed by hand.

This article is part of my Code Meet AI newsletter: https://codemeetai.substack.com

Wire AI is live today, and early access is open.

It's the AI-native growth engineer for mobile apps: AI that replaces your growth team. It runs four versions of every step of your users' journey, live at once, and keeps what makes them stay.

On the first app it ran on, activation went from 69% to 93%.

15 seats. 3 are already gone. Free, installed by me personally, and there's no price attached because I haven't set one yet.

Below: what it does, what already shipped, what's still rough, and how to claim one of the 12 that are left.

How it works

Your users' journey has stages. They onboard, they get a plan, they hit their first real win, they get asked for a review. Wire AI runs four versions of each of those stages, live, at the same time. Users are assigned to a version and stay in it, the funnel says which version keeps more of them, and the winner gets promoted.

Then the part a testing tool doesn't do. Every finished journey feeds back in: Wire reads what happened and writes a sharper variant for the next round.

It isn't a dashboard that tells you to go run a test. It's the loop, already running.

What that looks like in your codebase

Your React Native app embeds a small SDK. When a user opens the app, the SDK talks to a backend I run, and that backend decides, one screen at a time, what to ask that specific person next. It renders as native cards. Not a webview, not a chat window bolted onto your product.

At the end it hands your app a structured plan you can save and act on, and every step streams into a funnel you can read.

So instead of writing an onboarding once and guessing for the next two years, you write a config and the AI runs it.

The part that makes it work is boring on purpose. Deterministic code controls the flow and the model only generates content. Routing is a pure function of where the session is, how many questions are left, whether the user is bailing, so the whole flow is testable without a model in the loop.

The AI writes the next question, grounded in every answer the person already gave, and writes the final plan. Everything it emits gets validated against a fixed vocabulary of components before it's allowed anywhere near a screen.

That's the difference between a generative UI demo and something you can put in front of paying users. Most AI UI demos let the model draw whatever it wants and hope. This one gives the model a small, checked job and keeps the state machine in code where it belongs.

What that gets you

A journey that adapts per user. The static onboarding asks everybody the same seven questions in the same order. Wire AI asks what follows from what the person just said, stops when it has enough, and skips what it can already infer.
Experiments that run without you. A/B/C/D variants across the journey, five stages, four arms, twenty combinations, without anybody sitting in a meeting deciding which to try next. This is the direction the product is built toward and I'll be straight about where it sits today, further down.
A funnel you can actually read. Completion, drop by step, time per screen, and the transcript of any individual session so you can read exactly what the AI asked and what the person answered. Most apps at this stage are guessing about where users give up.
You find out who your users actually are. Wire AI reads every session and hands you the patterns: what people came for, which question makes them hesitate, which wording converts. Most founders are still running on a persona doc written before launch.

Our pilot client, and what actually happened

I can't name the app, that's a client boundary I hold. What I can tell you is what it does: it helps people find spots to hang out. Live React Native app, real users, and an onboarding people were quietly dropping out of.

Here's the run, in the order it happened.

We started with an experiment, not a redesign. Three versions of the onboarding running live at the same time, users assigned stickily so nobody got a different flow on their second open, every version chasing the same goal event. Nobody sat in a room deciding which one was better.
The first read was wrong, and the loop is what caught it. One arm came back looking like a 17 point winner. At around fifty sessions that feels like a result, and it's exactly the moment a human growth team ships it and builds the next quarter on top. At scale it was worth about three and a half points. Mostly noise wearing a nice hat.
The version that actually won was the short one. The deep, thorough discovery flow lost to a fast one of about eight screens. On a flow with no real leak in it, where every individual question converts in the high nineties, length turned out to be the only lever that moved anything.
Then the part I didn't expect: we found out who the users actually were. The product context we had written assumed one kind of person, someone new to the city looking for places. The answers said something else. Younger, local, born there, social, budget conscious. My actual reaction, reading the answers: wait, these people already live here. We had spent months onboarding a user who didn't exist.
So we rewrote the messaging to the real one. New product context, questions rewritten for the person who actually shows up, one question cut completely because it was seasonal noise nobody cared about, and a guard added so the AI stops asking the same thing twice in different words.
Three learning loops in, activation had gone from 69% to 93%, and the first movement showed up inside the first week of running live.

Two honest caveats on that number, because it's the one people will quote. It's activation on one app, in one category, over one window, so it isn't a portfolio of case studies and I won't dress it up as one.

And the winning arm's completion rate moved by about thirteen points between generations of the experiment, which is a reminder that you read these numbers per run, never all-time. That lesson cost me a re-read of my own dashboard.

What already shipped

Not a landing page and a waitlist. These pieces exist and run.

The SDK is open source. wireai-rn on npm, MIT licensed, eleven built in components with validated schemas, six adapters for different model providers. Swapping providers is one environment variable, so you're not married to whoever is winning this quarter.
The transport is an open standard. The device and the backend speak Google's A2A over JSON-RPC 2.0, the same contract implemented on both ends. That's how a Python agent graph ends up driving a native React Native screen. One call, one turn, one card.
The backend is a real service. Python, FastAPI, LangGraph. Multi tenant, per app keys with scoped access, session state living outside the process so it scales sideways, data in eu-central-1 because GDPR isn't a Q3 problem.
There's a console. Register an app, edit the config without cutting a release, read the funnel, open any session and read the transcript.
It's tested like something people depend on. The drop in kit runs 630 tests on every merge, and the agent routing has its own eval suite with an accuracy gate, so "the agent got worse" shows up as a failing build instead of a feeling.

First card lands in about 130 milliseconds, against roughly three and a half seconds when I started. Onboarding is the one screen where a spinner costs you the user permanently.

What a seat gets you

If Wire AI doesn't lift your activation, you've paid nothing and you still keep the teardown.

That's the deal in one sentence. Here's everything inside it.

The Activation Teardown, before you commit to anything. I put your existing onboarding through the analysis and send you a report: where people drop, which step leaks, what I would change first and why. It's yours whether you take a seat or walk away, and you don't need to install a single line of code to get it.
The install, done by me, by hand. Up to four hours on a call, in your codebase, together. Not a docs link and good luck. This is the part that doesn't scale, and it's exactly why there are 15 seats and not 500.
Your bugs jump the queue. When you hit something broken, and you will, it gets fixed that day instead of queueing behind everything else. That stops being possible the moment this cohort is full.
A direct line to the roadmap. What gets built next is what early-access apps need next. At this stage that isn't landing-page language, it's just how the queue works, because there is nobody in front of you.
Analytics free to 1 million events a month. Any app, not only early access, and it doesn't expire when the beta does.

No price, and that's deliberate. I'm not deciding what Wire AI costs until early access tells me what it's worth, so nobody in these 15 seats gets priced by a guess.

What I want back

One thing: the truth, while you use it.

When a question the AI asks is stupid, say so. When the console confuses you, say so. When a number looks wrong, say so, and that one is worth more to me than any testimonial you could write.

That's the whole trade. You get the teardown, the install, the queue and the roadmap line. I get the thing I can't buy, which is honest reactions from a real app with real users in it.

If it isn't you, it might be someone you know

All three seats that are gone came warm. Somebody knew somebody. Not one came from a cold email, and I have sent a lot of cold emails, so I've stopped pretending that's the channel.

So if your own app doesn't fit but a name came to mind while you were reading, that's the ask. Forward this to them, or drop the name in a comment and I'll reach out and tell them you sent me.

Anyone arriving through a referral skips the queue and goes straight to a call. And I'll run the Activation Teardown on your app too, even if you never install anything.

Before you say yes, two things you should know

Only the onboarding stage is live and proven. The journey wide experimentation I described up there is the roadmap, not a shipped feature. I'd rather you hear that now than find it out in week two.
I have an open number I can't explain yet. This week my own dashboard read 23% completion on an app that had been finishing north of ninety. I spent a morning on it and I still don't have a clean answer. Best guess is the dashboard, there are two honest ways to compute a completion rate and my headline tile looks like it's reading the wrong one, but I haven't proven it and I'm not going to pretend I have.

Both of those are in a launch post on purpose. The product is deliberately incomplete at this stage, and the fastest way to harden it is with a few real apps inside it rather than a year of me polishing it alone. If that reads as a red flag, this isn't the right moment for you and that's a fair call.

Who this is for

You're a fit if you have a React Native or Expo app that's live, with real users going through an onboarding right now, and you're a solo founder or a tiny team where the person who feels the activation problem is also the person who decides.

It helps if your app already has AI or personalization in it, because then I don't have to sell you the idea and we can go straight to the mechanics.

You're not a fit if you already have a growth team running experiments every week. Genuinely. A larger company passed on this recently for exactly that reason and they were right to. The value here is removing a person from a loop you don't have. If you have the person, you don't need me.

Pre launch is also a bad fit, and I say that with some regret because those are usually the most fun conversations. Without traffic there's nothing for the loop to learn from.

How to claim a seat

Reply to this email. That's the whole process, there's no form and no demo request.

Tell me what your app does and roughly how many people go through onboarding in a week. Two sentences is plenty. If it's a fit I'll send you a time this week. If it isn't, I'll tell you straight instead of quietly moving you into a nurture sequence.

Not sure you qualify? Ask for the teardown anyway. Worst case, you get a report on your own funnel and we both move on.

12 seats left of 15. The cap is real, because the install is manual and I'm the one doing it.

How I make this

I draft with AI. I've written about my workflow more than once and it'd be strange to hide it here. The receipts, the numbers, the decisions and the opinions are mine, the sentences get a drafting partner and then a lot of editing from me. If that disqualifies me for you, fair enough. If it interests you, that's most of what this newsletter is about.

I'm Malik, 9 years building mobile apps, React Native and Expo. I write Code Meet AI, where I show what I'm building with AI and what it costs me. Wire AI lives at getwireai.com, and the SDK is open source.

Fable 5 vs Opus vs GLM: I had a cheaper model grade the audit of my own code

Malik Chohra — Tue, 21 Jul 2026 09:43:04 +0000

i'm building Wire AI, and the next piece i have to build is the learning loop. It's the self-improving core of the engine: it takes each user's journey inside the app, generates variations of that flow, tests them, and keeps whatever makes people activate and stay. Real implementation work, a big pile of it, and the kind you'd rather not write by hand at frontier prices every single time.

so i wanted to do that build with a cheaper Chinese model, GLM 5.2, instead of reaching for a frontier model on reflex. one problem. cheap-and-wrong is the most expensive thing there is, and i was not about to let a model i hadn't vetted write production code inside my own engine. so before i trusted it with anything, i gave it a hard, real technical challenge: audit the actual codebase behind Wire AI and tell me where it breaks. not a benchmark, my own code, the files i'd opened a dozen times and thought i understood.

and i didn't just point GLM at it and hope. i ran the same audit through three models to see where the cheap one really lands: GLM 5.2, the candidate i actually wanted to hire for the build; Opus 4.8, my daily driver and the reference i already trust; and Fable 5, the ceiling. cheap, reliable, frontier, same job, and i'd grade every finding myself.

Here is what happened, with the receipts, because a feeling is not evidence.

Most model comparisons you read are benchmark charts on tasks neither you nor the author care about. i wanted the other thing. One real task, my own codebase, the actual numbers off the runs instead of vibes. So i gave three models the identical job inside Claude Code: audit the architecture of this SDK and tell me where it breaks when i build on top of it. Same prompt, same files, same instruction to cite every claim with a real file path. Then i read every output against the source and counted what was actually true.

a quick aside on what the codebase even is

The code i audited isn't a side project. It's the engine behind Wire AI, the thing i'm building, and it helps to know what it does before you watch three models take it apart.

Wire AI finds your app's winning formula. The one-breath version of how: it runs the experience inside your app, the first session a user gets, the moment they finally get it, the parts of the app they find, what they tell you back, then tests the variations itself and keeps the ones that make users stay. You set the goal. The AI runs the loop.

Here's the part that's easy to miss, and it's the reason i keep testing this thing against real code. Changing the app with no release isn't the trick, plenty of tools do that now. The difference is who's holding the pen. In the usual setup a person sits in a no-code builder and drags the new flow together by hand. In this one there's no builder and nobody in the middle: the AI writes the variants, runs them, and promotes the winner. That's the whole bet, and it only works if the engine underneath is right.

The part i keep pointing models at is exactly that engine, the piece that generates and renders those flows at runtime, the server deciding what a given user sees and the app drawing it without a new binary. It's the code with real users behind it, so it's the code i actually need to be right. Which is why i handed it to three different models and read every word back against the source.

the audit, scored

GLM 5.2, the cheap one. Opus 4.8, the one i run every day. And Fable 5, the frontier model, the most capable one i have access to. Same job for all three.

GLM and Opus found the same five problems. Not similar problems. The same five, down to the files.

They both caught that my component types get sealed into the bundle at startup, so an agent can't define a component at runtime. They both caught that streaming is dead on the agent path because the adapter never implemented it. They both caught the drift between what my SDK can render, what my server allows, and what my model actually gets told about. They both traced the coupling between the SDK and the agent backend to the same leaky spot. And they both landed on the same fix, make the registry the single source of truth.

i verified the citations on both. Zero hallucinations, every file path checked out. GLM even found one extra thing Opus missed: a comment in my backend claiming it runs the latest Claude while the code underneath quietly calls a cheaper OpenAI model. The kind of lie your own codebase tells you.

So on those two it was a tie. One costs roughly ten times less than the other and it found the same five things. If the story ended there the headline writes itself, run the cheap one for audits, go home.

Then i gave Fable 5 the identical prompt, and it found eleven.

Not five. Eleven distinct architectural problems, plus three smaller ones it flagged separately as lower severity. The same five the other two found are in there. Then six more, and i checked those against the source the exact same way. The streaming path advertises a sixty second timeout in its own docstring while a hidden thirty second poll cap kills the request first. The mechanism the SDK exports to tell an agent what components exist is built, tested, and wired into nothing. The registry silently ignores a component swap if you keep the same name. The agent card reads a private Zod internal that a supported version of Zod no longer has, so it degrades to typeless without ever throwing an error. Real, cited, reproducible. Zero hallucinations again, and it rated its own weaker findings as medium confidence instead of overselling them.

Later i ran the inverse experiment, because trusting a frontier model on my own code without a check is exactly the mistake i tell everyone else not to make. i had a cheaper model independently re-verify all eleven findings, line by line, plus the three secondary ones. Fourteen confirmed, zero refuted. The frontier model found the problems, the cheap one confirmed the homework.

Take one of them, the sixty-versus-thirty-second one. My agent path promises sixty seconds right there in its own docstring, and underneath it a hidden thirty second poll cap kills the request first. i would have built onboarding flows on top of that, watched a perfectly legitimate agent run die at thirty seconds, and burned an afternoon blaming my prompt or the network before i found the real thing. Fable found it by reading. That's the one that landed for me, because it's the exact kind of bug you only ever meet in production, on a user's screen, at the worst possible time.

That's the finding that reframes the whole comparison. It's not that Fable is a better model on a leaderboard. It's that on a genuinely hard read, depth is not free, and the cheaper models stopped at the obvious layer.

the numbers behind the runs

This is the part i actually care about, pulled from the session logs, not estimated.

	GLM 5.2	Opus 4.8	Fable 5
Distinct problems found	5 (+1)	5	11 (+3)
Hallucinations	0	0	0
Turns / tool calls	69	64	40
Fresh input tokens billed	644,000	88,000	62,000
Wall clock	6.0 min	18.1 min	~8 min
Cost	$0.59	~$6	~$14

A few things jump out.

Token consumption runs the opposite direction from price. GLM billed six hundred and forty four thousand fresh input tokens for the job. Opus billed eighty eight thousand. Fable billed sixty two thousand, the fewest of the three, and it did the deepest read. The two expensive models lean hard on context caching, reusing what they've already read at a steep discount, and that's most of why they can cost more per token and still not blow up on input. You're not just paying for the weights, you're paying for how few fresh tokens the model needs to hold the whole codebase in its head at once.

But few tokens is not cheap. Fable billed the fewest fresh input tokens and still cost the most, because the frontier price sits on top of every token and its denser output is expensive to generate. GLM is a tenth of that. So the cost curve and the depth curve run in the same direction: you consume more, you get more, and the more here is real problems in real files, not padding.

Speed didn't track price either. GLM was fastest at six minutes. Fable came in around eight. Opus, on maximum reasoning effort, took eighteen, because i deliberately run it slow and thorough. Fast and cheap didn't mean shallow on the five, and slow and expensive wasn't the deepest. The deepest was the frontier model, at a middle speed. None of the tidy stories hold.

then i made one of them build

A read tests reasoning. It doesn't test whether a model can do unattended work. So i ran a second round, GLM only, on a real build: take the drift bug from the audit and fix it properly. Single source of truth, generated manifest, a test that fails if anything drifts again.

It worked. Ninety two tests passing when i ran them myself, a drift guard that failed correctly when i sabotaged it on purpose, two previously unreachable components wired through end to end. A clean, verified, tested refactor.

And the build burned nearly seven times what the audit did. Same model, same codebase, one fix. Not because the fix was large, because building unattended means iterating, and iterating burns tokens. Three hundred and seventeen turns. A hundred and twenty seven tool calls, more than half of them just running tests and reading the errors. On a read the cost gap is enormous and it's in GLM's favor. On a long build it closes fast, because the cheap model pays for its discount in extra steps.

what each model actually gave back

All three earned a job. That's the real conclusion, and it's more useful than a winner, because it tells me what to do on Monday.

Opus is the daily reliable read. It found the same five things GLM did, cited clean, no drama, on the everyday work where the answer sits at the obvious layer. It's the one i trust without babysitting it, and on a long autonomous build the token efficiency i pay for stops being a luxury and becomes the reason the job finishes cheaper than the sticker suggests.
GLM is the cheap different lens. It found the same five, at six hundred and forty four thousand tokens of brute-force reading instead of clever caching, and it surfaced the one comment the frontier model didn't. i don't care how it got there when the output is right and the run comes in an order of magnitude under the one i trust. For volume reads it's the pick, and even on a build it finishes, it just pays in turns.
Fable is the surprising deep finder. It found six real problems the other two walked straight past, in the exact files, with honest confidence about the ones it was less sure of. That's the model you point at the thing before you commit six months to building on top of it. One deep read to not ship on top of a broken assumption is the cheapest line item in the project.

None of them replaced the others. Cheap for volume, efficient for endurance, frontier for depth. Better outcome than a leaderboard.

where this actually went

Here's the part that isn't abstract. Those findings didn't sit in a doc. They went back into the engine, and the first tenant running it in production felt the difference.

The sixty-versus-thirty-second bug and the drift bug were the exact kind of thing that shows up as a mystery failure on a real user's phone. Hardening them was the point of the audit. Around the same stretch i chased the first-card latency on the onboarding and it dropped from about 2279ms to 71ms, because i prefetch the adaptive card while the user answers the fixed questions instead of after, so the first screen a user sees is close to instant now.

And the loop holds. On the live tenant it runs about 88.5% completion with zero server language-model fallbacks, on real production traffic. When the AI tested the flow length itself, the short version, roughly eight screens, won at 92.8% on its arm. Earlier in that tenant's life the same loop found the message that actually resonated and daily installs went from about 100 to 1,000, because it landed on the exact problem users showed up to solve.

i want to be honest about what that is. It's a set of real receipts, not one clean before-and-after conversion number. i don't have a single "we lifted X%" figure and i'm not going to invent one. What i have: a hardened engine, a first card that went from a beat-and-a-half to instant, a live flow completing in the high eighties to low nineties with nothing falling back to a language model on the server, and an acquisition number that moved because the loop found the words. That's the improvement, stated as the numbers i can actually stand behind.

That engine is Wire AI, and here's the one line that matters if you build apps. You put AI in your product, a feature, a chatbot, a recommendation. i let AI run mine, the loop above is the AI operating the product's experience, not sitting inside it as one more feature. Same instinct you already have, pointed one layer up. The easiest way in costs you nothing. Analytics free to 1M events/month. Forever. Any app. Wire it up and watch where your own funnel actually leaks before you commit to a thing. If you want the loop itself running your product, i'm taking 10 founders into a free founding cohort right now, and the deal is plain: don't pay if we don't improve your activation. i set it up with you hands-on and stay in it with you month to month, no invoice attached. If you just want to see where your app leaks first, i'll run you a free Activation Teardown, one AI report on your real users, ending in "here's what to fix", no strings. If you ship React Native and you've already got AI somewhere in the app, you're exactly who i want in that cohort. Reply and i'll run your teardown.

the honest caveats

Four, so nobody quotes this out of context.

This is one task type on one codebase. Strong evidence about reading and reasoning over real code. On building it's exactly one data point, GLM only, not a verdict.
The depth result is one audit. Fable finding eleven where the others found five is a real, verified result on this codebase. It is not a promise the frontier model always doubles the count. Run your own hard task before you trust the pattern.
The provider matters. i pinned GLM to its first-party host at full precision. The cheaper resellers serving the same model name can be quantized and worse, and then you're measuring the host, not the model.
And the telemetry isn't perfectly symmetric. The Opus and GLM numbers came from the original run transcripts. Fable's came from a clean re-run of the identical audit, and i've flagged every number that's measured slightly differently instead of smoothing it over.

If you want the raw data, the full audit from each model, the telemetry table, and the config i used to run all three, reply RECEIPTS and i'll send the breakdown.

context engineering, simplified

Malik Chohra — Tue, 21 Jul 2026 09:43:04 +0000

TL;DR

A prompt is the ask. Context is the ground it stands on: who this is for, what good looks like, the real material, and what to leave alone.
When the AI gives you generic or wrong output, the reflex is to write a cleverer prompt. Usually the prompt was fine and the context was thin.
More context is not better context. Dump everything in and the model loses the thread. Curation is the actual skill, and the boundary (what to ignore) is the load-bearing half.
Write the context down once, in a small set of files next to the code, and every future task starts from ground instead of a guess. Stale context is worse than none, so treat it like a dependency you keep current.

This piece is from Code Meet AI, my newsletter where i document how i actually use AI to ship real products, receipts included. New guides land there first.

A few weeks ago an AI i built into an app asked a real user to name a beach-party plan. First thirty seconds in the product. The app can technically make a plan called that, so it wasn't a hallucination exactly, it was worse: a real feature dragged to the front because the model had nothing better to go on. i had handed it a one-line description of the app and told it to get the user to a concrete first action. A one-line description is an invitation to guess. So it guessed, confidently, in front of someone i was trying to keep.

That was the moment context engineering stopped being a phrase i skimmed past and became a bug with a name. And here is the part that should get a senior dev's attention: the failure looked exactly like AI code that compiles clean and still ships a bug. Confident, plausible, wrong. The fix was never a better prompt.

a prompt is the ask, context is the ground

The prompt is what you want. "Write the migration." "Refactor this service." "Draft the onboarding." Short, and you already know how to write one. Context is everything the model needs to answer that well and doesn't have unless you give it: which service owns this, which files are generated and off-limits, what the system actually does and who is on the other side of it. The prompt points at a target. Context is whether the model can see the target or is throwing in the dark.

Most bad AI output is not a bad prompt. It is a fine prompt fired into an empty room. The model fills the empty room with the most statistically average thing, and average is exactly what makes you close the tab and call it overhyped.

the four things you are actually feeding it

When people say "context," they mean four different things stacked together. It helps to see them apart.

A prompt is the arrow. These four are the ground it lands on.

The goal. Not the task, the outcome. "Turn these contracts into a tracker" is a task. "so i can see at a glance which renewals are risky this quarter" is the goal. Give the model the why and it makes better calls on the hundred small things you didn't specify.

The ground truth. The real material, not a description of it. This is the one people skip. Don't tell the AI "our style is terse and functional," paste two modules that already read that way. Examples beat adjectives every time. A model shown three real things you like will out-perform any paragraph describing them.

The constraints. What good looks like and what to never do. The format. The interface it has to satisfy. The generated files it must not edit. Constraints are not the AI's handcuffs, they are how it knows it succeeded instead of guessing at your taste.

The boundary. What to leave out and what not to touch. This is the half nobody talks about, and it is coming next, because it is the one that separates people who are good at this from people who just paste more.

more context is not better context

Here is the counter-move, and it is the part everyone gets wrong.

Once you learn that thin context causes bad output, the obvious next step is to feed it everything. The whole repo. The entire history. Every doc, in case it helps. It feels thorough. It is the exact opposite of thorough.

A model has a working memory, and past a point, adding more doesn't inform it, it distracts it. The signal you actually needed gets buried under fifty files of nearly-relevant noise, and the answer gets vaguer, not sharper. i have watched a model give a worse answer to the same question after i "helpfully" pasted three more files. The good lines were in there. It just couldn't find them anymore.

So context engineering is not "add context until it works." It is "give it exactly what this task needs, and nothing that competes with that." Curation, not accumulation. Telling the model what to ignore is as load-bearing as telling it what to read. This is the same discipline as scoping a service token: you grant the access the job needs, not everything you own, because blast radius is real whether the risk is a leaked secret or a distracted model.

The test i use now is embarrassingly simple. Before i paste something in, i ask: does the model need this to answer, or am i adding it to feel safe? The second kind is the noise.

how to actually do it

You don't need a framework. You need four sentences before the task, roughly in this order.

State the goal, not just the task. One line on the outcome you're actually after. "so that..." is the most useful phrase in the whole practice.
Show, don't describe. Paste two or three real examples of what good looks like. A before, an after, a module you'd be happy to merge. This single move fixes most "it sounds generic" complaints.
Name the constraints and the anti-goals. The format, the interface, the hard limits, and the one or two things it must never do. Short bullets are fine.
Draw the boundary. Say what to use and what to ignore. "Only this package." "Don't touch the generated types." "The old implementation is background, not a template."

That's it. Four sentences turns a coin flip into something you'd actually ship.

write it down once

The last move is what makes this compound instead of repeat. The first time you assemble the context for a recurring job, don't throw it away. Put it in the repo, next to the code it describes. Next time, you point the AI at the folder and add one line for today's task. A five-minute setup becomes a five-second one, and the output stays consistent because the ground under it stopped moving.

On a real project this is not one file, it is a few, and the names are becoming a standard any agent already reads. PROJECT.md for what the thing is and why. CONTEXT.md for what you are working on right now. CLAUDE.md and AGENTS.md for the rules and conventions you want followed. README.md for the human who lands cold. And progress.md, the memory file from episode 02, for what happened last.

the context lives in the repo, not in your head. any AI you point at the folder reads it and knows where it is.

If episode 02 sounds like it is happening again, that is because it is. A memory folder is context that persists across sessions. A context file is the same instinct pointed at a single repo.

where this breaks

Two ways, both worth knowing.

Stale context is worse than no context. A context file that still describes last quarter's architecture will make the AI confidently wrong, and confidently wrong is the expensive kind. When the thing changes, change the file. It is a living note, not a monument, and it belongs in code review like anything else that drifts.

And context is not a substitute for the check. Grounding the model dramatically raises the floor, it does not remove your job of reading the diff before you trust it. A non-engineer has no compiler and no test suite to catch a confident lie, but neither does your prose. The review step is the job that does not get automated away, and it is its own episode later in this series.

The punchline is small and annoying and true: most of the time the AI wasn't wrong because it is dumb. It was wrong because it was guessing, and it was guessing because you didn't tell it the thing you assumed was obvious. Context engineering is just the discipline of saying the obvious thing out loud, once, and then reusing it.

I put together a context starter pack: the four-line context you write before a task, the set of files that give any AI your whole project's context (PROJECT, CONTEXT, CLAUDE, AGENTS, README, and the progress.md memory file from episode 02, each explained), and the one prompt that sets them up for you. It goes out through the newsletter first.

Written by Malik at Code Meet AI. This is episode 04 of Using AI, properly. Episode 02 was give the AI a memory, episode 03 was put the AI on the work around work. New guides land there first.

i'm Malik, i've been a mobile engineer for 9 years, and i run my work and this newsletter on the system these episodes describe. Next up: how to make the AI check its own work, before you do.

Claude Cowork acts across your files now. Confidence is not correctness.

Malik Chohra — Tue, 14 Jul 2026 08:12:31 +0000

TL;DR

Chat makes you drive every step. Cowork flips it: you describe the outcome, it plans the steps, works across your files and connected apps, and hands back the finished thing.
Anthropic says more than 90% of Claude Cowork usage is not software development. It is expense memos, contract trackers, client decks, folder cleanup. This week it went to web and mobile, and scheduled tasks run with no device online.
That is a governance surface, not just a convenience. It acts across whatever you connect, and it is confident when it is wrong. Scope the access, keep the review.
Start with one task you already resent, give it context first, and check its work like a code review.

This piece is from Code Meet AI, my newsletter where i document how i actually use AI to ship real products, receipts included. New guides land there first.

This Monday Anthropic put a number on something most of us felt but hadn't measured. They expanded Claude Cowork to web and mobile and shared what people actually run on it: more than 90% of usage is not software development. Not code. The biggest categories were business operations and content work. Reconciling the quarter's spend and drafting the memo about it. Turning a folder of contracts into a renewals tracker with the risks flagged. Building tomorrow's client deck from call transcripts.

They call it "the work around work." Good name. It is the layer of the job that is real work, takes real hours, and somehow is nobody's actual job.

If you write code, you have had this delegation engine for a year in the terminal. Cowork is that same engine pointed at everyone else's work. The interesting part for us is not the convenience. It is that the tool now acts, on its own, across whatever you connect it to. That changes what "review" means.

what Cowork is, in one honest paragraph

You already know chat: you ask, it answers, you ask again. You are the project manager of every tiny step.

Cowork is the same Claude with a different job description. You hand it an outcome: "turn this folder of contracts into a renewals tracker, flag anything risky." It makes a plan, breaks it into steps, works across the files and apps you have connected, and comes back with the finished thing. While it runs, you do something else. Since this week it follows you: start a task at your desk, check the status on your phone, pick up the result later with the laptop closed. Scheduled tasks run even with no device online.

Chat: you drive. Cowork: you describe, then review.

my actual Claude home. one toggle flips chat into Cowork, and "send me a daily briefing" is already sitting there as a suggestion.

One tool, two jobs, and the second job is most people's actual day.

what people actually run on it

Not moonshots. Chores. The patterns showing up again and again in the early write-ups:

Folder archaeology. Sort, rename, and deduplicate a cluttered folder. Rename 400 photos to match the product list. The task postponed for a year because it is three hours of mind-numbing clicking.

Pile of documents, should be a list. A folder of contracts becomes a renewals tracker with dates and risk flags. A stack of receipts becomes an expense sheet. Dense PDFs in, structured table out.

The recurring report. The weekly status, the morning brief, the numbers pulled into the same format every Monday. Described once as a routine, in plain language: what to gather, what format, where to deliver it. It runs every morning without you. Cron, described in English, with file and app access.

First drafts from your own material. Tomorrow's client deck from the call transcripts. The variance memo from the spreadsheet. Not "write me something generic," but "turn my raw material into my draft."

The common shape: high effort, repeatable, source material already in your files.

the part that should get your attention

Here is where the senior-dev instinct earns its keep. Two things about this tool are load-bearing, and both are easy to wave past.

It has access to what you give it. That is the feature and the risk in one sentence. Connect the folders and tools the job needs, not everything you own. This is least privilege, the same principle you apply to a service token or an OAuth scope, except the person setting it up may never have thought about blast radius in their life. A general-purpose agent with read and write access to your whole drive is a very different thing from one pointed at a single project folder.

And it is confident, including when it is wrong. A renewals tracker with one silently wrong date is worse than no tracker, because someone will trust it. You already know this shape from AI-generated code that compiles clean and still ships a bug. The difference is that a non-engineer has no compiler, no test suite, no diff habit to catch it. The review step is not optional politeness. It is the entire job that does not get automated away.

So the honest framing is not "AI does your admin now." It is "AI does your admin now, and it needs the same governance you already give your code: scoped access, and a review before you trust the output."

how to start: one resented task

Don't tour the features. Pick the one task you flinched at earlier. Then:

Give it context first. Before the task, point Cowork at a short context file: what this project is, what good output looks like, what to leave alone. If you have given an AI a memory folder before, this is the same muscle. Two minutes, and the output quality jump is not subtle.
Describe the outcome, not the steps. "Make this folder make sense: group by client, newest first, flag anything duplicated" beats a 12-message back-and-forth.
Review like a manager, not a believer. Open the deliverable, spot-check five rows against the source. A code review with different file types.
If it worked twice, make it a routine, and scope it tight. Describe it once, give it access to exactly the folder it needs, and stop doing it forever.

the punchline

The AI didn't take the work. It took the work around the work. What's left over is the part that needed you all along: deciding, and checking. For us that is not new. We just called it code review and least privilege. The rest of the world is about to learn why we were so annoying about both.

I am putting together a routines starter pack: three plain-language routine templates (the folder cleanup, the pile-to-tracker, the morning brief) you can adapt in five minutes. It goes out through the newsletter first.

Written by Malik at Code Meet AI. This is episode 03 of Using AI, properly. Episode 02 was give the AI a memory, episode 01 was the art of prompting. New guides land there first.

i'm Malik, i've been a mobile engineer for 9 years, and i run my work and this newsletter on the system these episodes describe. The delegation habit started in the terminal, moved to my second brain, and now it does the work around the work. Next up: where a single sentence stops helping, and context begins.

Memory you can't inspect is memory you can't trust

Malik Chohra — Fri, 10 Jul 2026 14:48:10 +0000

TL;DR

Every new session your AI starts from zero. It doesn't remember you, your repo, or the thing it got wrong yesterday.
The fix is not a feature you wait for, it's a file you write. Two, actually: house rules (CLAUDE.md) and a diary (a memory folder).
The habit that makes it work: end each session with "what should you remember from this? write it down," and save the answer as one small note.
Wrong memories are worse than none. Keep each note to one fact so you can delete it the day it stops being true.

This piece is from Code Meet AI, my newsletter where i document how i actually use AI to ship real products, receipts included. New guides land there first.

This Tuesday my AI told me a piece of work was shipped. Merged, published, CI green, the whole report. It wasn't. The server was still serving week-old code, and i only caught it because i went and hit the actual endpoint instead of trusting the summary.

Annoying. But here is the part worth stealing. Instead of fixing it and moving on, i had the AI write the lesson down. One small note in the project's memory folder: "merged is not deployed. before you say shipped, curl the live thing and check the release SHA against the merge, twice."

Next morning, new session, zero context, the model has no memory of Tuesday. I run an npm publish and it stops me: the version on the registry didn't match the build we had just tested. It caught the exact same class of mistake, on its own, because Tuesday's note was sitting in a file it reads on startup.

That's the whole trick, and it lives in your repo, not in some feature you're waiting for.

I didn't plan any of this. It grew out of my repos. Each project got a small folder of markdown the AI reads before it writes a line of code, so it never opens the thing cold. That worked well enough that i lifted the whole pattern out of the codebase. My second brain runs on it now, the Obsidian vault too, and every work session i close ends by writing to the same kind of file. The pattern i built for my repos runs my notes.

your AI opens the project blind

You know this if you pair with Claude Code or Cursor daily. The first ten minutes of every session go to re-explaining the same things. The stack, where the API client lives, which files are generated, the conventions you moved to and the pattern you moved off. Good session. Next morning it opens the repo like it has never seen it.

So you type it all out again. Every day.

There was a thread on r/ClaudeAI this week, roughly titled "I often forget how many people are clueless when it comes to Claude (or any AI)." A bit harsh. The gap it points at is real though, and it is not intelligence, it is setup. The people getting compounding value out of these tools are not smarter. They stopped re-briefing the assistant every morning.

A session is a phone call. When it ends, the other side keeps no notes unless somebody writes them down. So write them down.

two kinds of memory, two files

Everything worth keeping splits into two buckets, and they belong in two different places.

House rules. The stuff that is always true: the stack, the conventions, the boundaries, the things it should never touch. One standing file the AI reads at the start of every session. In Claude Code that file is literally CLAUDE.md. Cursor calls it .cursorrules, some tools read AGENTS.md. Same idea everywhere, a one-page briefing that is just always there.

The diary. The stuff it learns as you go: a correction, a decision that closed a debate, a gotcha. "The Android build breaks if you bump reanimated past the pinned version." "We dropped the March API, stop importing it." "Merged is not deployed." Learned facts, they change, so they don't belong in the house rules.

Here is the part people overbuild. On day one the diary is one file. Make a memory.md in the repo root, tell the AI to read it at session start, and add a line whenever something worth keeping shows up. A working memory system, no framework, no folder. The folder version is an upgrade you grow into, and i'll show you mine in a minute. But it starts as one file you could open in any editor.

House rules are written once and edited rarely. The diary grows a note at a time.

Why the split matters: CLAUDE.md you write once and edit rarely, the diary grows every week and any note in it can turn out wrong later. Mix them and your always-on briefing slowly fills with stale facts, the one file you least want rotting. Keep them apart and each stays honest.

The tools already exist and you'll meet them as you go. Claude Code reads CLAUDE.md plus a memory folder automatically, the community ships things like claude-mem that record whole sessions, ChatGPT and Claude both have built-in memory they fill on their own. All fine. The plain file has one quiet advantage though: you can open it, diff it, and delete the wrong bits, and git already keeps the history. Memory you can't inspect is memory you can't trust, and a file you wrote is the most inspectable memory there is.

the capture loop

The memory folder doesn't fill itself. The habit that fills it takes about two minutes.

At the end of a session, ask: "what should you remember from this session? write it down."

That's it. Every correction, every "actually, do it this way," every decision that closed a question becomes a candidate. The AI writes each as its own small note and adds a line to the index.

I'm not the only one on a version of this. One of the most upvoted posts on r/ClaudeAI this month, close to three thousand upvotes, was titled "I end every AI session with two questions." The session-ending ritual is quietly becoming the power move, because it converts a good session, which evaporates the moment you close the tab, into a note, which does not.

One turn of the loop per session. It compounds fast.

Mine runs on two habits. During the day, anything worth keeping gets dumped into an inbox note without stopping to sort it. At the end of a session the AI does the ritual: sorts what it learned, writes the notes, updates the index. Next morning it reads the index and picks up where we left off.

the memory bank: one folder per repo

Once the one-file memory.md clicks, there's a natural upgrade, and it's still just files. I call it a memory bank: one small folder per repo, two files inside.

The first is the context: what this repo is, the stack, the conventions, the boundaries, the things the AI must never touch. You write it once and edit it rarely. The second is the progress: a dated log of where the work actually stands, updated at the end of each session. Drop both in a .memory/ folder in the repo (or docs/, wherever your team already looks) and point the AI at them on startup.

Here's the whole thing:

your-repo/
  .memory/
    context.md    stack, conventions, boundaries, hard no's. written once.
    progress.md   2026-07-09: shipped the auth refactor. open: token-refresh race. next: wire the retry.

Same shape for every repo you touch. The context file barely moves. The progress file is a diary with dates. Open a session, the AI reads both, and it starts from where the code actually is instead of from zero. This is not theory for me: my whole work life runs on these folders, and the "merged is not deployed" catch from the opener came straight out of one.

You don't have to hand-roll it either. Paste this into the AI once, per repo:

I want to give you a memory for this repo. Do two things.

First, create .memory/context.md. Interview me before you write it: ask one question at a time about what this repo is, the stack, the conventions, and the things you must never touch. Then write a one-page briefing you would want to read at the start of every session.

Second, create .memory/progress.md. Start it with today's date and one line: where the work stands right now.

From now on, read both files at the start of every session on this repo.

And at the end of each session, this one:

Before we finish, update .memory/progress.md. Add today's date and 3 to 5 lines: what we did, what we decided, what is still open, and anything you should remember next time. If i corrected you today or gave you a convention, put that in context.md instead. Keep both files short. Cut anything that is no longer true.

That second prompt is the whole engine. It's the capture loop from the last section, turned into a habit you can paste.

one fact per note, so you can fire it

The rule that took me longest to learn: one fact per note.

Not a session summary. Not a changelog. One fact, a couple of lines, with a date. "2026-07: merged is not deployed, verify the live endpoint before reporting shipped." That's a whole note.

The reason is not tidiness. Memories go stale, and a stale memory is worse than no memory, because the model states it with full confidence. The component gets refactored, the workaround you swore by gets fixed upstream, the dependency you pinned moves on. When each fact lives alone, you delete that one note and the rest stays intact. When facts live tangled in a long summary, you can't pull the rotten one without rewriting everything, so nobody does, and the whole thing quietly rots.

My memory folder is a few months old now. Notes get added most days, and deleted too, and that is not the system failing, that is the system working. Tuesday's "merged is not deployed" note earned its place by catching a real mistake inside twenty-four hours. A note that never fires again for months gets cut.

where this breaks

Honest limits, because there are some.

Memory doesn't make the AI right, it makes it consistent. Write down a wrong fact and you now have a machine that repeats your mistake politely, forever. Re-check anything important that came out of memory, especially anything with a date on it.

No secrets in there. Tokens, keys, other people's private data. A memory folder is a plain readable file and it's probably tracked in git, so treat it like one.

And don't over-collect. The goal is not to remember everything, it's to stop re-explaining the same ten things. If your index runs longer than a page, you're hoarding, not remembering.

start on your next branch

Two files. A CLAUDE.md with your stack and conventions. An empty memory folder with an empty index. Then end your next session with "what should you remember from this?" and let it write note one.

That's the whole setup. The assistant you pair with next week already feels different from today's, and the gap only widens from there.

I put together a memory starter pack: the CLAUDE.md template i actually use, the note format, the index file, and the exact session-ending prompt. It goes out through the newsletter first.

Written by Malik at Code Meet AI. This is episode 02 of Using AI, properly. Episode 01 was the art of prompting. New guides land there first.

i'm Malik, i've been a mobile engineer for 9 years, and i run my work and this newsletter on the system these episodes describe. The memory folder is where the second brain and this newsletter both live now. Next up: putting the AI to work on the work around the work.

Loop engineering with Fable 5

Malik Chohra — Wed, 08 Jul 2026 19:52:33 +0000

TL;DR

I pointed Fable 5 at my own React Native SDK, read only. It found 11 real bugs, each cited to a file and a line, six more than the two other models on the same job. A cheaper model re-checked all 11 against the source. 0 got refuted.
Finding bugs just got cheap. The moat moved to the check: tests plus reviewer agents run in a clean context, the part that does not come in the box.
A model in a loop with no check is a confident intern shipping unwatched. The check is the discipline that keeps it useful instead of dangerous.
Below: the two paste-able prompts I run (a read-only architecture audit and a weekly news loop), the receipts, and the loop I run them in.

This piece is from Code Meet AI, my newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first. It was originally published there.

Finding bugs used to be the expensive, senior skill. Then I pointed Fable 5 at my own React Native / Expo SDK, read only, and asked where the code breaks when another app builds on top of it. It handed back eleven real problems, each cited to a file and a line, six more than the two other models I ran on the same job. A cheaper model re-checked all eleven against the source. Zero got refuted.

That should scare you a little, not excite you. A model that good at finding things, wired to also fix and ship them unwatched, is a confident intern with commit access. The risk is not that it is wrong. The risk is that it is confidently, plausibly wrong on the one path that actually ships, and nobody checked. The discipline that keeps that intern useful instead of dangerous is the check. That is the whole job now, and it is the beat everyone skips.

My last 7 days in Claude Code. Opus 4.8 and Fable 5, split about 58/42. This is not a test drive: Fable does roughly 40 percent of my real work now.

So a model that good at finding things is only worth the bill if you do something with the finding, and "chatting with it" is not that. The way I actually use a model like this is the way I use every model now. I do not talk to it. I put it in a loop, and I spend my own time on the one part of the loop that still needs me.

Here is the loop, the prompts, and the part that does the real work.

What a loop actually is

Every loop has the same four beats.

Goal. You write down what done means before anything runs. Not a vibe, a test. Something that can come back true or false.

Act. The model takes one step toward that goal.

Check. Something compares the result against the goal.

Repeat. Failed the check, go again. Passed, stop.

The check is the beat everyone skips. It is also the whole game, and I will come back to it, because it is where finding a bug and actually shipping a fix stop being the same thing.

For content people the goal might be "beats my best newsletter." For me the goal is a codebase that stays green. Same shape, different done. I run this loop as a system I call Spec Harness: plan, spec, build, verify, learn. The model does the building. The verify step is the check. The learn step is what makes tomorrow's loop tighter than today's.

The loop, four beats. Goal, act, check, repeat. The check is the one everyone skips.

How I prompt Fable for the read that sets the goal

The loop needs a goal, and for code the goal starts with an honest read of what is actually wrong. That read is the one place I pay for the frontier model, because it is a single expensive pass I run once, not the grind that comes after.

Four things make the read worth the money.

Give it the reason, not just the task. "Audit this SDK, two apps are about to ship on top of it" gets a sharper read than "find bugs."

Set a boundary. Read only. It audits, it does not touch the code. Finding and fixing are different beats of the loop, and letting one model do both in one breath makes both sloppy.

Make it cite everything. Every finding points at a real file and line. A made-up bug cannot cite a real location, so this one rule kills hallucinations. It is also how I spot-checked eleven findings in minutes.

Make it grade itself. Rate each finding high, medium, low. A model that will admit "medium, not certain" on its weak calls is one you can trust on the strong ones.

The paste-able version, adapt the paths to your repo:

Audit the architecture of <package or feature dir> in this React Native / Expo app. Read only. Do not edit a single file.

Context: this ships to real users on real phones in a few days, and other screens (in my case, other apps too) are being built on top of it. I care about the problems that survive to production and page me at 2am, not style nits.

For every problem you find:
- cite the exact file and line
- explain how it breaks when someone builds on top of it, or when it hits a real device: slow or dropped network, the app backgrounded mid-request, low memory, a cold start, or the OS killing and restoring the process
- name the layer it lives in: state, navigation, data fetching, a native module, or the public API other code depends on
- rate your confidence high / medium / low, and for anything medium, say exactly what you'd need to read to make it high

Prioritise, in this order: silent data loss, a failure the user never sees but that corrupts state, anything that only breaks after the app is killed and reopened, and any API shape that forces a breaking change on the screens already built on it.

Do not pad the list. Ten real, cited problems I can fix today beat forty maybes. If an area is genuinely solid, say so plainly instead of inventing a finding.

Then I hand the list to a cheaper model and ask it to refute each finding against the source. Zero of the eleven survived as false. Frontier finds, cheap checks, I do neither by hand. That verified list is the goal the rest of the loop runs against.

If you do not write code, the same four rules work on anything you ship. Here is the one I run on the marketing side once a week. It reads the week's news in my space, hands back posts I could actually publish, and ranks them against what has already worked for me. Different job, identical bones: give it the reason, keep it read-only, make it cite every claim to a real source, make it grade its own confidence.

Scan the last 7 days of news and discussion in <your space>. Read and gather only, publish nothing.

Goal: three posts I could ship this week that would beat my best-performing post, not generic hot takes.

For each one:
- link the exact article, thread, or number it is built on (no angle without a real source)
- write it as a post I could publish as-is, in my voice, not a summary of the news
- name which of my patterns that has worked before it matches, and why it should land
- rate your confidence high / medium / low; for any medium, say what you would need to know about my audience to make it high

Then rank the three against what has actually worked for me before, and tell me the one you would cut.
Do not pad. One post I can ship today, tied to a real source, beats five vague trend-chases.

Swap "posts" for "emails," "landing sections," or "feature ideas" and the shape holds. The domain changes; the four rules do not.

The effort dial, and the one place I still switch models

The advice going around is to stop switching models and just use Fable's effort dial. Turn it down for easy work, up for hard, one model for everything. For a single reasoning pass, that is right. I leave the dial on high, push it up when the read is genuinely hard, and I stopped babysitting the model picker for one-shot work.

The dial does not save you inside a loop, though.

A build loop iterates for hundreds of turns, and every turn re-sends a growing context at the model's per-token rate. That rate is what compounds, not how hard the model thought on any single turn. I watched the same cheap model that audited my SDK for fifty nine cents spend four dollars building one fix, because building means running tests and reading errors over and over. Put a frontier model on that loop with the dial turned down and you are ordering the cheap wine at a three-star restaurant. You saved on the wrong line.

A normal day. I run the window down to the wall, it resets, I do it again. That is what "I actually use it" looks like on the invoice.

So I do both. The dial for the single read. A cheaper model for the loop that grinds. One is a knob inside a model, the other is a knob across phases. They are not the same knob.

Pay the frontier rate once for the read. Drop to a cheaper model for the build loop, where the cost compounds every turn.

Building the loop: the check is the part you actually build

Writing the loop is easy. Writing the check is the job.

Charlie Hills, whose piece got me writing this one, builds his check as a rubric. He fed a model a hundred and ten past newsletters plus their engagement numbers, had it pull out a scoring rubric, and now a separate judge agent scores every draft against it until it clears the bar. Separate judge, on purpose, so nothing grades its own homework.

My check is not a content rubric. It is tests, plus agents that read like a senior reviewer, all run in a clean context so nothing marks its own work.

The check is tests plus a reviewer agent plus a workflow-tester, all run in a clean context so nothing grades its own homework.

Two of those agents earn their keep every week.

A reviewer agent. I was wiring the same AI onboarding into two apps at once, mine and a client's, built days apart. The reviewer read both and found the same three mistakes in each. Config hand-rolled separately instead of calling the one shared helper, the copy-paste that drifts the second you touch it. An onboarding that asked the user what they cared about and then threw the answers away before saving, a quiet data-loss bug I would never have caught by eye. And a fallback I promised in a code comment and never wired, so a backend timeout would have dead-ended the new user instead of dropping them back to the old flow. Three real bugs, twice, caught by the check, not by me.

A workflow-tester agent. On another job it caught a status-code bug: a database outage was reaching the client as the wrong HTTP code, a four hundred where it had to be a five hundred. The kind of thing that passes every happy-path test and pages you at 2am.

That is the check. It is boring, it is most of the work, and it is the reason I can let the loop run on something without watching it.

The one Fable finding I actually shipped went through exactly this. The goal was a failing test for a timeout bug it found, a path that advertised a sixty second limit in its own docstring while a hidden thirty second cap killed the request first. Opus wrote the fix. The check ran the full suite, eighty eight of eighty eight green, plus the review gate, before it ever became a pull request. Goal, act, check, repeat, then stop.

Your codebase is the moat

Charlie's line is that your data is the moat, because every model read the same internet and everyone's output sounds the same, so the differentiator is your own history fed into the loop. For code it is the same idea one layer over.

Every model has read the same open source. What it has not read is your bugs.

The learn step of my loop turns every bug the check catches into a dated rule the harness enforces next time. The reviewer's three mistakes became an eight-point review bar, so app number three cannot repeat what apps one and two did. The eleven Fable findings, the ten I deferred, the triage note for when they come back, all of it is a private test set that grows every week and belongs to nobody else. A general model finds a bug. My harness knows which bugs I keep making. That accumulation is the thing you cannot download.

41 million tokens, a 9-day streak, active every single day. The loop is a habit, not a demo, and the rules it has ratcheted out of my bugs are the part nobody else has.

The check is the job

Finding got cheap. Fable proved it on my own code, eleven real problems for the price of lunch, better than I did by eye. That skill, the one you used to pay a senior nine years in for, just got commoditized.

The check did not.

The tests you wrote, the rules you ratcheted out of your own mistakes, the judgment to ship one finding and defer ten in launch week because you know which ones touch the path that is actually shipping, none of that came in the box. A model in a loop with no check is a confident intern shipping unwatched. Slop is a failure of judgement, not tooling, as Charlie puts it. The loop scales you exactly as far as your check is good, and not one inch further.

So that is how I actually use Fable 5. I do not chat with it. I pay it once for the honest read, I drop to a cheaper model for the grind, and I spend my own time on the check, because that is the part that is still mine.

Finding what is wrong is free now. Checking it is the job.

Want the loop itself? The loop starter kit is the four-part loop plus the verifier and ratchet templates I actually run it on.

Written by Malik Chohra, AI-first mobile engineer, 9 years building health, wellness, and coaching products (Mindshine, acquired by Greator; DocMorris; CoachHub). I build the AI-native infrastructure the next wave of mobile products runs on, including getwireai.com and aimobilelauncher.com.

This was one issue of Code Meet AI. I document how I actually use AI to ship real products, receipts included, and new guides land there first. Subscribe at codemeetai.substack.com.

GLM 5.2 for 59 cents: the read is cheap, the build isn't

Malik Chohra — Tue, 07 Jul 2026 17:21:40 +0000

TL;DR

GLM 5.2 is the open-weight model everyone is benchmarking right now: a tenth of Claude's price, a one million token context window. Instead of reading takes, I ran it on my own SDK.
The setup is five lines in your Claude Code settings, routed through OpenRouter. Pin the Z.ai provider and turn off fallbacks, or you might be testing a quantized knockoff.
The architecture read: 41 files, every citation real, 59 cents, six minutes. The build: it worked, 92 tests green, but cost four dollars, most of it test-loop stamina.
My split now: GLM for the reading, Claude for the building. Private code never leaves my machine, cheap or not.

This piece is from Code Meet AI, my newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first.

My Claude Code bill had been bothering me for a while. Not scary numbers, just creeping ones. I run a lot of agents, sometimes a whole harness of them at once, and the number at the end of the month kept drifting up. So I went looking for a cheaper engine, and the thing everyone kept pointing at was a Chinese open-weight model called GLM 5.2.

Two reasons I wanted to try it. One was pure cost. If a model a tenth of the price could do even half my work, that's real money back. The other was a curiosity I'd been avoiding, if I'm honest. The Chinese labs have been shipping fast, the benchmarks look absurd, and I had never actually run one of their models on my own code to see past the marketing.

So I put five dollars on OpenRouter and decided to stop reading takes. I'd run GLM on the one codebase I know better than anyone, my own generative UI SDK, and check every line of what it gave back.

This is what I did, what it cost, and the part I got wrong before I started.

The setup, because it's shorter than you think

GLM 5.2 is an open-weight model from Z.ai. It came out in the middle of June, it has a one million token context window, and the thing people keep saying about it is that it codes like a frontier model for a fraction of the price. The public numbers back the noise up: on OpenRouter's Design Arena board it sits in the top one percent for code, across more than three thousand head-to-head tournaments. I didn't want to take that on faith either. Benchmarks are somebody else's code.

The public claim, as of this week: top one percent for code on Design Arena, 3,243 tournaments. This article is me checking it against my own repo.

Claude Code doesn't care which model sits behind it. It speaks the Anthropic API format, and it reads two environment variables to decide where to send requests. Point those at a different endpoint and the whole tool keeps working, same agent, same file editing, same test running, different brain.

I used OpenRouter as the endpoint. The reason is simple: one account, one API key, and it can route that key to dozens of model providers including Z.ai. I didn't want a separate billing relationship with a Chinese lab to run one experiment. OpenRouter sits in the middle, I top up a few dollars, and I can try any model behind one key.

Here's the whole path, start to finish.

Three steps to set it up.

First, make the key. On OpenRouter you create an API key and put a few dollars of credit on the account. There's no free GLM 5.2 tier, but the credit goes a long way, my whole experiment ran on five dollars and I didn't finish it.

Creating the key. The credit limit field is the safety net: mine got five dollars, hard cap.

The same key after the experiment: $4.59 of the five dollar cap used. Everything in this article ran inside that.

Second, point Claude Code at it. Five lines in your Claude Code settings:

ANTHROPIC_BASE_URL = https://openrouter.ai/api
ANTHROPIC_AUTH_TOKEN = your_openrouter_key
ANTHROPIC_DEFAULT_OPUS_MODEL = z-ai/glm-5.2
ANTHROPIC_DEFAULT_SONNET_MODEL = z-ai/glm-5.2
ANTHROPIC_DEFAULT_HAIKU_MODEL = z-ai/glm-4.5-air

Drop that in, start Claude Code, and you're talking to GLM. To go back to Claude you comment it out. That's the entire switch.

Third, and this is the step most people skip, pin the provider. On OpenRouter the same model name can be served by a long list of different companies, and the prices are all over the place, from under a dollar per million tokens to over three. That spread is not a coincidence. Some of those hosts run quantized copies of the model, smaller and faster and measurably dumber, and the Providers tab even has a quantization filter because of it. If you let OpenRouter auto-route you might land on one of those, and then you're testing a compressed knockoff while thinking you're testing the real thing.

Same model name, a dozen hosts, a real price spread. This is why you pin the provider.

I set the routing to Z.ai directly, the first-party host, and turned off fallbacks. Every request hit the real full-precision model and nothing else. If a fair comparison is the point, this toggle is the whole game.

The part I got wrong: my own code is not all mine to share

Here's the mistake I almost made. I was about to point a third-party model at my whole monorepo.

My SDK is open source. But sitting in the same repo are the things that are not open: the dynamic onboarding kit, the billing, the tenant logic, the work that's supposed to make money. Sending that to a hosted model in another country is exactly the kind of casual leak you only notice after it's gone.

So before anything ran, I built a clean copy. I pulled out only the showable parts, the SDK package and the mental coach example with its agent backend, and I left the commercial code on my disk where it belongs. Then I did the boring but important step: I searched the copy for the words that would give the game away, onboarding, billing, tenant, stripe, and confirmed there were zero hits before a single token left my machine.

That habit is the whole point. The model being cheap doesn't change the rule. Public code can go to a hosted API. Private code either stays local or it doesn't go at all. I wrote about choosing a more expensive but EU-safe model for a client backend a while ago for the same reason, and the logic didn't change just because this one was fun to try.

Task one: read my SDK and tell me where it breaks

The first job was a pure reading test. I told GLM to audit the architecture as if I were about to build a new generation of tooling on top of it. Find the load-bearing seams. Name the files. Tell me what will crack first. And the rule that mattered most: cite a real file and line for every claim, and if you're not sure, say so instead of inventing something.

It read forty-one files. Then it handed me an audit that found the three real problems I already knew were there.

It found that my component types are sealed into the bundle when the app starts, which means an agent can't define a new component at runtime, which is the exact thing my next feature needs. It found that streaming is quietly dead on my main agent path, because the adapter that handles it never implemented the streaming method. And it found a drift bug I'd been ignoring, where my SDK can render thirteen components but the server only allows eleven of them and only tells the model about seven, so two perfectly good components were unreachable through the agent.

I didn't take its word for any of this. I went through its citations and grepped each one against the code. They were real. The file paths were right, the line numbers were right, and it hadn't made up a single function. It even caught something I hadn't flagged: a comment in my backend that proudly says it uses the latest Claude models, sitting directly above code that actually calls a cheaper OpenAI model. A stale comment that became a small lie. Good eye, for a model I was ready to dismiss.

That audit cost fifty-nine cents and took six minutes.

Task two: now fix one of them

A read is one thing. Reading is where every model looks smart. So I said: ok, you can read my code. Now touch it.

I gave it the hardest fix from its own audit: kill the component drift for good. Make the SDK the single source of truth, generate a manifest from it, and have the server read that manifest instead of its own hand-typed list, so the two can never fall out of sync again. And write a test that fails if they ever do.

It did it. It generated the manifest, rewired the server to read it, promoted the two orphaned components into real SDK built-ins so they were finally reachable, and wrote a drift guard test. When I ran the suite myself, ninety-two tests passed, the original eighty-seven untouched and five new ones added. Then I tried to break it on purpose. I deleted a component from the manifest by hand and re-ran the guard. It failed, loudly, exactly where it should. The safety net had teeth.

It also hit a genuinely annoying toolchain trap along the way, a syntax issue in React Native that stops the test runner from loading certain files, and instead of hiding it or giving up it built a small workaround and then wrote the problem down in its report as a caveat. That honesty is worth more to me than a clean-looking result.

The catch, because there is always a catch

The build cost four dollars. The read cost fifty-nine cents.

The receipt behind the "ten times cheaper" line: same audit, same 41 files, priced twice.

That's the number nobody in the hype videos mentions. On the reading task GLM was a clear win, ten times cheaper than what I usually run, and three times faster. On the build it succeeded, but it spent most of those four dollars not on the fix itself but on grinding through the test harness, run the tests, read the error, edit, run again, over and over, three hundred turns of it. The actual code changes were maybe thirty of those steps. The rest was stamina.

So the lesson I'm keeping is not "GLM replaces my setup." It's narrower and more useful than that. For reading, reviewing, auditing, explaining a codebase, the kind of work where the model thinks hard once and hands you an answer, GLM 5.2 is a genuine bargain and I'll reach for it on purpose. For long unattended building, where the cost is paid in debugging loops, it works, but the price gap closes and the reasons I pay for a frontier model come back into focus.

Five dollars, one afternoon, my own code, and a clear answer instead of a feed full of opinions. That's the cheapest research I've done all month.

How I actually use this now

Two routes, depending on the code.

For anything public, I keep the OpenRouter config above in a commented block in my Claude Code settings. When I want a cheap second opinion on an open-source repo, an architecture read, a "what is wrong with this," I uncomment it, pin Z.ai, and let GLM do the heavy reading for cents. Claude stays my default for the building.

For anything private, the model goes to the code, the code doesn't go to the model. Local weights or nothing.

If you want the exact settings block, the provider-pinning step, and the little script I use to strip a repo down to the showable parts before sending it anywhere, reply LOCAL and I'll send it over.

This was one experiment in a longer thread I keep at Code Meet AI, where I document how I actually use AI to ship real products, receipts included. It's the hosted-model sibling of my post on running Claude Code offline with a local LLM. Next week: the full three-way comparison, GLM against the frontier models on the same tasks.

If you have run GLM 5.2 or another cheap model on real code, where did it hold up and where did it fall apart for you? I'm still calibrating my own split, and the build-cost number surprised me most.

The one habit that fixes generic AI answers (and 7 ways to ask)

Malik Chohra — Mon, 06 Jul 2026 10:41:07 +0000

TL;DR

You don't need to be technical to prompt well. You need to stop typing three words and hitting enter.
The one habit that fixes almost everything is context: tell the AI who it should be, what you want, and what a good answer looks like.
Seven simple ways of asking cover most of daily life, from summarizing an email to planning a week of meals.
The best place to practice is your own life: your messages, your plans, your notes.

This piece is from Code Meet AI, my newsletter where I document how I actually use AI to ship real things, receipts included. New guides land there first.

Prompting is just how you ask an AI for something. The AI reads your words, not your mind, so a lazy question gets a lazy answer. The fix is context: tell it who you want it to be, what you actually need, and what a good result would look like. After that, a handful of simple patterns handle almost anything. No jargon. You get good by practising on the things you already do every day.

The AI reads your words, not your mind

The first time a lot of people try one of these tools, they type something like "make me 1 million," read the bland thing that comes back, and quietly decide it is overrated. I did a version of this for months. I treated it like a smarter Google, typed three words, and was annoyed when i got three-word-quality answers back.

Spoiler alert: the "make me 1 million" prompt doesn't work. Which i think you already know by now.

What changed for me was not a better app. It was an afternoon in a park. Instead of firing one-line questions at it, i opened the AI on my phone and just talked to it for about three hours: what i was working on, what was stuck, what i had been avoiding. By the evening it could help me in a way it never could when i was firing one-liners at it.

That is the whole game. When you leave a question vague, the model fills the empty space with something generic, because generic is the safest guess when it does not know what you actually meant.

What a good prompt actually contains

A good prompt is not longer; it is clearer. Four things usually do it, and you rarely need all four: who you want the AI to be, what you want, the bit of context it cannot see, and what a good answer looks like.

Lazy: "give me dinner ideas." You get a generic list, half of which you would never make.

Clear: "You're a practical home cook. Give me three vegetarian dinners for a tired weeknight. I have pasta, spinach, and eggs, i want each under twenty minutes, and just give me the three with a one-line reason, no essay." Same question, but now it knows the situation, the limits, and the shape you want back.

The same question, minus the guesswork.

The seven ways to prompt

Friendly names first, the technical name in brackets for the curious.

Just ask it clearly (zero-shot). "Summarize this email in three bullets and tell me whether i need to reply." Your default for anything simple.
Show it an example (few-shot). "Here's a thank-you note i wrote once that felt right [paste it]. Write one like it for my neighbour." It copies your taste instead of guessing at it.
Make it think out loud (chain-of-thought). "I'm choosing between two flats. Walk through commute, cost, and daylight step by step, then tell me which one and why." Forcing the thinking first beats a snap answer.
Break the big thing into steps (decomposition). Planning a five-day trip becomes: rough day-by-day, then one day in detail, then the packing list. Small steps you can check.
Ask for the plan, then the work (reason then act). "Tell me how you'd structure a monthly budget for an irregular income, then build it as a table i can fill in."
Have it check its own answer (self-critique). "Reread that message to my landlord and flag anything passive-aggressive, then give me a warmer version." The easiest quality check there is.
Keep improving, and save what works (iterate). Tell it exactly what was off, teach it your taste, and save the asks that work so you can reuse them.

If you only remember three: ask clearly for the simple stuff, make it think out loud for anything you are deciding, and have it check itself before you send anything that matters.

The seven, one line each. This is the cheat sheet.

Your own notes are the best place to practice

You learn this on your own life, not from a course. I keep what people call a second brain, a plain folder of my own notes that the AI can read, and it is the best practice ground i have.

Try the smallest version. Drop a week of messy notes into one place, then ask: "group these into themes, tell me what i keep circling back to, and what i seem to be avoiding." Giving it your real material instead of a blank question is patterns 1 through 7 at once. If you want the full setup, i wrote up how i built mine with Obsidian.

Ask, read what came back, steer, save what works. Then again.

Where a better question stops helping

Asking well fixes one conversation. It does nothing about the fact that the AI forgets you the moment you close the chat. That is where the work moves from the question to what is around it: giving the AI a memory it can read, which is exactly what a second brain is for. That is the next part of this series.

How to get good: practise on your own life

Try, look at what came back, adjust, go again. When an answer is bad, read it instead of deleting it, because it is telling you which of the four things you left out. And when a way of asking works, hand it back to the AI: "write me a cleaner version of this prompt i can reuse." Using the AI to improve how you talk to the AI is the fastest way i know to get good.

The seven live on a one-page cheat sheet, plain language, ready to copy. Grab it free here.

I'm Malik. I build with AI every day and write about using it well, minus the hype. This is part 01 of Using AI, properly. Next: giving the AI a memory. New parts land first at codemeetai.substack.com.

Your AI agent checks its own work. That's not a loop, that's a confident intern with a cron job.

Malik Chohra — Sun, 05 Jul 2026 16:24:29 +0000

TL;DR: a loop is memory + rules + verify + schedule. Most agent setups have three of the four. The one they skip is a separate verifier, and skipping it means the agent that does the work also grades the work. That is the difference between self-correcting and self-confirming.

This piece is from Code Meet AI, my newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first.

I run background AI agents on a schedule. For months I was quietly proud of the setup, until I lined it up against what a real loop actually requires and found I had skipped the one part that makes it trustworthy. If you have any agent running unattended, this is the question I had to ask myself, and you should too.

The ladder, fast

Prompt engineering tuned the words. Context engineering got the right things into the window. Harness engineering is the scaffolding around the model: tools, rules, sandboxes (I mapped the harness floor here). Loop engineering is the floor above, the harness running on a timer, spawning helpers, feeding itself. Each layer wrapped the last. Nobody got replaced, the edge just climbed a floor.

A loop has four parts

Memory it reads before acting and writes after. Rules it cannot break. A verifier that confirms the output before it counts. A schedule that triggers the cycle. Memory, rules, verify, schedule.

Where I told on myself

Three indexing layers per project, a curated memory bank, a structural index of what imports what, a temporal recall layer (the full second-brain setup is here). Background agents on a schedule on top.

Count it against the four parts. Memory, yes. Rules, yes. Schedule, yes. That is three. The fourth is verify, and I did not have it.

I never built a separate checker. The loop produced work and then trusted its own work. No second model, no sub-agent whose only job is to read the output and return true or false. The agent that does the work also decides the work is fine. In any human process you would flag that conflict of interest immediately. In an automated one it is somehow the default.

That is the whole point. Memory plus rules plus schedule gives you an agent that runs a lot. It does not give you an agent you can trust to run unattended. Verification is the difference between self-correcting and self-confirming.

What verification actually means

Not the agent re-reading its own output and saying "looks good." A separate checker: a sub-agent or a second model, given the acceptance criteria of the goal, whose only output is true or false against a defined end-state. It does not see the reasoning that produced the work, it sees the work and the spec. That independence is the entire value. If you build one thing this week, build this, because it is what makes the rest safe to leave alone.

The governance angle most people miss

The loop does not know what you are using it for. Two teams build the identical loop and get opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. Same files, same cron line, same checker, opposite outcomes. The responsibility moved up a floor alongside the capability.

So, the one question: who checks the output? If the answer is "the same agent that wrote it," you do not have a loop. You have a head start.

I packaged the skeleton I am using to close my own gap, the memory bank, the rules file, a goal with a verifiable end-state, the checker sub-agent, the schedule, and guardrails so it cannot run off a cliff. It is free, name your price: the Loop Engineering Starter Kit. The deeper write-up, with the diagrams, is on Code Meet AI.

I lean on these loops daily building Wire AI, my generative onboarding SDK for React Native, where unverified agent output would land in front of real users.

I write Code Meet AI: real AI workflows, real numbers, from someone shipping with it every day.

How are you handling verification in your own agent setups? I am still wiring mine in and would take notes from anyone further along.