How to Manage AI Token Limits in Claude and Codex

There's a population of developers who never show up in enterprise AI discourse but who feel this problem in their bones: the OSS maintainer running automated code review on a weekend project, the solo developer building a tool they'll probably give away for free, the indie hacker whose entire AI budget is whatever they can justify putting on a personal credit card. They're not hitting token walls because they're being reckless. They're hitting them because the economics of how LLMs handle context are genuinely punishing—and nobody put that in the brochure.

Nate B. Jones, who runs the AI News & Strategy Daily channel, has published a 15-rule framework for managing token consumption across Claude, Codex, and similar tools. The framework is practical and well-organized. But the more interesting thing Jones surfaces—possibly without intending to—is a structural problem that no amount of personal discipline fully resolves.

The math nobody explains upfront

The core mechanic is this: LLMs don't have persistent memory. Every time you send a message, the entire conversation history gets bundled up and sent again from the start. Your tenth message doesn't cost what you typed—it costs what you typed plus the nine preceding exchanges you already paid for. By message thirty, Jones notes, "the thing you actually wrote just now is a tiny tiny rounding error."

This accumulated weight has a name: reused input. And it compounds faster than most people realize until they're staring at a "come back in five hours" notice after what felt like a modest session.

Jones tracked his own usage on one working day—143 separate Codex threads—and found that 3.59 billion of the 3.77 billion tokens moving through his workspace were reused input. That's 96% overhead on tokens he'd already been charged for. The number is striking even accounting for the fact that Jones, by his own admission, pushes these tools unusually hard.

For the small maintainer running AI coding assistance on a side project, that math matters differently than it does for an enterprise team with infrastructure budgets. Token costs are not abstract when you're paying out of pocket.

The behavioral layer

Jones structures his approach in three tiers. The first is pure habit—nine rules requiring no installation, applicable to any AI tool.

The most impactful one is also the most obvious: start a new conversation when you switch tasks. Don't carry a debugging thread into a documentation task. Don't let your research session bleed into your drafting session. Jones says this drove "the biggest measured change" in his own testing. You're not losing the old conversation—you're just not forcing the next job to haul it along.

Related: carry the artifact, not the argument. If a research phase produced a clean summary document, feed that document into the next phase—not the entire thread of source material, false starts, and iterative corrections that produced it. The version you accepted is the one worth keeping. The rest is scaffolding.

A few other rules worth internalizing: ask for exactly the output format you need (a JSON object, five bullets, one paragraph), because verbose output doesn't just cost tokens once—it costs tokens on every subsequent turn where it sits in context. Search files yourself before asking the model to search them; the convenience of letting Claude root through a large document is real, but so is the token bill. Convert PDFs and formatted sources to plain text or markdown before passing them in—the layout is almost never what the model needs.

The deeper principle underneath all of this is that session costs scale with conversational entropy. Every clarification, correction, and retry drags the full history of the misunderstanding along with it.

The tool layer, and a governance question

Jones's second tier is Token Saver, a skill he built and tested with his team that installs into both Codex and Claude Code—per his published guide at Unlock AI. It automates much of the first tier: searching before opening large sources, sending selected passages instead of whole files, holding outputs to requested lengths, stopping pointless retries. The value proposition is straightforward—if you're not going to remember to do this manually, the skill remembers for you.

The tool definitions problem Token Saver also helps address is worth pausing on. Research cited by Jones from Anthropic's own published work, and corroborated by independent analysis on deferred tool loading, shows that connecting a typical multi-tool setup—GitHub, Slack, Sentry, Grafana—burns roughly 55,000 tokens in tool definitions before any actual work begins. For a solo maintainer running automated code review with a handful of integrations, that's not a rounding error. That's your entire useful budget for a nontrivial session, gone before you've typed a single prompt.

Jones's third tier, Ringer, is where the piece gets structurally interesting—and where I'd want any developer community to pause before adopting it wholesale.

Ringer is a locally-running intermediary that sits between your AI interface and the model provider. Before a request goes upstream, it can intercept it: return a cached answer, run a local recipe without a model call at all, strip the request down to only relevant passages, or enforce hard size limits. It's genuinely clever architecture. It also solves a real problem that the Token Saver skill cannot—a skill can't shrink the envelope it's already inside.

But Ringer is, as far as the public record shows, a Jones personal project. He's building it, he's testing it, his team is using it. The video doesn't address what happens to Ringer if Jones moves on, pivots, or gets acquired. The developer community has watched this exact cycle play out enough times—indie tool becomes indispensable, maintainer burns out or gets bought, tool gets abandoned or locked behind a paywall—that asking the governance question is not paranoia. It's due diligence. A proxy that routes your AI traffic is not a weekend plugin. It's infrastructure. Before wiring it into your workflow, it's worth asking: what are the maintenance commitments here? Is there a community of contributors, or is this one person's framework? Those aren't criticisms of Jones specifically—they're the questions any serious developer should ask about any single-maintainer tool they're about to depend on.

The incentive problem that frames all of this

The most honest thing Jones says in the entire framework is also the most uncomfortable: "The labs aren't going to fix it because frankly, they have an incentive to get us using the product."

He's right, and the implications run deeper than he develops them. The entire consumer promise of modern AI is that friction goes away—you point the tool at a problem and it runs. That narrative is commercially essential for these companies. Token economics work against that narrative, so the labs have little structural reason to make token discipline easy, visible, or even particularly well-documented. Anthropic publishes context window sizes; they don't publish tutorials on how to spend less.

This puts every individual developer in the position of doing behavioral labor that the product design actively discourages. Jones frames this as "cleaning your desk"—a personal responsibility framing that's accurate but incomplete. The hidden math behind Claude's session limits isn't a user education problem. It's an incentive design problem dressed up as one.

What's interesting is that the developer community has been here before—maintaining critical shared infrastructure, absorbing costs that the platforms profiting from their work don't share, building workarounds for systemic issues that the incumbents have no financial reason to fix. The token efficiency problem isn't exactly maintainer burnout, but it rhymes with it. The people least equipped to absorb the cost are the ones doing the most to route around it with personal discipline and indie tooling.

Context windows will grow. Models will get cheaper to run. Some of this will get better on its own. But "better tools are coming" is also what people said about OSS funding models in 2015, and the maintainers are still waiting. The efficiency gains Jones is describing require sustained behavioral discipline in a market where the entire product promise is that you shouldn't have to think about this. That gap—between what the product promises and what the economics require—isn't going to close just because the context window got bigger.

---

Dev Kapoor covers open source software and developer communities for Buzzrag.