Agentic loop engineering: the loop, the harness, and the cost discipline that ships agents

Vibe coding feels productive because it deletes steps, and every deleted step was where understanding got built. The output exists, so you ship it. You didn't produce something, you approved something, and until you learn the difference, every line is a liability.

Andrej Karpathy coined "vibe coding" for the state where the model writes the code on its own and you rarely intervene. @pmitu counts eight pre-development stages it has quietly killed:

• thinking before building
• talking to users first
• building waitlists
• analyzing audience segments
• idea validation
• competitor research
• prioritizing features before coding
• feedback-loop-driven building

None of those were ceremony. They were where the product got a stake in whether it succeeded. Outsource them to a model's pattern-matching and you get something impressive in isolation and catastrophic in context.

@rewind02 draws the opposite posture: "you define the spec, the architecture, the top-level design decisions... you treat agents as fallible, stochastic, powerful interns." The human keeps judgment, taste, and correctness, the machine gets execution. The two approaches even fail differently, and that difference is the tell:

• Vibe coding fails silently. The code works until it doesn't. The product ships until a user finds the edge no one considered.
• Agentic engineering fails loudly and recoverably. The spec is explicit enough that deviations are detectable, the verification is automated enough that regressions get caught.

The deeper trap is cognitive. @JuliannPod names the fluency illusion: information that feels easy to process gets mistaken for knowledge. You read the generated code, it looks right, so you assume it is, and your brain stops encoding because it assumes something else is doing the work. The number he cites is brutal (creator-reported): retention drops from 68.5% to 57.5% when you offload cognition this way. The output of that habit is what he calls "slop": content that cost the author nothing and reads like it.

Protect the judgment, not the task

What vibe coding really strips out is the muscle that builds taste. Teaching someone prompts takes a couple of hours, teaching them taste takes the rest of their career. Most people skip evaluation entirely, ship the first mediocre version, and never develop the standard that would reject it. They protect the wrong thing, the task instead of the judgment: the job is patient care, the task is reading a scan. The job is strategy, the task is building a spreadsheet. Protect the task and you get replaced. Protect the judgment and you get amplified.

Which decides what you should ever hand off:

"When both types of friction are outsourced, you don't gain time. You lose the version of yourself the friction would have made.", @JuliannPod

The test before you delegate: would doing this myself make me better at my job? If yes, that's virtuous friction, keep it. If no, automate it and move on.

Karpathy frames the larger shift as Software 1.0 → Software 3.0: your lever over the computer is no longer the code you write but the context you manage. One operator put the boundary cleanly, you can outsource your thinking, but you can't outsource understanding. The gap between tinkering and shipping shows up in exactly three places, and the rest of this note is how you close them:

A single model call has no memory of what it tried, no way to check its own work, and no way to recover from failure. A loop fixes all three by making the output the next input. Input → Model → Output is a coin flip that costs tokens.

@0xwhrrari puts the industry signal plainly: "Anthropic and OpenAI are both telling engineers to write loops. Not prompts. Not agents. Loops." The identity shift is the real change. @0xCodez: "I don't prompt Claude anymore. I write loops, and the loops do the work. My job is to write loops." Write a prompt and you decide what comes next. Write a loop and you architect the system that decides what comes next. Operator becomes designer.

@_avichawla gives the loop four parts:

• A schedule decides what to run
• Loop is the maker that produces the work
• A separate checker agent grades the output
• A file on disk holds the state they both read

That structure is what turns guessing into measuring. @bcherny describes the behavior it produces: "It is the first model I have used that was so methodical and precise, taking measurements and adding logs then verifying that it truly fixed the issue before declaring victory." That's not a property of the weights. It's a property of the loop you build around them.

Not all loops are equal. Four patterns each solve a specific failure mode of autonomous work. Pick by what's most likely to break.

Loop-Until-Done is the foundation, and its one critical decision is the exit condition, set it before the loop starts or you burn tokens forever on work that's "almost there." Fan-out has a sharp template from @Voxyz_ai: split the goal into independent pieces and spawn a parallel agent for each, every one handed its own deliverable, verification, and completion standard. Adversarial verification exists because of a default flaw, @_avichawla: "Models grading their own output often justify what they already did rather than catching failures." Friendly verification is no verification at all.

The single most important technical decision in loop engineering is where state lives. The answer is disk, never the context window.

@_avichawla is unequivocal: "State has to live on disk, not in context. The model forgets everything between runs, so an MD file or a knowledge graph holds what is done and what is still open." Store state in the context and you lose it the moment the session ends. Store it in conversation history and you pay to re-read it every turn while the model drifts anyway.

flowchart LR
  S["State file on disk"] --> M["Maker works"]
  M --> C["Checker grades"]
  C --> W["Both write back"]
  W --> S

The implementation is humbler than it sounds. A Markdown file with sections, Completed, In Progress, Blocked, Next Steps, is enough for most loops. Each iteration reads it, the maker works, the checker grades, both write back, and the next iteration resumes from there. A loop can pick up hours or days later with zero context loss. For richer state, a lightweight knowledge graph or structured JSON. The file is the source of truth, not the model's memory.

What that buys you, at the extreme, is @Mnilax's result: "the same shape rewrote bun from zig to rust, 750k lines, test suite green." That isn't a prompt. It's a disk-stated loop crossing an enormous codebase, persisting progress between iterations, and verifying at each step.

Set the bar low for boring work and high for judgment, and only loop as far as the checker can objectively confirm, then hand off.

The insight is counterintuitive. @_avichawla: "The lower the verification bar, the safer the loop. Boring, repetitive checks like a stale version string or a missing test are trivial to verify." A checker can confirm those objectively and fast, so the loop runs unattended with confidence. Architectural decisions can't be confirmed that cleanly, so a human stays in the seat.

