▶ YouTube Summaries

← All summaries

Token-maxing Claude and Codex subscriptions

2026-10-02 Fri ⏱ 1 hr 6 min t3dotgg

Theo's guide to "token-maxing": squeezing the most out of heavily subsidized Claude and Codex subscriptions by stacking accounts behind a single residential proxy, running many agent threads in parallel across a fleet of cheap Linux boxes, and changing how you work so the agent goes all the way from problem to merged PR. The underlying argument: subscriptions give you roughly 40x the API value, unused quota is money lost every week, and humans — not agents — are now the bottleneck. He flags up front that parts of this may violate terms of service.

Why subscriptions, not the API

  • $200 on the API buys $200 of tokens. A $200 Claude sub yields roughly $8,000 of inference (only ~$4,000 of it Fable, which has a separate 50% bucket). A $200 Codex sub is ~$12,000, with no split between Astra and cheaper models like Soul.
  • Codex handed out ~14 limit resets in 30 days, effectively doubling that. OpenAI has temporarily paused new $200 Codex subscriptions because of demand.
  • Fable's API price ($10/$50 per Mtok) is already ~70% below the $25/$125 originally quoted for Mythos preview; rumoured API margins are ~95%. Theo says he puts in about $1,000 for every ~$50,000 of tokens he takes out.
  • Cursor, OpenCode, T3 Chat and similar subscriptions get far smaller subsidies (30–50% off versus 95–98%). Only Claude and Codex subs are worth stacking.
  • The $100 Claude tier gives half the tokens but a quarter of the 5-hour limit. He recommends going straight to $200.
  • Turn off "improve the model for everyone" in Codex (and the equivalent in Claude Code). He says the personal-sub terms then match team terms, so paying API prices for privacy is wasted money.
  • Use the API for anything user-facing. Serving public traffic through subscriptions is against the rules, and he says you deserve the ban.

Accessing the tokens: one proxy, one residential IP

  • Never sign Claude Code into a VPS or VPN. Anthropic watches datacenter IPs closely because of resold subs and distillation. Avoid traffic from many machines at once.
  • Run CLI Proxy API (he started from the VibeProxy fork and has forked it heavily) on a home machine. It holds the OAuth for all accounts (he has five Claude and four Codex) and exposes one endpoint. Claude Code and Codex point at it by changing two config variables, which works because both already support custom base URLs for Bedrock.
  • Changes worth making to the proxy:
  • Prioritise accounts by soonest reset instead of spreading load evenly.
  • Enable websockets for Codex, which cuts latency a lot.
  • Check session/account affinity. Prompt caches are per-account, so switching accounts mid-thread forces expensive cache re-writes.
  • Expose the proxy only over Tailscale. With no API key it is still reachable only from your tailnet, and any machine anywhere routes through the home IP.
  • Only use Claude models from a Claude sub inside Claude Code. Using them in other harnesses gets accounts banned.
  • He keeps a "fleet management" repo describing how every box is set up. A new machine is just SSH access plus "set this up the way I like" to an agent.
  • Resets differ. A Codex reset restarts the 7-day window. A Claude reset only refills the percentage and keeps the timer. Mindset: you are gifted ~$4k a week, and whatever is unused at reset is lost.
  • Update recorded later: Opus 5.5 behaves much like Fable 5.1 and is hard to max out on a single sub, so you may need fewer accounts. He calls Opus 5 a "dumpster fire" and 5.5 "pretty good".

Using tokens well

  • Roughly 10–15% of his tokens go to writing code and 85–90% to verifying it. De-risk both sides of the merge button: make it likely the PR is good when you first see it, and make reverting take under 15 seconds.
  • Bring the agent in when you start thinking, not when you have finished. Give it the problem, not your solution. If it fails, you have learned the problem is genuinely hard and worth your attention. "Don't outsource thinking, scale it."
  • Let the agent span the whole pipeline: problem → solution → PR → review bots → fixes → merge. Each hop is time you can spend firing off other threads.
  • Make each check-in productive: ask up front for a PR, a Tailscale preview environment, and "babysit this PR". Ideally, the next time you open the thread you can merge it.
  • Treat threads as to-dos, not history. T3 Code's "settle" works like inbox zero: merged PRs make threads vanish, idle threads auto-settle after 3 days, working threads are dimmed, and Cmd+Enter sends a prompt in the background.
  • Agents are multi-threaded and humans are single-threaded. Never watch an agent work.
  • Run each thread in a new worktree. Current models handle the git edge cases themselves.
  • T3 Code features he highlights: choosing which machine a thread runs on, load-balancing across machines, and one sidebar for every box including mobile. Set up a new box with npx t3 connect or npx t3 serve (with Tailscale support).

Using tokens "poorly"

  • Reach for an agent before your brain, even for "silly" asks: summarise a teammate's rewrite, triage your PRs, find an email, collect your medical records from web dashboards.
  • If your questions to agents don't feel a bit silly, you are not offloading enough.
  • Spend quota that is about to reset: one example was asking sub-agents to scan all his GitHub and local projects for abandoned ideas worth reviving.

Using tokens while asleep

  • Move dev work off the laptop onto an always-on Linux box at home (an old PC with 8 GB of RAM and 4 cores is enough), with Tailscale, the proxy and T3 Code. Agent coding barely uses CPU — his 32-core box sits near 0% with six threads running.
  • He argues against VPSs (expensive, and datacenter IPs risk bans) and against macOS for parallel agent work (he blames the filesystem and security policy for overheating).
  • Handle bottlenecks such as parallel Rust CI with engineering: run CI remotely (Blacksmith, Depot), queue builds, and so on.
  • His closing point is that this is fun: the new engineering problems are about orchestrating cores, CI and parallel work, and engineering has never been more enjoyable for him.