---
title: Tokenmaxxing only pays with fat skills and real tests
description: Tokenmaxxing means paying for every extra bit of work that makes a result more complete. Notes on Garry Tan's Lightcone episode, from the $200 rewrite and thin harness, fat skills to the math behind his 400x, held against my own skills, hooks and token bill.
date: 2026-11-01
tags: AI agents, tokenmaxxing, Claude Code, agent skills, testing
---

Tokenmaxxing means paying for every extra bit of work that makes a result more complete, instead of stopping where a human would get tired. Garry Tan says it took him to 400x the code he wrote in 2013. I run the same kind of setup, and the part worth copying isn't the spending. It's the skills that hold your judgement and the tests that catch what comes out. Without those two, you get a bigger bill and more slop.

Garry runs Y Combinator, and he told the story on a [special Lightcone episode](https://www.youtube.com/watch?v=57lDpTwiW6g) in May. After 13 years away from code, he went back in January with Claude Code. Since then he's open sourced gstack, his set of Claude Code skills, which had 138,528 GitHub stars when I checked today. The other side of this word is in my note [don't count tokens, count what they bought](/notes/tokenomics-dont-count-tokens.html), so read them together.

## Three builds of the same blog

His best number comes from a blog platform he's built three times. Posterous, his first YC startup, took about $4 million, six or seven people and a year and a half. Twitter bought it and shut it down, so he and his co-founder wrote it again as Posthaven, for about $100,000, two people and maybe three months.

In January he wrote it a third time for Garry's List, his site about California politics. That took about $200 of Claude Max and probably five days, and this version also crawls the web, runs deep research and has full RAG.

The catch is that by the third time he knew exactly what a blog platform needs. That's my reading, not his, and it matters. Rewriting something you've already designed twice is the best case for any tool.

<figure class="fd-fig tm-builds" aria-labelledby="tm1-cap" data-desc="The same blog platform built three times, as three bars on a log scale. Posterous: about 4 million dollars, six or seven people, about a year and a half. Posthaven: about 100 thousand dollars, two people, maybe three months. Garry's List: about 200 dollars of Claude Max, probably five days, with web crawling, deep research and RAG added. Underneath, the warning: by the third build he already knew what to build.">
<div class="tm-bars">
<p class="tm-bar"><span class="tm-n">Posterous</span><span class="tm-v">~$4M</span><span class="tm-t"><i style="--w:100%"></i></span><span class="tm-s">6 or 7 people, about a year and a half</span></p>
<p class="tm-bar"><span class="tm-n">Posthaven</span><span class="tm-v">~$100K</span><span class="tm-t"><i style="--w:76%"></i></span><span class="tm-s">2 people, maybe 3 months</span></p>
<p class="tm-bar"><span class="tm-n">Garry's List</span><span class="tm-v">~$200</span><span class="tm-t"><i style="--w:35%"></i></span><span class="tm-s">Claude Max, probably 5 days, plus research and RAG</span></p>
</div>
<p class="mp-strip"><b>The catch</b><span>The third time, he already knew what to build.</span></p>
<figcaption id="tm1-cap">His figures, all approximate. The bars are on a log scale, or the last one wouldn't show.</figcaption>
</figure>

## Twenty sources, not one

The word comes out of how Garry's List writes its articles. A person clicks a link, reads a headline and moves on. His pipeline pulls research through Perplexity's and Grok's APIs, takes 20 sources instead of one and cross-references them: these 13 say this, those seven disagree. All of that goes into the main prompt.

He calls the habit boil the ocean. If extra work makes the result more complete, pay for it. He puts one article at the equivalent of $5 or $10 of Opus calls, for work a person would do by going through dozens of articles and whole books.

He doesn't think that removes people. Someone still has to supply the want, and his is middle schoolers in San Francisco who couldn't take algebra. No model picked that subject for him.

<figure class="fd-fig tm-sources" aria-labelledby="tm2-cap" data-desc="Two ways to research an article. A person clicks one link, reads the headline and that's all they understand: one square. Tokenmaxxed, the pipeline takes 20 sources and cross-references them: 13 cobalt squares that say one thing and seven red squares that disagree, all fed into the main prompt. Underneath: Garry's estimate of 5 to 10 dollars of Opus calls per article.">
<div class="mp-two-row">
<div class="mp-two-card">
<p class="mp-two-who">A person in a hurry</p>
<p class="mp-two-name">1 source</p>
<p class="tm-dots" aria-hidden="true"><i></i></p>
<p class="mp-two-line">Clicks a link, reads the headline</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">Boil the ocean</p>
<p class="mp-two-name">20 sources</p>
<p class="tm-dots" aria-hidden="true"><i></i><i></i><i></i><i></i><i></i><i></i><i></i><i></i><i></i><i></i><i></i><i></i><i></i><i class="tm-no"></i><i class="tm-no"></i><i class="tm-no"></i><i class="tm-no"></i><i class="tm-no"></i><i class="tm-no"></i><i class="tm-no"></i></p>
<p class="mp-two-line">13 say this, 7 disagree, and all of it goes in the prompt</p>
</div>
</div>
<p class="mp-strip"><b>His estimate</b><span>$5 to $10 of Opus calls per article.</span></p>
<figcaption id="tm2-cap">His example. The 13 and the 7 are how he illustrates it, not a measured article.</figcaption>
</figure>

## Judgement goes in the Markdown

A harness is the core loop: it takes your input, gives it to the model and runs what the model asks for. YC kept rewriting one for internal agents until they asked why, since Claude Code already exists. Their partner Pete Koomen gave the idea its name: [thin harness, fat skills](https://github.com/garrytan/gbrain/blob/main/docs/ethos/THIN_HARNESS_FAT_SKILLS.md). Stop writing the loop and spend your time on the Markdown.

His test is a wedding planner. Whatever you'd write in plain English to teach the next planner goes in Markdown. Calling 20 venues is a real action, so that's code, a call to Twilio. Most of the pain in agent engineering, he says, comes from putting judgement in code, which is brittle and doesn't understand special cases.

Thin doesn't mean the harness doesn't matter. One of the hosts says anything harder than a simple script fails for them through OpenClaw, on the same Opus 4.7 that works in Claude Code. So use a good loop, and don't write your own.

This is the part I already live in. Claude Code and OpenClaw are my harnesses, and about 30 skills of my own hold the procedures. The skill that saved my brief of this episode is 124 lines of Markdown deciding what goes in the note, next to a 441-line Python script and an 80-line browser check that make the API calls, validate the data and take the screenshots.

<figure class="fd-fig tm-split" aria-labelledby="tm3-cap" data-desc="Where work belongs under thin harness, fat skills. In Markdown: judgement and special cases, like a wedding planner's checklist for the next planner, or my video-brief skill's 124 lines deciding what goes in a note. In code: real, deterministic actions, like calling 20 venues through Twilio, or my 441-line Python script and 80-line browser check making API calls and checks. Underneath: the harness is the loop that runs the model, and you reuse it rather than write it.">
<div class="mp-two-row">
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">Markdown</p>
<p class="mp-two-name">Judgement</p>
<p class="mp-two-line">His: the wedding planner's checklist</p>
<p class="mp-two-line">Mine: 124 lines on what goes in a brief</p>
<p class="mp-two-line">Handles the special cases</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card">
<p class="mp-two-who">Code</p>
<p class="mp-two-name">Actions</p>
<p class="mp-two-line">His: calling 20 venues through Twilio</p>
<p class="mp-two-line">Mine: 441 lines of Python, an 80-line check</p>
<p class="mp-two-line">Does the same thing every time</p>
</div>
</div>
<p class="mp-strip"><b>The harness</b><span>The loop that runs the model. Reuse it.</span></p>
<figcaption id="tm3-cap">His example and mine, side by side. My line counts are from the skill's files today.</figcaption>
</figure>

## gstack started in Apple Notes

He didn't plan gstack. He got tired of typing the same instructions into Claude Code, put them in Apple Notes and then posted them, and about 200,000 people saw that. Now it's a chain of reviews, and each one works on the plan before anything gets built.

Two of its tricks are tiny. Before any work, he asks for an ASCII diagram of the data flows, inputs and outputs, user flows and error messages. Once Claude has drawn that, he says, the work comes out more complete. The CEO review adds a check for what's more ambitious and delivers 10x the value for only 2x the effort.

None of my skills asks for an ASCII diagram. It's the cheapest thing on his list to try.

The chain also stops to ask. gstack leans on AskUserQuestion, because that's where the person supplies what they're actually building. "I never want to be entirely out of the loop," he says. "I just want the machine to do the stuff that I don't want to do."

<figure class="fd-fig tm-chain" aria-labelledby="tm4-cap" data-desc="A gstack plan in the order Garry describes, five steps lighting up in turn under a big label. One, office hours: how do you know people want this, who is it for. Two, CEO review: Brian Chesky's 10-star exercise and a check for 10x the value at 2x the effort. Three, design and developer reviews, when the work has UI or a developer will use it. Four, eng review: ASCII diagrams and the test plan. Five, Codex: a second model looks for problems and reports back to Claude Code. Underneath: only then does Claude build, and then browse tests what changed.">
<p class="ea-now ea-say5" aria-hidden="true"><span>Does anyone want it</span><span>Make it 10x better</span><span>Check the UI and the API</span><span>Draw it, plan the tests</span><span>Ask a second model</span></p>
<ol class="ea-rows ea-cyc5 tm-rows" aria-label="A gstack plan, step by step">
<li><b>1</b><span class="ea-who">Office hours</span><span>How do you know people want this? Who's it for?</span></li>
<li><b>2</b><span class="ea-who">CEO review</span><span>The 10-star exercise, then 10x the value at 2x the effort.</span></li>
<li><b>3</b><span class="ea-who">Design, dev</span><span>Run when there's UI, or a developer will use it.</span></li>
<li><b>4</b><span class="ea-who">Eng review</span><span>ASCII diagrams of the data flows and errors, then tests.</span></li>
<li><b>5</b><span class="ea-who">Codex</span><span>Another model hunts for problems and reports back.</span></li>
</ol>
<p class="mp-strip"><b>Only then</b><span>Claude builds, and browse tests what changed.</span></p>
<figcaption id="tm4-cap">The order he describes on screen. gstack has more skills than these, and it has moved since May.</figcaption>
</figure>

## It's slop until something catches it

He hit what everyone hits. It works for the 80% case, then real users touch it and it falls over. Writing tests by hand was never fun, so he always did the minimum. Now the machine doesn't care, so he aims for 80 to 90% coverage, after finding 100% was too much. Untested agent code, he says, is 10x worse than human code, because you have no idea what will happen.

Then manual testing became the bottleneck. He had 15 features waiting for him to click through, and the Claude in Chrome MCP took 2 to 3 seconds a turn. So he wrapped Microsoft's Playwright. That's now browse, a long-lived HTTP daemon with 70 commands, and his QA skill reads what changed on the branch and tests any UI or data change in a real browser.

I got to the same place another way. My skills bring their own Playwright checks, and this note had to pass one in Chromium and WebKit at 320, 390 and 1280 px before it shipped.

What I'd add is a hard stop. "The machine doesn't care. It'll just do it" cuts both ways. Two of my agent sessions ran a `pkill` with options after the pattern to stop a test server. macOS reads those as more patterns, and Docker Desktop quit both times, taking every container on my Mac mini with it.

So that one is now a hook. Three of them run before a Bash command does: one refuses that `pkill` form, one refuses taking over another app's port, and one refuses a pull request with no issue. A skill asks. A hook refuses.

I also have the opposite example. On October 25, an agent ran my film app's tests inside its live container. The container's environment aimed them at the real database, and the tests' `drop_all` dropped every table. A backup brought back what it held. The rule against that is still only written down, which is a gap.

<figure class="fd-fig tm-layers" aria-labelledby="tm5-cap" data-desc="What catches bad agent output, his setup against mine, in five rows. Tests: he aims for 80 to 90 percent coverage; I run build and tests on each change, with no coverage target. Real browser: his is browse, a daemon with 70 commands; mine are Playwright checks per skill. Second model: he usually runs Codex on the plan; I only do it in the pipeline that runs without me. Diagram first: he asks for ASCII data flows; none of my skills does. Hard stop: not covered in the episode; I have three hooks on Bash.">
<div class="tm-table">
<p class="tm-row tm-head"><span>Layer</span><span>Garry</span><span>Me</span></p>
<p class="tm-row"><b>Tests</b><span>80 to 90% coverage</span><span>On each change, no coverage target</span></p>
<p class="tm-row"><b>Real browser</b><span>browse: a daemon, 70 commands</span><span>Playwright checks, one per skill</span></p>
<p class="tm-row"><b>Second model</b><span>Usually Codex on the plan</span><span class="tm-gap">Only in my unattended pipeline</span></p>
<p class="tm-row"><b>Diagram first</b><span>ASCII data flows</span><span class="tm-gap">None of my skills asks</span></p>
<p class="tm-row"><b>Hard stop</b><span>Not in the episode</span><span>Three hooks on Bash</span></p>
</div>
<figcaption id="tm5-cap">His side is what he says in the episode. Mine is my own config today, with my two gaps in red.</figcaption>
</figure>

## The 400x is arithmetic, not value

He got trolled for counting lines of code, so he [published the math](https://github.com/garrytan/gstack/blob/main/docs/ON_THE_LOC_CONTROVERSY.md). A script counts logical lines across his repos: 5,143 in all of 2013, and 1,233,062 in the first 108 days of 2026. Per day, that's 14 against 11,417, or 810x. Then he assumes AI code is twice as verbose and halves it, and that's the 408x the episode rounds to 400x.

I like that he shows the work, because the same table has the other numbers. Across those same periods, logical lines went up 240x, files touched 47x and commits 4.9x. And the 14 a day was part-time, in a year with a day job.

He concedes the point himself, in bold: "Time to first user is the metric that matters, not LOC." If 80% of what he shipped this year is dead in two years, he writes, the critique gets its teeth.

<figure class="fd-fig tm-loc" aria-labelledby="tm6-cap" data-desc="The same work measured six ways, 2013 against 2026, as bars on a log scale. Logical lines per day: 810 times. Per day, after assuming AI code is twice as verbose: 408 times, the figure the episode calls 400x. Total logical lines: 240 times. Files touched: 47 times. Commits: 4.9 times. Active repos: 3.75 times. Underneath, his own concession: time to first user is the metric that matters, not lines of code.">
<div class="tm-bars">
<p class="tm-bar"><span class="tm-n">Lines per day</span><span class="tm-v">810x</span><span class="tm-t"><i style="--w:100%"></i></span></p>
<p class="tm-bar tm-key"><span class="tm-n">Lines per day, halved for verbosity</span><span class="tm-v">408x</span><span class="tm-t"><i style="--w:90%"></i></span></p>
<p class="tm-bar"><span class="tm-n">Total lines</span><span class="tm-v">240x</span><span class="tm-t"><i style="--w:82%"></i></span></p>
<p class="tm-bar"><span class="tm-n">Files touched</span><span class="tm-v">47x</span><span class="tm-t"><i style="--w:57%"></i></span></p>
<p class="tm-bar"><span class="tm-n">Commits</span><span class="tm-v">4.9x</span><span class="tm-t"><i style="--w:24%"></i></span></p>
<p class="tm-bar"><span class="tm-n">Active repos</span><span class="tm-v">3.75x</span><span class="tm-t"><i style="--w:20%"></i></span></p>
</div>
<p class="mp-strip"><b>His words</b><span>"Time to first user is the metric that matters, not LOC."</span></p>
<figcaption id="tm6-cap">From his write-up, 2013 against the first 108 days of 2026. Log scale. The totals compare a full year with 108 days.</figcaption>
</figure>

## Tokens are rent, they say

One of the hosts compares token spend to San Francisco rent. Founders flinch at the apartment, and YC tells them to pay it. Save money on the couch, not on the models. Garry goes further, with $500 in a single day, as long as you're building something of great value to you and it's the right thing.

That condition does all the work. J.R. Storment's rule in my [tokenomics note](/notes/tokenomics-dont-count-tokens.html) was to count what the tokens bought, so I tried it on myself. [Meterlex](/projects/meterlex.html) read 4.09 billion tokens for the week ending October 30, and my account merged 417 pull requests across 46 repos that week. That's about 9.8 million tokens per merged PR.

It's a tidy number, and it doesn't tell me much. A PR isn't an outcome any more than a line is. Tokens aren't what they sound like either: in the week open as I write this, Claude Code's count is 3.87 billion and only 25.8 million of that is model output. Nearly all the rest is cached context, read again on every turn.

So I can tell you what I burn and I can't tell you what it bought. That's the same gap the Tokenomics survey found.

<figure class="fd-fig tm-bill" aria-labelledby="tm7-cap" data-desc="My own numbers. 4.09 billion tokens in the week ending October 30, as read by Meterlex. 417 pull requests merged under my account across 46 repositories in that same week, which is about 9.8 million tokens per merged PR. 0.7 percent of Claude Code's tokens were model output in the week open on November 1, 25.8 million of 3.87 billion; nearly all the rest is cached context read again. Underneath: none of this says what the work was worth.">
<div class="mp-stats">
<p><b>4.09B</b><span>tokens, the week ending October 30</span></p>
<p><b>417</b><span>PRs merged that week, about 9.8M tokens each</span></p>
<p><b>0.7%</b><span>of Claude Code's tokens are model output</span></p>
</div>
<p class="mp-strip"><b>Still missing</b><span>What any of it was worth.</span></p>
<figcaption id="tm7-cap">From Meterlex and GitHub on November 1. The output share is from the week open today, which isn't finished.</figcaption>
</figure>

## A Ferrari with a mechanic on call

His line on OpenClaw is the one everyone quotes. It's like driving a Ferrari: it figures things out you'd never think a machine could, and it breaks down on the side of the road when you most need it, so you'd better be a mechanic. He calls this the Homebrew Computer Club moment, the Apple 1 in a wooden case. Getting one running takes two or three hours and maybe $500 or $1,000 in tokens and cloud.

A host has the better line. It doesn't matter if it's brittle, because you can sit another agent next to it to fix it. I already do that: one of my skills is a Claude Code runbook for OpenClaw. When an agent goes deaf on Telegram, it says to look for a hung `codex app-server` and kill that, not the gateway.

He predicts that everyone on the planet will have a personal AI a year from now. That's a bet, and he offers no evidence for it. The question he opens the episode with stands either way: "Will you have control over your own tools or will your tools have control over you?" Unless you write your own prompts, he says, you sit below the API line of some PM who doesn't know you. My agents' prompts and memory are files on my own disk, and that's my answer so far.

<figure class="fd-fig tm-ladder" aria-labelledby="tm8-cap" data-desc="How getting unstuck changed, as one of the hosts tells it, in four rows. Stack Overflow: you look the problem up. ChatGPT: you ask, then copy and paste the code and the errors back and forth. Claude Code: it runs the code itself, so the copying stops. OpenClaw with Claude Code beside it: when the agent breaks, another agent fixes it. Underneath, my version: a Claude Code skill of mine is the runbook for OpenClaw.">
<ol class="ea-rows tm-rows" aria-label="How getting unstuck changed">
<li><b>1</b><span class="ea-who">Stack Overflow</span><span>You look the problem up.</span></li>
<li><b>2</b><span class="ea-who">ChatGPT</span><span>You ask, then copy and paste back and forth.</span></li>
<li><b>3</b><span class="ea-who">Claude Code</span><span>It runs the code, so the copying stops.</span></li>
<li><b>4</b><span class="ea-who">Two agents</span><span>OpenClaw breaks, and Claude Code fixes it.</span></li>
</ol>
<p class="mp-strip"><b>Mine</b><span>A Claude Code skill is my runbook for OpenClaw.</span></p>
<figcaption id="tm8-cap">The host's progression, in my words. The host says this isn't how it will stay.</figcaption>
</figure>

## Try it

The episode is 41 minutes, and the demos are the best part. If you only have ten, start at the thin harness chapter.

- [Tokenmaxxing: How Top Builders Use AI To Do The Work Of 400 Engineers](https://www.youtube.com/watch?v=57lDpTwiW6g), Y Combinator, May 8, 2026. [The accidental gstack at 10:07](https://www.youtube.com/watch?v=57lDpTwiW6g&t=607s), [thin harness, fat skills at 20:59](https://www.youtube.com/watch?v=57lDpTwiW6g&t=1259s), [the Ferrari at 24:35](https://www.youtube.com/watch?v=57lDpTwiW6g&t=1475s).
- [gstack](https://github.com/garrytan/gstack) and [the math behind the 400x](https://github.com/garrytan/gstack/blob/main/docs/ON_THE_LOC_CONTROVERSY.md).
- My notes on [counting what tokens buy](/notes/tokenomics-dont-count-tokens.html) and [reviewing the plan instead of the pull request](/notes/review-the-plan-not-the-pull-request.html).

Next time you're about to spend more tokens, write down first what would catch a bad result. If you've found a better number than lines or PRs, I'd like to hear it.