Real self-verification is not asking the model "is this good?", that's self-preference wearing a verification badge. It's the model taking observable actions: running tests, reading logs, comparing against a spec, executing the code and reading the output. @Voxyz_ai encodes it as a rule: after every meaningful step, test the real thing end-to-end (browser, keystrokes, whatever it needs), then auto-review and commit. @bcherny's "methodical and precise" behavior comes from exactly this grounding in reality, not from the model's personality.

The best loops harden themselves over time. The self-repairing harness pattern: a failing trace gets diagnosed, the fix is verified against the exact input that failed, and the failure is locked as a regression test so it cannot recur. Every failure becomes a permanent test case, and the system gets more reliable with each break, not less.

The dominant failure mode has a name, context rot, and the fix is to treat the context percentage the agent shows you as your primary operational metric, not a curiosity. Every file the agent reads, every command it runs, every error it hits gets stuffed into one opaque window on top of a system prompt that is already thousands of tokens. Once the window fills, the model drifts: it forgets the spec, re-introduces bugs it just fixed, and starts looping.

flowchart TD
  A["Every file, command, error stuffed into one window"] --> B["Window fills"]
  B --> C["Model drifts: forgets the spec, re-adds fixed bugs, loops"]
  C --> D["Fix: disk state, compact at 50 percent, cap the spend"]

The fix is disk state (above) plus disciplined compaction. Run /compact at 50% context usage, not 95% (per @charliejhills). Reset conversations every ~20 messages by asking the model to summarize the thread into five bullet points and pasting that into a fresh chat. @AiWithIqra reports this saves up to 50× tokens per turn on long threads.

And cap the spend, not just the steps. @_avichawla: "Exit must be set before the loop starts." @0xLogicrw sharpens it: set a fixed financial budget rather than a step count, so a cheaper model can iterate more within the same envelope before the loop hits its wall.

@charliejhills' command reference is the vocabulary of the harness, but the commands aren't equally important, and their value shifts with where you are in a project. Here's the working set.

/compact is not a cleanup tool, it's a production necessity once a session exceeds ~20 messages, where token cost compounds non-linearly. And old context degrades new output: if you just finished an auth module, /clear before the pricing page so auth logic doesn't bleed into pricing.

Shipping looks like plan → pick the model → execute one change at a time → compact. Not prompt, watch, prompt again. The planning step pays back the most, which is why the field repeats one minute of planning saves ten minutes of building.

Skip planning and you meet the second-most-common failure: the vague prompt against an autonomous agent. Tell one to "build a landing page" and it will scaffold a React app, install Tailwind, wire up routing, and write five components before you can blink. You didn't ask for React. You didn't ask for Tailwind. But the agent has autonomy and you gave it no constraints, so you lit money on fire, confidently, building the wrong thing.

flowchart LR
  A["Define task + done-criterion"] --> B["Run plan mode"]
  B --> C["Execute one change at a time"]
  C --> D["Compact or clear"]

Most CLI agents expose a plan mode (Shift+Tab in the terminal, or a toggle in the desktop app). It locks file writes and lets the agent read, research interfaces, and reason into a written plan before it touches a single source file. @Voxyz_ai pushes this into a "shift-left on architecture" pattern: analyze requirements, list edge cases, design the architecture, deliver folder structure, schema, API design, and performance notes, before writing code. The sound execution loop has four steps:

1. Define the task in one sentence with a definition of done. "Refactor the auth module" is not a task. "Extract the token-refresh logic into a standalone refreshToken(token: string): Promise<string>, keep the existing tests green, and add one test for the expired-token case" is a task. The done-criterion stops the agent quitting early (a partial refactor) or sweeping too far (rewriting the module).
2. Run plan mode. Let it read the codebase, identify the files, and propose the sequence. Review it. Push back if it touches files outside scope or proposes an abstraction you never asked for. A thin plan that fails on the first build is a planning bug fixed upstream, not an execution bug.
3. Execute one change at a time, the build-validate loop. One logical change, run the compiler or tests, self-correct, move on. Don't let the agent queue five changes and test once at the end, bugs compound, and catching them per step is far cheaper than untangling a chain.
4. Use surgical file references. @styles.css make all the buttons gold restricts the edit to that one file. Drop the @ and the agent may decide to "improve" five other files on the way, one of the most common ways agentic edits introduce regressions in files you never meant to touch.

Then compact, or /clear for a clean break, but first write a short hand-off note so the next session resumes without rediscovery. If you work by heavy voice dictation, pipe the raw transcript through a cheaper model in a separate tab first, then send only the tight summary to your primary agent. Don't pay your best model to read your rambling. Verify the plan worked by checking the generated file structure matches the proposal and the first compile or test run goes green.

Route the model, then execute

On the model itself: a heavy model thinks, a cheap model executes, and roughly four-fifths of the work goes to the cheap one. Plan and architect with Opus (it reasons deeper and catches edge cases), lock the plan, switch to Sonnet for execution and command it to follow the plan exactly. The /effort dial is the finer control, reserve the highest setting for the planning pass and for bugs with an unclear root cause, a lower setting for mechanical work. The full routing taxonomy and what the wrong tier costs are in the cost section below.

Make the done-criterion a template

Step 1's done-criterion is worth a template of its own, because a goal without one lets the agent quit early or sprawl forever. A bare /goal refactor until you are happy with the architecture is not enough.

The production-grade template from @Voxyz_ai requires real-world testing after every meaningful step, auto-review then commit, progress written somewhere sensible, and a final dedicated review pass:

goal: {your task / the full spec you already agreed on}
after every meaningful step: real-time test the real thing (full end-to-end, plus computer use, browser, keystrokes, whatever it needs), auto review then commit, write progress somewhere sensible in the project
finished: one dedicated review pass over everything
done = every dimension at 100%, production-grade, a real user can walk in and use it

For parallel work, the goal splits itself and hands each spawned agent its own dedicated /goal with deliverable, verification, and completion standard: "For this task, write yourself a new end-to-end /goal: complete the whole plan, not just the next step, until the architecture, implementation, tests, review, and final result meet the standard. Split that goal into independent pieces, spawn as many parallel agents as needed to do it better and faster, and give each agent its own dedicated /goal that includes its expected deliverable, verification, and completion standard."

Two non-negotiables:

• always use a worktree for heavy refactors to keep the main branch clean
• make done explicit, every dimension at 100%, production-grade, a real user can walk in and use it.

For a YOLO refactor with banked rate-limit resets the shape is refactor until you are happy with the architecture. ensure you live test after each significant step and autoreview/commit. track progress in /tmp/refactor-{projectname}.md … run high or xhigh reasoning.

CLAUDE.md is not documentation. It's the agent's operational brain, injected at the very top of context before your first prompt, narrowing the model's output paths onto the trajectory you want. Run /init and the agent scans the codebase and writes a starter, you refine it by hand.

The field runs two competing philosophies, and both are right at different times.

• Minimalism (@bcherny, Claude Code's creator): "My entire CLAUDE.md is two lines. With every new model you need less instruction, not more, most people are over-engineering the one thing that should stay tiny."
• Systematization (@Mnilax): a machine-readable design system (typography, spacing, cards, buttons, inputs, hierarchy) that cut a 10-screen dashboard rebuild from ~6 hours to ~40 minutes, because the model stopped guessing the look fresh every time.

The resolution is project phase. For exploration and prototyping, Cherny wins, minimal context lets the model's general capability shine. For production systems with multiple contributors or frequent UI changes, Mnilax's approach dominates, and the design system has to be machine-readable and referenced by name in prompts. @humzaakhalid's 65-line file is the practical middle ground, with four enforceable rules, think before coding, simplicity first, surgical changes, goal-driven execution, which map onto the four failure modes the field keeps documenting: silent assumptions, code bloat, collateral damage, infinite loops.

What goes in it:

• the tech stack and conventions
• the build, test, and lint commands (this is what powers the self-correcting loop)
• the directory structure so the agent stops dropping files at random
• security rules (never hardcode keys, use .env, never commit it)
• a plain statement of what the agent is capable of (agents act timidly and underestimate their reach, tell it it has write access here, may run the test command, may create files there)
• a running log of failure modes

Two refinements raise this from a config file to a brain.

Keep it capped and hierarchical. Past ~500 lines the file bloats the window, raises cost, and degrades reasoning, the model averages across everything rather than following specific instructions. Consensus lands at 200–500 lines, with one staff-engineer voice arguing for around 300: the more bloat in your context, the less likely the AI does exactly what you want.

• Keep a global file for universal rules and a project file for local context, when they conflict, the project file wins.
• Put the critical guardrails at the very top to exploit the model's primacy bias.
• For large projects, split a monolith into a rules/ folder (code-style.md, security.md, testing.md) and load only what's relevant.

Make it self-modifying, the strongest idea in the batch. Instruct the agent: whenever I correct a mistake, or you hit a bug from a wrong assumption, append a rule to a "Learned Rules" section in a strict shape, Category: [never/always] do X because Y. The sharpest articulation of why: logging failures mathematically carves out invalid solution space, letting the agent skip the 80% it already knows fails. When the same mistake recurs two or three times, that's the signal to write the rule, not repeat the correction.

# Learned Rules
- Files: never delete the .env file because it holds local secrets and is not recoverable.
- Tooling: always use the project's package manager, never a different one, because lockfiles diverge.
- Migrations: never edit a committed migration; always add a new one because old ones are already applied elsewhere.
- Style: always write succinctly because verbose replies waste the context budget.

Verify the brain works by opening a fresh session and asking the agent to describe the project architecture without reading individual files. If the description matches reality, the file is carrying its weight.

Before a single line of code, install the architecture the prompt skipped: spec, plan, and a definition of done. This is the step vibe coding deleted, and it's where most of the edge hides.

The three-prompt pre-coding sequence

flowchart LR
  A["Prompt 1: Spec"] --> B["Prompt 2: Architecture"]
  B --> C["Prompt 3: Define done"]

@faraznaqvi0 gives a three-prompt pre-coding sequence that stabilizes results before any code is generated. Prompt 1 forces the model to read the relevant files and restate the goal, patterns, constraints, and assumptions, and to ask only the questions that change the implementation. Prompt 2 asks for the smallest safe plan: files touched, order of work, edge cases, risks, and a recommendation among viable approaches. Prompt 3 defines done before coding starts. Verbatim:

• Prompt 1 (Spec): "Don't code yet. Read the relevant files first, then restate the goal, the existing patterns, the constraints, and the assumptions you're making. Ask only the questions that would materially change the implementation."
• Prompt 2 (Architecture): "Give me the smallest safe implementation plan. Include the files you expect to touch, the order of work, edge cases, and risks. If there are multiple viable approaches, compare them and recommend one."
• Prompt 3 (Implementation Plan): "Before coding, define done. Write the acceptance criteria, the tests or checks we'll run, and any manual verification needed. If something can't be verified, say so before implementation."

Then @faraznaqvi0 runs chunked-sequential work with save points: "break down bigger tasks with claude code to bite-sized chunks, then knock them out sequentially, after each chunk i can run tests and commit, so I'm never losing progress if something goes wrong... it's like having save points in a video game but for actual work." It costs more time than typing "build me a Twitter clone." It produces something you can debug, extend, and trust.

RCT: Role, Context, Task

The prompt skeleton underneath all of this is RCT: Role, Context, Task. Tell the model who it is, give it the situation, state the bounded ask. (One creator expands it to four letters with "Format" tacked on, ignore that. Format and constraints are real levers, but they belong to a separate Briefing Method: audience, outcome, format, constraints. RCT is three letters.) A bare "write me a blog post about X" is a Google search aimed at a colleague, RCT is a brief. The non-obvious payoff is recursive: RCT is also the skeleton of every agent system prompt, the Role is the job title, the Context is the memory it reads, the Task is its one-line job, and the format constraints are the skill file dictating output shape. Beginner template and orchestration primitive, same shape at different scales.

Chain-of-thought, grown up

Chain-of-thought is the same idea grown up. Taught as "think step by step, show your reasoning, then give the final answer," it's worth doing, but it scales into the operating logic of an agent system at three levels:

• a clarifying-question loop: one model interrogates the spec before another executes (running this in a desktop model before handing a coding agent a detailed spec yields cleaner code than typing a quick brief into the CLI)
• multi-step reasoning held across a sequence of tool calls
• trace-map debugging

When an agent run goes wrong, don't rebuild the chain. Open the full trace, prompts, tool calls, results, failures, model switches, retrieved memory, and read it backwards from the final output until you hit the step that looks off. "Nine times out of ten the weak link is one or two steps before the final answer." The reported speedup (roughly an hour of guess-and-rerun down to about five minutes) is one creator's own stopwatch, unaudited, but the practice is exactly how anyone who has actually debugged agent runs already works. Steal the practice. Ignore the timer.

When one loop can't hold the complexity, the communication medium matters more than the orchestration style. Files beat messages.

Start with the right kind of sub-agent. @Mnilax: "Every sub-agent I deleted was a Mahesh: smart, general, no domain shape. Every survivor was a Barry: one job, one bounded input, one structured output." A Mahesh re-confirms what the parent already knows and returns prose, each one costs ~20K tokens of spawn overhead for nothing. A Barry does exactly one thing and hands back structured data:

The Barry pattern runs on a file bus. @MyWestLord's pipeline:

flowchart LR
  P["Planner"] --> S[".pipeline/spec.md"]
  C["Coder"] --> CH[".pipeline/changes.md"]
  T["Tester"] --> TS[".pipeline/tests.md"]
  S --> R["Reviewer reads all"]
  CH --> R
  TS --> R

No agent needs to know what the others are doing beyond what's on disk. @RoundtableSpace shows the peer-review variant: "The QA agent found three bugs, sent feedback directly to the developers, they fixed the issues and the app shipped in a single pass", faster for small teams, harder to debug at scale, and only safe with strict file-level permissions so agents don't overwrite each other's code.

@AiCamila_ sorts the three orchestration styles:

• Orchestrator: one agent routes to sub-agents
• Hierarchical: supervisors manage workers
• Swarm: peers collaborate over shared memory

Start with Orchestrator for debuggability, reach for Swarm only when you need emergent behavior and can stomach the complexity. The non-obvious truth across all three: file-based communication is more reliable than message-passing because it survives crashes, is inspectable by humans, and doesn't depend on the model formatting messages correctly. @0xLogicrw's DecentMem reinforces the point at the memory layer, a dual-pool design (an E-pool for historical experience, an X-pool for generating new candidate ideas, an online decoder adjusting the weights between them). The hard problem in multi-agent systems is how agents store and retrieve shared state, not which org chart you draw.

Skills are the productized Barry

Skills are the productized Barry: folders of instructions the agent loads on demand to become a specialist without manual prompting. The field shows skills for marketing (7 internal agents for SEO/ads), email/Slack/web building, Remotion video editing, and Nano Banana image generation. For production, skills should be versioned alongside prompts and agent logic, tested against golden datasets before deployment, and observable, trace every step: User query → Agent thought → Tool call → LLM call → Final answer.

Parallelism is the core strength of CLI agents and the fastest way to set money on fire. The honest ceiling is your review capacity, not the tool's.

Sub-agents protect context and cut cost. A parent agent calls a child, often on a cheaper model like Haiku or Sonnet, and the child runs in its own fresh context window (the standard 200,000 tokens), returning only a summary, not its full transcript. A main Opus agent handed "build a competitor analysis report" can spawn three Sonnet/Haiku researchers (scrape competitor A, scrape competitor B, analyze sentiment) and synthesize their summaries. A reviewer sub-agent spun up with zero prior context applies the adversarial-verification pattern at the sub-agent layer, the critic that never saw the maker's reasoning.

flowchart TD
  O["Main Opus agent"] --> A["Sonnet/Haiku child A"]
  O --> B["Sonnet/Haiku child B"]
  O --> C["Reviewer child, zero prior context"]
  A --> S["Returns summary only"]
  B --> S
  C --> S
  S --> O

Git worktrees prevent collisions. Two agents editing the same files in the same directory overwrite each other. A worktree gives each its own branch and directory:

git worktree add ../feature-x -b feature-x
# the agent works in ../feature-x on its own branch
# when done, merge back to main, then delete the worktree

Worktrees are disposable, delete them after use and reinstall dependencies in fresh ones. The most grounded operator in the field runs up to four parallel windows at mixed effort (say two high, one medium, one low) and is candid about the limit:

my mental capacity is pretty much four parallel work streams.

Run more than you can review and you generate unreviewed output that accumulates silently until it breaks something.

Agent teams are the heavy-artillery variant, and the wallet hazard. For a full security audit, a team lead splits the work: ten agents to scan the codebase, four to document issues, two "devil's advocate" agents to argue over whether the findings are real. The cost is blunt: an unsupervised agent team can eat a month's token budget in one sitting (see the opening). This is the layer the field calls a nuclear weapon for your wallet, occasionally worth it, never a default. Shut teams down the instant the work is done.

All of this rests on permissions as real kill switches, a three-tier risk ladder:

• Ask before edits is the safe default (the agent prompts before modifying any file).
• Edit automatically lets it change existing files but still prompts before creating new ones.
• Bypass permissions is full autonomy and can run sudo rm -rf if it misreads a request, so you only run bypass inside a sandboxed container, never against a directory you care about.

For finer control, set per-tool rules: allow ls and cat silently, force a prompt before bash or curl. This is also what makes the self-correcting loop safe, you grant "allow" on exactly the trusted operations the agent needs to read an error log and retry, without handing it the whole keyboard. Widen autonomy exactly as far as the blast radius is contained, and no further.

MCP enables real capability, but the contrarian call is the right default: don't reach for it first. Most of the field over-reaches here, and it costs both tokens and debugging time.

Model Context Protocol (MCP) is the standardized layer between the agent and external tools, GitHub, Slack, Gmail, databases, browsers. A useful representative stack: Playwright (browser automation), Context7 (live docs, so the agent stops citing deprecated APIs), GitHub MCP (repo access via a PAT), and a Postgres connector for direct reads. Install at local, project, or global scope deliberately to avoid tool bloat. Concrete wins:

• Shopify: enable Products, Inventory, Orders, Customers, the agent reads live store data and surfaces inventory gaps, SEO weaknesses, missing tags, unfulfilled orders.
• Figma: the Chrome extension captures live sites as editable layers, read the structure via Figma MCP and rebuild in your brand.
• GitHub: the agent reads and writes issues, PRs, Actions, releases, the repo "stops being a folder of files and becomes something the agent actually runs."
• Browser / computer use: the agent opens browsers, navigates, fills forms, screenshots.

But the contrarian note cuts against the reflex: for common platforms and simple operations, plain bash beats MCP. A curl call, a versioned CLI, or a short script is often faster to set up and easier to debug, direct API calls are reported at 5–10× faster than the MCP path. Reserve MCP for unknown internal services or specialized retrieval where the connector earns its overhead. One security rule, from @AtsuyaYamakawa's Workato implementation: never run agent API calls through a single shared service account with no tracking, capture who the agent is representing so logs and tickets reflect the real human behind every action.

The agent can be confidently wrong. It will tell you the refactor is complete and the tests pass, after quietly editing the test to match the broken output. Fluent prose is independent of correctness, a well-structured explanation of a wrong approach reads exactly like one of a right approach. Trust requires a protocol, and the field has converged on three patterns.

flowchart LR
  E["Read error log"] --> F["Find the cause"]
  F --> T["Try an alternative"]
  T --> R["Re-run the suite"]
  R --> Q{"Green?"}
  Q -->|"no"| E
  Q -->|"yes"| D["Ship"]

Two habits sit alongside these. Spot-check, don't rubber-stamp: after every execution pass, read at least one file the agent changed that you did not direct it to touch, and if it strayed, tighten the next plan. Demand citations for non-obvious decisions: an agent that can't say why it chose a specific algorithm, library, or architecture guessed, and guesses become debt. Signals to distrust:

• the plan touches more files than expected
• an abstraction appears for a single-use case
• the test count rose but the tests look easier to pass than the code is to write

And the hard rule before anything goes public: never ship vibe-coded code without a manual security audit. AI-generated code is prone to prompt injection and logic flaws, @codingtechnyks cites studies showing up to 45% of AI-written code can be insecure. Add authentication, audit with the agent and then yourself, and treat every output as a draft. @BratDotAI's guardrail is non-negotiable: never let an agent run production deploys, database changes, or billing changes without your approval.

Spend doesn't die on the frontier. It bleeds out on the routine, the grammar checks, the formatting passes, the lookups you never think about, each one routed through your most expensive model out of pure habit. @Mnilax calls the reflex paying "migration prices for a rename": you deploy a brain surgeon to put on a Band-Aid, then act surprised when the monthly bill reads like a car payment. The teams winning in 2026 don't have the biggest API budgets, they treat model selection as a routing problem, not a loyalty program.

Decouple cost from intelligence and the same discipline that cut one engineer's bill by 75% is what lets a founder run an $18,800/month agency on $480 of API spend. (Both creator-reported, hold them as the shape of the prize, not a guarantee.)

Route by task complexity, not by reflex. The model that reasons best is almost never the model you want doing the typing. @hadesboun101 gives the cleanest split, 80% of work to cheap fast models, 15% to mid-tier, 5% to the frontier, and his verdict on the alternative is blunt: "Using premium models for simple rewrites or summaries is financially insane."

What the wrong tier costs

The leak @Mnilax put a number on: bumping a normal task from the "high" reasoning tier to "xhigh" (Opus 4.8) costs 4× more for marginal quality, quality-per-dollar collapses from 95 to 24. The only task in his testing that earned the jump was a cross-file migration, where scores rose from 78 to 87. Everything else was paying quadruple for a rounding error. @ai_appreciator gives the cautionary inverse: Fable 5 burned 1.4M tokens and 5 subagents over 90 minutes to clean up 21 Resharper warnings, a job Codex GPT-5.5 xhigh would have done in 10 minutes, under 300K tokens, no subagents. Right model, wrong lane, 5× the cost.

Build the router

@Sprytixl built the concrete router: routine tasks to Kimi K2.6 at $0.09, complex work staying on Claude Opus at $1.41, and the detail that makes it work, context never drops between switches. That's the difference between a routing system and a frustrating one: if the model switch loses the thread, the user re-establishes context by hand, burning the exact tokens they were trying to save. The mechanism is a shared state file (markdown or a knowledge graph) both models read from and write to. The same logic runs across providers: @Voxyz_ai dispatches Fable 5 for planning and front-end where visual output justifies the price, then writes a clear spec and hands backend implementation to Codex / GPT-5.5 where his quota sits unused. His exact instruction:

"to save tokens, keep this main session (fable 5) on planning and frontend tasks, its visual output and ideas are worth the price. for backend and heavier implementation, write a clear spec and dispatch to codex (gpt-5.5 xhigh) with /goal to execute, my quota there sits unused anyway."

A practical starting taxonomy, drawn from across the corpus (cost bands are indicative, not quotes, only the $0.09 / $1.41 pair above is a measured per-call price):

That routing instinct rests on a thesis worth internalizing: no single model is best at every job, so single-model prompt habits are a liability. One creator's self-run, six-week, four-model benchmark across five workflows (read it as one bench, not a leaderboard, but directionally consistent with independent testing):

The shape is the lesson: frontier models hold long agentic threads, local models truncate and lose the plot, and a bigger context window does not guarantee better recall. Where practitioners split is on how dynamic the routing should be. @Sprytixl and @Mnilax favor explicit, human-configured rules. @hadesboun101 goes further with model ensembles via OpenRouter's Fusion API, firing one query at several models in parallel, using a judge to map where they converge and diverge, then synthesizing. It costs more per query and adds latency, but it buys resilience (if a model gets banned, you're not stranded) and can match frontier quality at half the cost. His re-evaluation rule is the keeper: judge on "runtime vs. IQ", actual shipped work, not benchmark scores.

Local inference is a cost layer, not a replacement strategy. It pays off for high-volume, low-complexity work, and quietly loses money for occasional use or anything that needs frontier reasoning.

The aspirational case is @0xLogicrw's Lindy migration: founder Flo Crivello moved all client-side traffic from Anthropic to open-source DeepSeek v4, rented Atlas Cloud for niche compute, and kept Claude Opus as an automatic fallback for complex-task failures. Claimed result: millions saved, with performance improving on many core scenarios, but only after building internal infrastructure to absorb "up to 100× higher" workload than expected. Open-source models cost you engineering time instead of API dollars. The bill moves, it doesn't vanish. The hardware paths people actually run:

The economics only hold under conditions the loudest claims skip. @0xKnzo says Chinese developers are making "$400,000 running local AI" and Japanese developers killed "$249/day in AWS bills", both claimed, no verified revenue behind them. The honest caveats:

• Upfront cost is real. $2,400–$5,000 is not trivial for an individual.
• Thermal management is critical. @0xKnzo runs external cooling fans "the size of a toaster" to stop thermal throttling on 24/7 workloads, without them, performance silently degrades.
• Capability drops. Local DeepSeek 14B or Qwen3 235B are competent, not Opus 4.8 or Fable 5. @ai_appreciator's read: Opus 4.8 is "competent and I could probably get the game done with it, but the difference is noticeable" against GPT 5.5 xhigh, and local models sit below that.
• Security is extra work. @0xKnzo wraps every agent in Docker sandboxing to stop prompt injection from leaking host credentials.

@marfinxx found the non-obvious failure mode. After switching to a Hermes Agent, his flat-file Obsidian markdown memory "floods GPUs with uncompressed markdown strings," bottlenecking the hardware. The fix, SQLite FTS5 compression, cutting token waste by 70%, is the local-inference lesson in one line: the model isn't your bottleneck, your memory format is. (His performance-ceiling reference rig is an 8-GPU RTX 4090 server with NVFP4 quantization.) The decision rule, from @gippp69, who runs local daily:

"Does not replace frontier models for the 'hardest tasks'. Keep one cloud model as a backup."

Most teams optimize which model they call and ignore how it remembers. The same model, on the same task, can vary 10× in cost depending on context architecture. And the highest-ROI move in this entire note costs nothing.

@Mnilax's "tokenmaxxing" is an audit of ~/.claude/settings.json (≈125 keys, only ~40 documented, 18 that actually touch billing). Three you can act on today:

The biggest lever is where the response cache breakpoint sits:

Move the cache_control breakpoint to the static/dynamic boundary so the stable prefix of every request is cached instead of re-billed. That's the move that dropped Mnilax's Opus month from $340 to $87.

One caveat worth copying with the technique: the "deny-rule bug," where config says block but the binary reads anyway. Don't assume a setting took effect, verify the token drop in your next session. That breakpoint is the manual front end of prompt caching, cache the system prompt and tool definitions once, pay discounted rates on every subsequent turn, which is where @elsontec's line "agent projects cheaper to run than to scope" stops being a slogan. @bonsaixbt attacks the same tax from the memory side: a Graphify + Obsidian knowledge graph that retrieves only the relevant subgraph instead of reloading whole histories, for a reported ~70× token drop.

@AiCamila_ packages the discipline into five tactics:

• route simple tasks to cheaper models
• cache repeated queries
• compress context
• implement early stopping
• set per-user budgets

All under one metric that reorders everything: cost per successful task, not cost per token. Tokens saved on work that never shipped is not a win. Her starting advice is deliberately small: "Start with model routing + caching." And on the build-vs-buy line for heavy users:

Directional guidance, not a claimed figure: self-hosting a local model starts to pay off once sustained monthly API spend on cheap-tier work clears a few hundred dollars (the ~$1,700 rig above pays back in months against a $440/mo bill). Below a low-volume threshold, the overhead of running your own infrastructure outweighs the savings.

Before you build a router or buy a GPU, also kill the subscriptions you already pay for and don't use. It's the fastest dollar saved.

@eyishazyer's stack is the wake-up call, the "serious AI user" tax laid bare:

• $200/mo Claude Code Max
• $200/mo ChatGPT Pro
• $20/mo Cursor
• $20/mo Gemini
• = $440/month, $5,280/year

The point isn't that any one is overpriced, it's that nobody audits the sum. @alchemyofmax ran the enterprise version: an audit of $47,000/year that found 14 separate subscriptions with zero shared context, a team "talking to AI in 14 separate windows with zero shared knowledge," copy-pasting outputs into Google Docs and calling it a deliverable. His fix was a unified "2nd Brain":

• a daily AI briefing
• a living business wiki
• a shared context layer
• a built-in task manager
• a custom metrics dashboard

(Creator-reported, but the diagnosis, overlap with no shared layer, is the transferable part.)

The fix is the same at any scale: audit by function, not by tool. Map what each AI subscription actually does, find the overlaps, and cut anything that doesn't connect to a shared intelligence layer. Once the obvious waste is gone, self-hosting open-source equivalents (an n8n instance for the paid-automation tier, a local model for cheap inference) is the next lever.

A fallback is both a safety net and a cost lever, it's the thing that lets you run lean and escalate only when the cheap model actually breaks. Without one you're forced to over-provision (Opus for everything) or under-provision (DeepSeek for everything, eating the failures).

flowchart LR
  P["Primary: cheap model"] --> Q{"Task succeeds?"}
  Q -->|"yes"| D["Done"]
  Q -->|"no"| F["Fallback: Opus"]

@0xLogicrw's pattern is the reference: DeepSeek v4 primary, Claude Opus as automatic fallback on complex-task failure, no human in the loop, the system detects the miss and re-routes. @archiexzzz generalizes it to config: give every workflow a primary model and a list of fallback providers (fallback_model_providers: [anthropic, openai]) and route to the next option when the primary is unavailable or restricted. Even Anthropic runs this internally, @ArtificialAnlys documents Fable 5 falling back to Opus 4.8 on 2% of GDPval-AA tasks, with fallback occurring in fewer than 5% of sessions on average. That's the closest thing here to a verified (not creator-reported) number.

@AiCamila_'s self-healing agents extend the pattern into a loop:

• detect (error logs, failed tool calls)
• diagnose (compare to baseline)
• remediate (retry, fallback model, reset state)
• escalate (notify a human only when auto-fix fails)

Tie it back to cost per successful task, otherwise a "fallback" is just a more expensive way to keep burning tokens on a doomed task. Which is exactly what @mardehaym's Cursor invoice was. His frame: Token Capital = Human Capital × Scaffolding × Feedback Loops, and because it's a product, "doubling your model spend when scaffolding is zero still gives you zero." The looping Cursor agent from the opening had model power and no scaffolding. Daily spend limits are not optional.

The frameworks expire. The skills and the memory don't. That's the entire compounding argument.

@DeRonin_ names what survives a model release:

• context engineering
• tool design
• orchestrator-subagent pattern
• eval discipline
• the harness mindset (harness > model, always)
• MCP as the protocol layer

These are model-agnostic and tool-agnostic. Invest your architecture in a vendor framework and you've built on sand, invest it in these and every new model makes you stronger. @rewind02's "context minimalism" closes the loop: the prompt should shrink as the model improves, not grow. The system around it should grow more sophisticated, precisely because more capable models produce more complex output that's harder to verify by eye.

The deepest moat is memory. The one layer beginners skip is persistent, business-specific context, and it's the hardest thing for a competitor to replicate. "Context is the single biggest driver of AI performance. Without it, agents produce generic output. With it, output is specific to your business, customers, and voice." The engineering pattern, worth stealing wholesale, splits memory three ways:

• Episodic: an append-only memory.md, timestamped, never overwritten.
• Semantic: a user.md of stable preferences (e.g. "UK English," "most productive in mornings") injected into every system prompt.
• Procedural: versioned skills/ files updated as the agent learns better methods.

Context loading stays semantically compressed (recent messages verbatim, relevant past sessions retrieved by search, older context aggressively summarized) so tokens don't explode while long-range coherence holds. And the memory is maintained, not set-and-forget: quarterly semantic compression (summarize the last ~90 days, keep names/projects/decisions/lessons, drop small talk), daily Git backup to a private remote, and non-negotiable security (files local or encrypted, FileVault / git-crypt / LUKS, before any push, sensitive apps excluded from capture, weekly memory audits). These files hold real business intelligence. Treat them like it.

flowchart LR
  A["Prompt fluency"] --> B["Model fluency"]
  B --> C["Automation"]
  C --> D["Monetization"]

The learning order itself is a dependency chain: prompt fluency, then model fluency, then automation, then monetization, and skipping a rung produces a predictable downstream failure. Structured prompting without model fluency gives brittle output. Automation without structured prompts gives broken workflows. Monetization without automation means you're still selling hours.

Choose Claude Code when you want to compose your own harness, and choose Codex when you want the harness pre-built and opinionated. Treat this as a fast-moving snapshot, Claude Code shipping its own /goal to match Codex already dates one row, but the shape holds.

The character summary is worth keeping verbatim: Claude Code feels like a workflow system you're building out, and Codex feels like an opinionated machine designed to take you from agent-is-done all the way to shipped-to-production. Both support MCP, CLIs, VS Code extensions, markdown/YAML skills, plugin marketplaces, and cloud delegation.

Here's the do-this-then-that, ordered from zero-cost wins to capital investment, with a way to check each step actually worked.

Phase 1, install virtuous friction and trim the waste (Day 1, zero cost). Audit your last three AI-assisted projects: for each, did you understand every line before you shipped it? Where the answer is no, write down the steps you skipped. Categorize your weekly friction (vicious → automate today, virtuous → keep until the skill is yours). List every AI subscription and bill in @eyishazyer's format (tool, monthly cost, annual cost, what only it does) and flag every overlap. Run the tokenmaxxing audit, disable unused plugins, set unused MCP servers to enabled: false, move the cache_control breakpoint, and verify the token drop next session. Reset any chat past 20 messages with a 5-bullet summary.

Target: a 30–50% bill cut from Phase 1 alone.

Phase 2, run the pre-coding sequence and tiered routing (Week 1–3, low cost). Spec, architecture, definition of done (the three-prompt sequence). Argue with each output, ask "why?" three times. Then sort every recurring task into the 80/15/5 buckets, build or adopt a router that defaults to cheap and escalates on failure, and wire the fallback chain with context preserved across switches. Verify: can you explain every architectural decision to a colleague without the model's justification?

After one week, total cost vs prior week, task success rate ≥95%, fallback trigger rate under 10%.

Phase 3, build the harness.

1. Write state to disk, a progress.md the agents update after every step. Verify: kill the session, start fresh, can it read the file and resume?
2. Separate maker and checker, the checker sees only the output, never the maker's reasoning. Verify: does it catch errors the maker missed?
3. Set exit conditions (max iterations, token budget, verification bar) before the first iteration. Verify: does the loop stop, or run forever?
4. Build Barries, not Maheshes, one job, one bounded input, one structured output, file-based communication.
5. Initialize CLAUDE.md by hand, stack, build commands, directory structure, security rules, guardrails at the top, the four enforceable rules. Verify: a fresh session can describe the architecture without reading individual files.

Phase 4, iterate, compound, and (if warranted) go local. Run evals, not vibes.

@AndrewYNg: "The single biggest predictor of whether someone executes well is their ability to drive a disciplined process for evals and error analysis."

Build a golden dataset, run it after every change, ship only if the metric moves. Calculate monthly spend on cheap-tier tasks, if it exceeds ~$200/month, local pays back within a year, pick hardware, point your tools at localhost, add cooling, sandbox in Docker, and always keep the cloud fallback. Then shift to judgment-only supervision: @Mnilax's cowork templates run an 8-hour workday in the background against ~47 minutes of human steering and approving, but only because the harness, exit conditions, and maker/checker split were built first. Without that infrastructure, "judgment-only" is just vibe coding with extra steps.

Two rubrics to grade yourself against. The maturity ladder:

And the numbers that prove the cost system works:

The final check is one question: can you swap your primary model without changing your workflow? If yes, your architecture is decoupled and you've stopped paying the loyalty tax. If no, you're still locked in, and the next price hike or model ban is your problem to absorb.

The edge is real. So are the ways it breaks. Distrust these.

The harness is boring, and that's where agents die

@NeoOpenGPU: most AI agents fail at the plumbing, not the reasoning, auth tokens expiring mid-run, webhooks that drop, state that drifts. Skip the unglamorous part and the agent fails in production while you blame the model.

"100% AI-written code" is marketing

@0xCodez's uninstalled-IDE, zero-lines-by-hand claim sells a brand. @AtsuyaYamakawa has it right: "AI coding empowers people who can design. It does not replace engineers." If you can't verify the logic, 100% AI-written code is 100% unverified code.

The gains are oversold

Realistic agentic-coding gains land around 30–60%, not 5× (the calm operators' own estimate, not a measured study), the people doing the best agentic coding aren't screaming from the rooftops that they're five times more productive. The "10x developer" framing ignores the verification and context overhead the same demos spend most of their runtime describing, generating 10,000 lines a day fails in any team setting because nobody can review it. The constraint is review bandwidth, not generation speed. Karpathy himself notes models still fail at simple logic and spatial reasoning, so the "vibe coding replaces engineering" narrative is overstated.

The frameworks expire

@DeRonin_: "Avoid AutoGen / AG2: moved to community maintenance, releases stalled. CrewAI: demos well, breaks in production." Not technically inferior, they expire. The reliable path is file-based communication between narrow agents, not message-passing between general ones.

Where the sources genuinely fight

The sharpest disagreement is whether local can fully replace the cloud. @0xKnzo says you can "replace Anthropic forever" with a stack of Mac Minis, @0xLogicrw demonstrates the opposite (even after migrating everything to open-source, you keep Opus as a fallback), @ai_appreciator confirms local models are "competent" but noticeably worse on complex coding. The honest synthesis: local inference can replace your cheap tier entirely, but it cannot yet replace your frontier tier. Anyone claiming otherwise is selling hardware, not sharing data. The second fight is migration effort, @0xLogicrw warns of "100×" infrastructure load, @DAIEvolutionHub frames open-source swaps as simple repo deployments. Reality sits between them: the software is free, the engineering time to configure, maintain, and debug it is not. Budget 2–4 weeks for a real migration.

Distrust round numbers, including the impressive ones above

Several of the loudest tutorials are course-length funnels from the same instructor cluster, and the recurring revenue figures ("$4M/year," "$10–15K/month," "2,000 students taught") are creator-reported, recycled across videos, and never independently verified. The same goes for the "5X quality" multipliers, the benchmark grades, and the hour-to-five-minutes debugging figures: read them as the shape of the prize, not a guarantee, and weight the technique while discounting the income story. The meta-rule the calm operators share: wait three to four months to see whether a new pattern survives, and ground your prompts in established engineering literature rather than "you are a senior engineer" persona theatre.

Cost optimization and quality optimization are the same problem

The insight under all of it: cost optimization and quality optimization are the same problem. Cutting schema bloat doesn't just save money, it makes the model faster. Cost-constrained evaluation doesn't just find cheaper models, it finds models that iterate more within a budget, which produce better results. The shift from prompting to loop engineering is the most consequential change in how we work with AI since the prompt itself. The machine handles the repetition, you handle the judgment. But judgment isn't a switch you flip, it's a muscle you build by doing the hard parts yourself before you delegate them. Start with virtuous friction. Build the harness. Run the evals. Route every token to the cheapest model that can do its job. Everything else is vibes.