DEV Community: Henry Godnick

The Weekly Limit Is the New Wall: A Field Guide to Claude's Weekly Cap and the Shared ChatGPT + Codex Allowance

Henry Godnick — Thu, 05 Nov 2026 01:42:39 +0000

For most of last year, the number that ruined your afternoon was the 5-hour window. You'd hit it, take a coffee break, and come back. That era is ending. On Claude, the weekly limit is now the cap that actually stops work: even the new top plan drops the 5-hour cap for Claude Code but keeps the weekly one. On the OpenAI side, from December ChatGPT and Codex draw from one shared allowance, so a long chat about a design doc now spends the same budget your coding agent needs on Thursday.

Both changes push the same way: you need to budget for a week, not a session. Here's what's worked for me.

1. Know your real burn rate, not your vibe

Most people find out they're near the weekly cap when the agent stops. Instead, take three readings a day for one week: morning, after lunch, end of day. In Claude Code, /status shows where you are; for Codex, check the usage page in ChatGPT settings. Write the percentages down.

After a week you'll know two numbers: your average daily burn and your worst day. If worst day × 5 is over 100%, you will hit the wall in a normal week. That's the number to fix.

2. Treat one 5-hour session as a slice of the week

A common report right now: one heavy 5-hour session uses 15–20% of the weekly allowance. That means four or five intense sessions is your entire week. Plan around it:

Split big tasks. One giant "refactor the whole module" prompt drags an ever-growing context. Five scoped tasks in fresh sessions are usually cheaper and better.
Start fresh sessions often. Long sessions re-send long context. When a session drifts, summarize the state into a note and start over.
Keep CLAUDE.md / AGENTS.md short. It rides along on every request. Move rarely used detail into separate docs the agent reads on demand.

3. Match the model to the job

Use the biggest model for planning, hard debugging and architecture. Use the smaller, cheaper model for renames, tests, boilerplate and status updates. Background subagents in Claude Code just got much cheaper for status updates, but the main loop still costs what it costs; route accordingly.

4. Budget chat and code together (Codex users)

Once ChatGPT and Codex share an allowance, the mental model changes:

Decide a split, e.g. 70% coding agent / 30% chat, and check it mid-week.
Do long brainstorming in a model you don't need for coding, if you have one.
Don't paste huge logs into chat "just to ask"; trim them first.

5. Put the reset time where you can see it

The single most useful fact is not "how much have I used" but "am I burning faster than it refills, and when does it reset?" If the reset is Friday morning and you're at 85% on Wednesday, Thursday is a small-model day. If it resets tomorrow and you're at 60%, spend freely.

Write the reset day on a sticky note if you have to. The point is to never be surprised.

6. Have a fallback plan before you need it

When the cap hits mid-task, the cost isn't the tokens, it's the lost context. Keep a running NOTES.md in the repo that the agent updates as it works (what's done, what's next, open questions). If you have to switch tools or wait for the reset, you resume in minutes instead of rebuilding context from scratch.

7. A weekly routine that takes 5 minutes

Monday: check where you start, note the reset time, decide your big-model days.
Wednesday: check the burn rate. Above 60%? Shift to smaller models and scoped tasks.
Friday / reset day: look back at what ate the most. Usually it's one runaway session or one enormous context.

Tools

Claude Code's /status and the ChatGPT usage page are enough if you check them. If you want the numbers always visible on a Mac, Peter Steinberger's free, MIT-licensed CodexBar puts them in the menu bar. Disclosure: I make TokenBar, which is built on CodexBar (tokenbar.site).

Whatever you use, the habit matters more than the tool: know your weekly burn, know your reset time, and match the model to the job. How are you handling the new limits?

This post was drafted with AI assistance.

DraftKey in a Developer's Workday: $4.99 Tab Autocomplete for Slack, Email and PR Descriptions on Mac

Henry Godnick — Tue, 27 Oct 2026 18:58:35 +0000

DraftKey is a Mac app that puts on-device AI autocomplete and rewrite into almost any text field: type, see grey ghost text, press Tab to accept it, or select a sentence and press ⌘⌥ to rewrite it in place. It costs $4.99 once, a lifetime license for up to 3 Macs, and runs fully offline on Apple Silicon (macOS 14+, ~1.12 GB local model). Get it at getdraftkey.com.

Disclosure: I built DraftKey (Aura Technologies). There's no free trial, so I'll be specific about where it helps and where it doesn't.

Why a developer would want this

Code editors already have Copilot-style completion. The writing around code doesn't: Slack replies, standup notes, emails to stakeholders, PR descriptions in the browser, issue comments. That's the gap DraftKey fills. It works through the macOS Accessibility API, so there's no plugin per app.

A normal day with it

Morning Slack catch-up. You start "Looked into the flaky test, it turns out" and DraftKey offers the rest of the sentence. Tab if it's right, keep typing if not.
PR description in the browser. Draft the summary roughly, select it, ⌘⌥, and you get a tighter version in the same text box.
Email to a non-engineer. Select the jargon-heavy paragraph and rewrite it into something a PM can read.
End-of-day notes. Short completions in Notes or Mail while the context is still in your head.

What it won't do

Not a frontier model. The local model is good at finishing sentences and tightening prose. It won't design your system or write a long doc from one line.
Not in your code editor. Keep Copilot or Cursor for code. DraftKey is for prose.
Some fields don't cooperate. Terminals, secure/password fields, custom canvases and some Electron apps expose text poorly through Accessibility, so suggestions may not appear there.
Apple Silicon + macOS 14 only. No Intel Macs.

Why on-device matters for dev work

Slack threads and PR descriptions often mention internal systems, customers or incidents. DraftKey's model runs locally, so what you type isn't sent to a cloud API for suggestions.

Price, plainly

$4.99 once. No subscription, no account, up to 3 Macs. If you write a lot of non-code text on an Apple Silicon Mac, get DraftKey at getdraftkey.com.

Aura Technologies

TokenBar vs Claude Code's /cost and /status: Why I Built a $15 Menu Bar Meter Anyway

Henry Godnick — Mon, 26 Oct 2026 21:56:39 +0000

TokenBar is a Mac menu bar app that shows your AI coding usage, limits and reset times for Claude, Codex, Cursor, Gemini and Copilot in one glance. It costs $15 once, lifetime, no subscription, and runs on macOS 14+. Get it at tokenbar.site.

Disclosure: I built TokenBar (Aura Technologies). It's built on the MIT-licensed CodexBar by Peter Steinberger, which did a lot of the groundwork. I'm biased, so here's when you don't need it too.

The free option you already have

Claude Code ships with built-in commands for checking where you stand. /cost shows token use and estimated cost for the current session, and /status shows your account and session details. They're free, first-party, and accurate for the session you're in.

The catch: you have to remember to type them, inside that one terminal, and they only know about Claude Code. They say nothing about your Codex weekly window, your Cursor plan, or Copilot.

What TokenBar adds

Always visible. A compact meter sits in the macOS menu bar. You see you're near a limit before you start a big agent run, not after it stalls.
Every tool in one dropdown. Claude, Codex, Cursor, Gemini and Copilot, with usage windows and reset times where each provider exposes them.
Routing decisions. If Claude is nearly capped and Codex is fresh, you can see that and send the next job to Codex.
$15 once. No monthly fee for a meter.

Side by side

	Claude Code `/cost` + `/status`	TokenBar
Price	Free	$15 lifetime
Tools covered	Claude Code only	Claude, Codex, Cursor, Gemini, Copilot
Where you see it	Typed into one terminal session	macOS menu bar, always on
Platform	Anywhere Claude Code runs	macOS 14+ only
Billing source of truth	Closer to it	No, reads what providers expose

Honest limits

Mac only, macOS 14 or newer. No Windows or Linux.
Not invoice-grade. TokenBar reads what providers expose; if a provider changes its endpoints, numbers can lag until an update. Use the vendor dashboard for billing disputes.
Overkill for single-tool users. If Claude Code is your only AI tool, /cost and /status are enough. Don't pay for this.

Who it's for

You run Claude Code in one terminal, Codex in another, Cursor in the editor, and you keep getting cut off mid-refactor on one while another sits unused. That's exactly why I built it. One avoided cap-out mid-task is worth more than $15 of time.

If that's you, it's $15 lifetime at tokenbar.site. If not, the free commands you already have are fine.

Aura Technologies

DraftKey vs Apple Writing Tools: $4.99 Tab Autocomplete vs the Free Rewrite Built Into macOS

Henry Godnick — Mon, 26 Oct 2026 19:03:34 +0000

I built DraftKey, an on-device AI autocomplete for every Mac app, for $4.99 lifetime (up to 3 Macs). It shows a short gray suggestion as you type in Mail, Slack, Notes, Linear or your browser, and you press Tab to accept it. Your text stays on your Mac. Get it at getdraftkey.com.

The question I get most is: "macOS already has Apple Writing Tools, why would I pay for this?" Fair question. I'm the maker (Aura Technologies), so I'm not neutral, but here's the honest answer.

The short version

	DraftKey	Apple Writing Tools
Price	$4.99 once	Free with macOS
Main job	Finishes your sentence while you type (Tab to accept)	Rewrites, proofreads or summarizes text you already wrote
How you use it	Just type; suggestions appear inline	Select text, open the Writing Tools menu
Also does rewrite?	Yes, ⌘⌥ rewrite (shorter, clearer, fix grammar, tone, custom)	Yes, that's its core
Requirements	macOS 14+, Apple Silicon, 8 GB RAM	Apple Intelligence (newer macOS, Apple Silicon, supported region/language)
Model	Bundled ~1.12 GB local model	Apple's on-device models, plus Private Cloud Compute for some tasks

Use Apple Writing Tools if you write a draft first and then want it cleaned up. It's free and it's good at that.

Use DraftKey if you want help during typing: the next few words appear and you hit Tab, like code autocomplete but for emails, Slack replies and tickets. Writing Tools doesn't do inline autocomplete.

They don't conflict. Plenty of people could run both.

What DraftKey actually does

DraftKey reads the text around your cursor through macOS Accessibility, runs a small language model on your Mac, and shows a gray suggestion. Tab accepts it. Keep typing and it disappears. ⌘⌥ opens a rewrite on the paragraph or selection, and you review before anything is inserted. It also has clipboard history (⌘⌥V).

It isn't a chatbot or a side panel. It's autocomplete for prose, system-wide.

Honest limits, upfront

No free trial. You pay $4.99 to try the real app. There's a free in-browser typing demo on getdraftkey.com.
Apple Silicon and macOS 14+ only. No Intel Macs.
About a 1.12 GB model download on first launch.
It depends on Accessibility. Some Electron apps and custom editors work poorly, and password fields never work (on purpose).
It's a small local model. It's good at finishing sentences fast, not at writing essays for you.

Who this is for

If you send a lot of short writing every day (Slack, email, tickets, PR descriptions) and you've ever wished Copilot-style Tab completion existed outside your code editor, that's exactly why I built DraftKey.

getdraftkey.com: $4.99 once, no subscription, no account needed to write.

I built it at Aura Technologies. If suggestions misbehave in a specific app, tell me in the comments and I'll look at it.

TokenBar vs CodexBar: An Honest Comparison From the Developer Who Forked It

Henry Godnick — Sun, 25 Oct 2026 22:03:13 +0000

I built TokenBar, a Mac menu bar app that shows your Claude Code, Codex, Cursor, Gemini and Copilot usage limits, reset times and AI spend in one place. Pro is $15 lifetime for one Mac (or $5/month Basic) at tokenbar.site. It's built on CodexBar, a free, open-source, MIT-licensed project by Peter Steinberger. People reasonably ask: why would anyone pay $15 for something built on a free app? This post is my honest answer, including the cases where you should just use CodexBar.

What CodexBar is

CodexBar is an open-source macOS menu-bar app that shows usage for AI coding tools such as Codex and Claude Code. It's MIT-licensed, which means anyone can use it, modify it, and build on it, including commercially, as long as the license and copyright notice are kept. It has an active community and it's free.

If you've never tried a menu-bar usage tracker, CodexBar is a great place to start. It costs nothing, and you'll find out quickly whether having usage visible changes how you work.

What TokenBar is

TokenBar is a commercial app from Aura Technologies built on top of CodexBar's foundation. The MIT license allows that, and TokenBar keeps the required attribution. It sells for $15 as a one-time purchase at tokenbar.site, with no subscription.

The goal of TokenBar is to focus on spend: helping you see what AI coding is costing you and keep it within a budget, packaged as a polished app with direct support from the developer.

When you should use CodexBar

I'd genuinely recommend the free option if:

You're comfortable with open-source tooling and happy to update, configure, or build from source.
You mostly want usage visibility and the CodexBar feature set already covers your tools.
You like contributing. Open-source projects improve when people use them and send fixes upstream.
Budget is tight. If $15 matters right now, a free tool that does 90% of what you need is the right call.

There's no catch here. CodexBar is good software.

When TokenBar might be worth $15

TokenBar is aimed at a few kinds of people:

They want a packaged, supported app. Paying gets you a product with a developer who answers email and has a direct incentive to keep it working.
They care primarily about cost rather than raw usage, and want the app oriented around spend.
They'd rather not maintain anything. Install it, leave it running, forget it.
They want to support continued development of a focused tool.

On top of CodexBar, TokenBar adds a Pro dashboard with spending history and provider mix, Pixel Agents (your coding agents shown as a small pixel-art office so you can see which are working, done or waiting on you), and more providers. That's the honest pitch: convenience, focus, and support, not secret capabilities that make the free version useless.

Why build on open source at all?

Because rebuilding a solid foundation from scratch would have been wasteful. CodexBar's authors did excellent work and chose a permissive license that explicitly allows this. Building on it let me spend time on the parts I cared about instead of reinventing the basics.

I think the healthy way to do this is to be upfront. TokenBar's relationship to CodexBar is disclosed, the license is respected, and anyone who reads this post can make an informed choice. If you think a paid app built on an MIT project is distasteful, that's a fair opinion, and CodexBar is right there.

Questions to ask yourself

If you're deciding between the two, try this:

Install CodexBar first. It's free.
Use it for a week of normal work.
Ask: did I miss anything? Was there a spend-related question I couldn't answer at a glance? Did I want something more packaged?
If the answer is no, you're done. Keep using CodexBar.
If the answer is yes, look at what TokenBar offers and decide if it's worth $15 to you.

The bigger point

Whichever one you choose, the real win is having AI spend visible while you work. Developers who can see the meter make different decisions: they start fresh sessions sooner, they use cheaper models for routine work, and they notice runaway agents before the bill does. A free tool that you actually use beats a paid one sitting in your Downloads folder.

Disclosure, once more

I built TokenBar. It's a product from Aura Technologies, based on the MIT-licensed CodexBar project, and it costs $15 one-time at tokenbar.site. I have an obvious interest in people buying it, which is why I've tried to be clear about when you shouldn't. If you try CodexBar and it's enough, I'd honestly count that as a good outcome: one more developer keeping an eye on their AI spend.

A note for other indie developers

If you're considering building a commercial product on open source, a few lessons from doing it:

Read the license carefully and follow it exactly.
Credit the original project prominently, not in a hidden footer.
Add real value rather than just repackaging.
Be kind about the comparison. The upstream project made your product possible.

Get TokenBar: https://tokenbar.site

DraftKey: Tab AI Autocomplete for Every Mac App ($4.99 Once)

Henry Godnick — Sun, 25 Oct 2026 15:52:32 +0000

DraftKey is a Mac app that suggests the next few words as you type, in almost any app, using an AI model. It costs $4.99 once, with no subscription, and you can get it at getdraftkey.com.

Disclosure up front: I built DraftKey. It's made by Aura Technologies, my small indie studio. This post is a straight description of what it does, who it's for, and where it falls short, so you can decide in two minutes whether it's worth five dollars.

What DraftKey actually does

You type in Mail, Slack, Notes, Linear, a browser text box, or your editor's commit message field. DraftKey reads the text around your cursor, uses a small language model to show a short gray suggestion. Press Tab and it's inserted. Keep typing and it goes away.

That's the whole product. It's not a chatbot, it doesn't rewrite your paragraphs, and it doesn't open a side panel. It's autocomplete for prose, system-wide.

Why I built it

I write a lot of short, repetitive text: support replies, ticket descriptions, release notes, PR summaries. Existing writing assistants were good at it, but I didn't want another monthly subscription for something this small.

DraftKey is built for Apple Silicon Macs and ships with a compact model for low-latency suggestions.

What you get for $4.99

System-wide suggestions in most apps that use standard macOS text fields.
No account required.
One-time purchase. $4.99, lifetime, no subscription.
Small footprint at rest. It lives in the menu bar and stays out of the way.

Honest limits (please read before buying)

I'd rather you skip DraftKey than buy it and feel misled.

There's no free trial. You pay $4.99 to try it. I know that's a real ask for an unknown indie app, which is why this list exists.
Apple Silicon and macOS 14 (Sonoma) or later only. Intel Macs and older macOS versions are not supported. The model needs Apple Silicon to be fast enough.
It downloads a ~1.12 GB model. If disk space is tight, factor that in.
It depends on the macOS Accessibility API. You have to grant Accessibility permission. Some apps expose their text fields poorly or not at all: certain Electron apps, some terminal emulators, custom-drawn editors, and secure fields. In those, suggestions may be missing or placed oddly.
It is not GPT-class. The model is small so it can be fast. It's good at finishing sentences and common phrasing in your context. It is not going to write a strong essay from a one-line prompt, reason through a hard problem, or match a frontier cloud model on quality.

If any of those is a dealbreaker, DraftKey isn't for you, and that's fine.

Who it's a good fit for

Developers and indie founders who write lots of short text (tickets, support emails, PR descriptions, Slack updates) and want it a bit faster.
Anyone tired of stacking $10–$20/month AI subscriptions for small conveniences.

Who should skip it

If you want a full rewriting or chat assistant, a cloud tool will do more.
If you're on an Intel Mac or pre-Sonoma macOS.
If you mostly type in apps with weak Accessibility support.

Other pay-once options

DraftKey isn't the only non-subscription AI writing tool on the Mac. Charm and RewriteBar are both worth a look if you prefer a one-time purchase. They lean more toward rewriting and transforming selected text, while DraftKey focuses on inline, as-you-type autocomplete. Depending on how you write, one of them may suit you better, or you may want one alongside DraftKey.

Permissions

The Accessibility permission is what lets it read text near your cursor in other apps; that's a macOS requirement for this kind of tool, and you can revoke it anytime in System Settings > Privacy & Security > Accessibility.

Getting started

Buy and download DraftKey from getdraftkey.com ($4.99 lifetime).
Open it and grant Accessibility permission when prompted.
Let it download the ~1.12 GB model once.
Start typing in Mail, Notes, or Slack and accept suggestions with Tab.

Feedback

DraftKey is a small product from a small studio, and I read every piece of feedback. If an app you use doesn't work well with it, tell me which one through the contact link on getdraftkey.com, and I'll look at what the Accessibility API exposes there.

If pay-once autocomplete that works across your Mac sounds useful, DraftKey is $4.99 at getdraftkey.com.

When to Kill a Codex CLI or Claude Code Session (and Start Fresh Instead)

Henry Godnick — Sun, 25 Oct 2026 15:12:58 +0000

There is a sunk-cost trap in AI coding sessions. You have spent forty minutes with Codex CLI or Claude Code on a task, the agent has built up a lot of context, and it feels wasteful to throw it away. So you keep going, nudging it with "no, try again," while each turn gets slower, more expensive and less accurate.

Very often, the right move is to kill the session and start a new one with a short summary. Here is how to tell when.

Why long sessions degrade

Agent sessions carry their entire history forward: every file read, every tool output, every failed attempt. As that grows:

Each turn costs more, because more context is sent each time.
Quality drops. Models handle huge contexts less reliably, and early mistakes stay in the history, influencing later turns.
Compaction loses detail. When tools auto-summarize to save space, specific facts like file paths or the exact error can vanish, leading to re-reading and repeated mistakes.
Plan limits drain faster, so you hit usage caps sooner.

A fresh session with a precise brief often outperforms a bloated one on the same task.

Seven signs it is time to restart

The agent repeats a fix it already tried. It has lost track of its own history.
It contradicts earlier decisions, such as reintroducing an approach you rejected.
You have corrected it on the same thing twice.
The task changed. You started fixing a bug and are now redesigning a module. New task, new session.
Spend or usage has climbed steadily without a commit. No checkpoint in 20–30 minutes is a red flag.
Compaction has happened more than once and the agent asks about things it already knew.
Responses are getting slower and vaguer.

Two or more of these and you should restart.

How to restart without losing progress

Killing a session does not mean losing the work. Do this first:

1. Commit or stash what is useful. If part of the diff is good, commit it on a branch. If none of it is, git stash or reset.

2. Ask for a handoff summary before exiting:

Summarize in under 150 words: the goal, what you changed, what
you tried that failed and why, and the current blocker. List the
relevant file paths.

3. Edit the summary. Remove wrong conclusions. Add what you know that the agent did not.

4. Start a new session with the summary as the first prompt, plus a tighter task statement: "Fix only the failing test in auth.test.ts. Do not change the session model."

This usually takes two minutes and saves far more than that.

Make restarts cheaper by design

Small tasks. Scope prompts to something finishable in one short session.
Persistent context files. Put project rules and architecture notes in CLAUDE.md or AGENTS.md so a new session gets them for free instead of rediscovering them.
Checkpoint commits. Ask the agent to commit after each passing step.
Worktrees for parallel attempts. If you are unsure which approach works, run two fresh sessions in separate git worktrees instead of one long one that tries both.

Use the meter as a tiebreaker

When you are unsure whether to push on or restart, look at what the session has cost so far against what it has produced. If usage has climbed steadily for half an hour and there is no commit, that is your answer. The problem is that many people never look, because usage lives in a web dashboard and the session lives in the terminal.

I use TokenBar, a Mac menu bar app that tracks Claude Code, Codex, Cursor and related AI usage so today's burn is always one glance away. It is $15 lifetime and built on the MIT-licensed CodexBar project. Disclosure: I built TokenBar (Aura Technologies). It will not make decisions for you, but it puts the number in view while you still have time to act on it.

A rule worth adding to your agent config

Agents follow explicit stop conditions well. Add something like:

If the same approach fails twice, stop and summarize what you
tried and what is blocking instead of trying variations.

This turns many would-be long sessions into short ones that end with a useful question.

Bottom line

Long sessions feel productive because you are invested in them. But context is not free, and history full of failed attempts actively hurts. When the agent starts repeating itself, drifting or burning usage without commits, save what is useful, get a summary and start fresh. It is cheaper, faster and usually gets a better result.

OpenAI vs Anthropic Spend Mix: How to Decide Which Model Gets Which Coding Task

Henry Godnick — Sun, 25 Oct 2026 14:10:55 +0000

Plenty of developers now pay both OpenAI and Anthropic: a ChatGPT plan for Codex, a Claude plan for Claude Code, plus some API usage for scripts. That is reasonable, since the models have different strengths. What usually is not reasonable is the split. Most people route tasks by habit, not by cost or fit, and end up running expensive models on trivial work.

This post is a practical framework for deciding which tasks go where and for checking whether your spend mix makes sense.

Start with what you actually spend

Before optimizing, measure one or two normal weeks:

Subscription costs for each provider
API spend for each provider
Which tools you use for which kinds of tasks
How often you hit plan usage limits on each side

Most people are surprised by one of two things: they barely use one of their subscriptions, or most of their API spend comes from a single kind of task, often long agent sessions.

Categorize your coding tasks

Rough categories work fine:

Quick questions and snippets. Syntax, small regexes, one-off scripts.
Focused edits. A bug fix or small feature in a known area.
Large agent tasks. Multi-file refactors, test suite fixes, migrations.
Review and reasoning. Code review, architecture questions, debugging hard issues.
Batch or scripted work. Generating docs, classifying issues, CI tasks via API.

Match tasks to the cheapest adequate option

The principle: use the cheapest model and billing path that does the task well, not the best model available.

Quick questions: small or fast models, or free tiers. Using a top reasoning model for "how do I reverse a list in Swift" is wasted spend.
Focused edits: whichever agent you are fastest with, on a flat-rate subscription so iteration is not metered.
Large agent tasks: subscriptions are usually better than API billing here because agent sessions resend large contexts many times. Rotate between providers when one plan's limits run out instead of switching to pay-per-token.
Review and reasoning: this is where top models earn their price. Spend here deliberately.
Batch work: API with smaller models, batch pricing where offered, and hard spend caps.

Which provider is "better" at each category changes with every model release, so test periodically on your own codebase instead of trusting benchmarks or social media.

Signs your mix is off

You pay for two plans but one sits mostly unused. Downgrade or cancel it.
You hit limits on one plan every week while the other has headroom. Shift agent work.
Your API bill is dominated by agent sessions. Move them to a subscription.
You use the most expensive model for everything. Set a cheaper default and escalate manually.

A simple routing rule set

Write it down so you do not decide every time:

Default: Provider A subscription agent for day-to-day edits.
When A limits hit: switch to Provider B agent, same task.
Hard bugs / review: top reasoning model, either provider.
Scripts and CI: API, small model, capped at $X/month.

Putting this in your notes or a team README stops the drift toward "whatever tab is open."

Visibility across both providers

The hard part of a two-provider setup is that the numbers live in different places: two billing consoles, two sets of usage limits, plus whatever your IDE reports. You only notice imbalance at the end of the month.

With both providers visible side by side, patterns become obvious within a week, like Claude limits hit every Thursday or Codex barely touched, and you can adjust the routing rules accordingly.

Re-evaluate monthly

Models and pricing change constantly. Once a month:

Compare total spend per provider to the previous month.
Check which plan hit limits and when.
Try your hardest recent task on the other provider's current model.
Update the routing rules.

This takes fifteen minutes and is often worth more than any single prompt trick.

Bottom line

Paying for both OpenAI and Anthropic can make sense, but only if each one is doing the work it is cheapest and best at for you. Measure for a week, categorize your tasks, write a routing rule set and review it monthly. The goal is not loyalty to one provider; it is spending money where it actually improves your code.

A $50-a-Month AI Coding Stack for Students: What to Pay For and What to Skip

Henry Godnick — Sun, 25 Oct 2026 13:14:01 +0000

If you are a student learning to code in 2026, AI tools are everywhere and so are subscriptions. Claude, ChatGPT, Cursor, GitHub Copilot, Codex and a dozen others all want $10 to $20 a month, and some of the "pro" tiers cost far more. Stack three or four and you are spending more on AI than on your phone plan.

This is a realistic plan for keeping AI coding costs around $50 a month without crippling your learning. Prices change often, so check current pricing pages before you commit; the structure matters more than the exact numbers.

Step 1: claim everything free first

Before paying for anything:

GitHub Student Developer Pack. Verified students have historically gotten free GitHub Copilot access, plus credits for various cloud and dev tools. Check what is currently included.
Education discounts. Several AI tools and IDEs offer student pricing or free tiers. Search "[tool] student" before paying list price.
Free tiers. Most chat assistants have free tiers that are fine for occasional questions.
University licenses. Some schools provide access to AI tools through campus agreements. Ask your department or IT.

Many students can cover inline autocomplete entirely for free this way.

Step 2: pick one primary paid tool

The biggest waste is paying for overlapping tools. Pick one primary assistant that you will use for real work:

If you mostly work in an editor and want agent features, an AI IDE plan.
If you are comfortable in the terminal, a Claude or ChatGPT plan that includes Claude Code or Codex CLI.

One $20 plan, used well, beats three $20 plans used casually. That leaves room in the budget.

Step 3: keep a small pay-as-you-go buffer

Put $10–$20 a month into API credits for occasional heavy tasks or experimenting with models. API billing charges per token, so it is cheap for light use and dangerous for long agent sessions. Set hard spending limits in the provider console. Both OpenAI and Anthropic let you set usage limits; use them.

A sample $50 budget

Item	Approx. monthly
Copilot via student pack	$0
One primary assistant plan	$20
API credits buffer (hard capped)	$15
Free chat tiers for quick questions	$0
Reserve for a one-off month of a second tool	$15

The reserve is intentional. Some months you will want to try a new tool for a project. Budget for it instead of letting subscriptions pile up.

Step 4: track it

Students overspend on AI the same way everyone does: not on one big charge but on forgotten subscriptions and long agent sessions on API billing. Two habits help:

A subscription list. A note with every AI subscription, its price and its renewal date. Cancel anything you have not used in two weeks.
Live usage visibility. Subscription plans have usage limits; API billing has a meter. Seeing both while you work stops surprises.

For a student, a one-time $15 tool is worth it only if it saves you from at least one bad month. Free dashboards and the provider consoles also work if you check them regularly; the point is checking at all.

Step 5: use AI in ways that actually teach you

Budget is half the problem. The other half is not letting the tools do your learning for you:

Write first, then ask. Attempt the function yourself, then ask the AI to review it. You learn from the diff.
Ask for explanations, not just code. "Why does this cause a race condition?" is a better prompt than "fix this."
Turn off autocomplete for practice. For algorithm practice or exam prep, disable inline suggestions.
Check your school's policy. Many courses have explicit rules on AI use. Follow them.

Agents are great for boilerplate and exploration but can hide the fundamentals you are supposed to be learning. Spend budget where AI saves time, not where it replaces understanding.

What to skip

Premium "max" tiers. They are aimed at professionals running agents all day.
Multiple overlapping editors with AI built in.
Annual plans before you have used a tool for at least a month.
Uncapped API keys. Always set a limit.

Bottom line

$50 a month is plenty for a student if you claim free education offers, pay for one primary tool, cap your API spending and keep an eye on usage. The goal is not the cheapest possible setup; it is a setup you understand, can afford, and that helps you learn faster rather than skip the learning.

Spotting Runaway AI Agent Loops Early: Spend Spikes as an Alarm

Henry Godnick — Sun, 25 Oct 2026 12:08:18 +0000

An AI coding agent stuck in a loop is quiet. It does not crash. It keeps reading files, running tests, editing the same function and re-running the tests, and every iteration costs tokens. By the time you come back from lunch, a ten-minute task has turned into a long, expensive session with nothing to show for it.

The cheapest signal that something is wrong is not in the terminal output. It is the spend curve. This post covers what runaway loops look like, why they happen, and a simple way to catch them before they matter.

What a runaway loop looks like

Common patterns with Claude Code, Codex CLI, Cursor agent mode and similar tools:

Fix-test-fail cycles. The agent edits code, a test fails, it edits again, the same test fails in a slightly different way. Ten rounds later the diff is bigger and nothing passes.
Re-reading the world. The agent repeatedly greps or reads large files because it lost track of context after compaction.
Tool error retries. A command fails (missing dependency, wrong path, a permission prompt) and the agent keeps trying variations.
Scope creep. The agent "notices" related issues and starts refactoring things you never asked about.

Each of these looks like progress in the log. They look very different on a cost graph.

Why spend is a better alarm than output

Normal work is bursty: a big read at the start, some edits, a test run, done. Spend rises and then flattens. A loop has a steady slope that does not flatten, because the agent keeps re-sending a large context every turn. Context size grows as the session goes on, so each loop iteration tends to cost more than the last.

Watching the terminal, you see plausible messages. Watching spend, you see a line that keeps climbing at the same rate for twenty minutes. That second view is easier to judge at a glance.

Set your own thresholds

There is no universal number. Calibrate from your own history:

Look at a week of normal sessions. Note what a typical small task costs and what a big one costs.
Set a soft alarm at around 2x your typical big task. That is "go look."
Set a hard stop at an amount you would be annoyed to lose on a single session.

For a solo developer this might be a few dollars soft and somewhat more hard. For a team running agents in CI it should be enforced in code.

Practical guardrails

Cap turns or time. Many agent tools let you limit iterations or run headless with a max-turns setting. Use it for unattended runs.

Make the task smaller. Loops are far more common on vague tasks. "Make the tests pass" invites thrashing. "Fix the null check in parseConfig so config.test.ts passes" does not.

Fix the environment first. Many retry loops come from a broken setup: missing env vars, wrong Node version, a flaky test. If the agent fails a command twice, the problem is usually not the agent.

Commit checkpoints. Ask the agent to commit after each passing step, or use git worktrees. If a loop starts, you reset to the last good state instead of untangling a giant diff.

Clear context deliberately. Long sessions accumulate context. Starting fresh with a short summary is often cheaper and smarter than letting a session drag on.

A simple routine

Start the task and note current spend.
Glance at spend every 10–15 minutes, or when you get a notification.
If the slope has not flattened and the agent has not committed anything useful, interrupt.
Ask it to summarize what it tried and what is blocking. Often the summary reveals the real problem in one line.
Restart with a narrower prompt, or fix the blocker yourself.

The key habit is having the number visible without opening a dashboard. If you have to log into a billing page to check, you will not check.

What to do after a loop

Treat it as a cheap postmortem:

What was the prompt? Was it vague?
What did the agent get stuck on? Environment, test flakiness, missing context?
Could a rule prevent it? Add a line to CLAUDE.md or AGENTS.md, such as "If a command fails twice with the same error, stop and ask."

That last rule alone prevents a surprising number of loops. Agents follow explicit stop conditions well; they just are not given many.

Bottom line

Runaway loops are not a reason to stop using agents. They are a reason to watch the one metric that captures every failure mode at once. Output can look fine while the agent spins. Spend does not lie about how much work is being repeated.

Tracking Token Spend Across Claude Code, Codex CLI and Cursor on One Mac

Henry Godnick — Sun, 25 Oct 2026 02:12:21 +0000

One tool was manageable. Three is how solo developers lose the plot: Claude Code for agentic refactors, Codex CLI for quick terminal tasks, Cursor for inline edits—each with its own meter, plan, or API key. The Mac becomes a bundle of progress bars you never look at until something rate-limits mid-flow.

You do not need a finance department. You need one glanceable total and a weekly habit.

Inventory what you actually run

Make a three-line list (honest beats complete):

Claude Code — seat / API — heavy agent sessions
Codex CLI  — API key     — terminal one-shots
Cursor     — sub         — tab complete + chat

Add anything else that burns tokens on the same machine (ChatGPT desktop, local proxies, CI that uses your key). If it can surprise you, it belongs on the list. Revisit the inventory when you install a new AI CLI—most cost leaks start as "just testing."

One visible surface beats three dashboards

Cloud dashboards are accurate and ignored. While you are in a coding trance, only something in the menu bar or a status line gets seen.

Options people actually stick with:

A menu bar usage app that understands multiple AI CLIs.
Shell prompts that show the active key or project (helps attribution, not totals).
A Friday export into a single CSV or note.

Ideal combo: live glance plus Friday number. If you only keep one, keep the live glance; it changes behavior the same day.

TokenBar is aimed at that menu-bar glance for Claude, Codex, and related usage on macOS ($15 lifetime; built on the MIT-licensed open-source CodexBar). Disclosure: I built TokenBar. Pair it with whatever Cursor's account page shows so you do not double-count or miss the IDE side.

Attribute by project, not by vibes

When two client folders and a side project share a machine:

Use different API keys or at least different env files per client.
Name git worktrees and terminal tabs with a project prefix.
Once a day, peek at which tool burned the most—not every token, just the winner.

If everything shares one key, you can still approximate with time blocks ("morning = client A") but do not pretend it is accounting. For invoices, approximation without a written method becomes an argument.

A 10-minute Monday setup

# Per-project env (example)
cd ~/work/client-a && echo 'export ANTHROPIC_API_KEY=...' >> .envrc
cd ~/work/personal && echo 'export ANTHROPIC_API_KEY=...' >> .envrc

# Confirm which tools are installed
which claude codex cursor 2>/dev/null

Pin TokenBar (or your meter) on the menu bar. Disable duplicate meters that you never check—noise trains you to ignore all of them. Put the Friday review on the calendar so it survives busy weeks.

Weekly review questions

Every Friday, five minutes:

Which tool took most of the spend?
Did any session look like a loop or stuck retry?
Did personal and billable work share a key by mistake?
Any limit hit that blocked shipping?

Write three lines in a ai-spend.md note. Patterns show up by week three. If the same spike repeats, fix the workflow (context size, hooks, concurrency) before you change plans again.

Failure modes

Watching Cursor but ignoring CLI agents — agents often dominate cost.
Resetting keys without labeling them — last month's CSV becomes fiction.
Optimizing price before measuring — switch plans only after two quiet weeks of numbers.
Three overlapping meters — pick one primary glance and demote the rest.

One Mac can run three AI coding tools without financial fog. Put spend where your eyes already go, separate keys when money matters, and keep a tiny Friday ritual. That is the whole system.

How the three tools usually split spend

Patterns many solo Mac setups see after a few weeks of honest logging:

Cursor — steady, relatively predictable; the subscription hides per-token noise, so the risk is complacency, not surprise invoices.
Codex CLI — often cheap per task; cost creeps when you script loops or paste huge logs.
Claude Code — can dominate the week whenever you leave a long agent unsupervised or reload giant contexts.

Your mix will differ. The point of cross-tool tracking is noticing when the mix changes—for example, a week where Codex suddenly rivals Claude because a new script is polling. Without one glance surface, that shift shows up only as a vague feeling that "AI got expensive."

Alerting without noise

You do not need real-time pages. You need:

A visual cue when today's burn is unusually high (menu bar color or a number you recognize).
A hard cap on API keys used for experiments.
A personal rule: no new agent session after you have already hit a limit once that day—go outside or write the PR by hand.

Automation that emails you every $1 is worse than no automation. Prefer thresholds you will actually respect.

CLAUDE.md and AGENTS.md Templates for Claude Code and Codex CLI: What to Put In, What to Leave Out

Henry Godnick — Sun, 25 Oct 2026 01:12:56 +0000

A practical guide to project instruction files for Claude Code and Codex CLI: where they live, what belongs in them, and how to keep one file working for both tools

If you use Claude Code or OpenAI's Codex CLI for long, you start repeating yourself. "Use pnpm, not npm." "Don't touch the generated client." Every session starts with a fresh context window, so the agent forgets all of it.

Both tools solve this the same way: a Markdown file in your repository that the agent reads at the start of every session. Claude Code calls it CLAUDE.md. Codex calls it AGENTS.md. Many of these files end up nearly empty or several screens of prose the agent half-follows. Here's how to write one that earns its place.

What these files are, and where each tool looks

Claude Code: CLAUDE.md

Claude Code reads CLAUDE.md files from a few places, and it combines them instead of picking one:

User level: ~/.claude/CLAUDE.md applies to every project on your machine. Put personal preferences here.
Project level: ./CLAUDE.md or ./.claude/CLAUDE.md in the repo. This is the one you commit and share with your team.
Local level: ./CLAUDE.local.md is for your own project-specific notes. Add it to .gitignore.

At launch, Claude Code loads these files from your current working directory and every directory above it, and concatenates them. The file closest to where you launched is read last. Files in subdirectories don't load at launch. Each one loads when Claude reads or edits a file in that subdirectory. That makes a packages/api/CLAUDE.md a good home for rules that only matter in that package.

Anthropic's docs are clear that CLAUDE.md is context, not enforced configuration. Claude reads it and tries to follow it, but nothing guarantees compliance. If something must never happen, use a permission rule or a hook, not a sentence in a Markdown file.

Codex CLI: AGENTS.md

Codex builds what it calls an instruction chain when it starts:

Global: ~/.codex/AGENTS.md (or the CODEX_HOME directory if you've set it). An AGENTS.override.md in the same place takes priority if it exists.
Project: starting at the project root (usually the Git root), Codex walks down to your current working directory and picks up at most one instruction file per directory. In each directory it checks AGENTS.override.md first, then AGENTS.md.

Files are joined from the root down, so a file in a nested directory appears later and can override broader guidance. A few details are worth knowing. Codex skips empty files, and it stops adding files once the combined size reaches project_doc_max_bytes, which defaults to 32 KiB. Also, unlike Claude Code, Codex stops at your current directory. It doesn't pick up files from subdirectories below where you launched, so start Codex from the directory whose rules you want.

Both tools can draft one for you

Claude Code and Codex both have an /init command. In Claude Code, it analyzes the codebase and writes a starting CLAUDE.md with build commands and conventions it finds. In Codex, it generates an AGENTS.md scaffold in the current directory. Treat either as a first draft: the useful part is what you add that the agent couldn't work out by itself.

What to put in

A good test for every line: would a capable new teammate need to be told this, or would they figure it out by reading the code? Write down the first kind.

Commands, exactly as you run them. Install, build, test, a single test file, lint, type-check. Agents run these constantly, and guessing wrong wastes a whole loop. Write pnpm test -- path/to/file rather than "run the tests."

A short map of the repo. Not every folder, just where the important things live and anything surprising. "API handlers are in src/api/handlers/. Shared types are in packages/types, not in each app."

Conventions that differ from the defaults. If your team does something the agent wouldn't assume, say so: a specific error-handling pattern, a naming rule, a preferred library over a more popular one.

Gotchas. The things that bit you. The test suite needs a local Redis. A module is imported dynamically, so "unused" doesn't mean unused.

What not to touch. Generated files, vendored code, lockfiles you don't want rewritten, a legacy directory under a freeze. Be explicit and use paths.

How to check the work. What "done" means: tests pass, lint is clean, types check. Agents do better when they know how to verify their own changes.

Anthropic's guidance on phrasing is worth copying: make instructions concrete enough to check. "Use 2-space indentation" instead of "format code properly." "Run npm test before committing" instead of "test your changes."

What to leave out

Long prose. Paragraphs of background are harder for the model to act on. Use headings and short bullets.

Things the model can infer. Every dependency, a full directory tree, an explanation of React. The agent can read package.json and the file system. Claude Code's /doctor checkup flags this kind of content as derivable from the codebase.

Secrets. No API keys, tokens, passwords, or internal URLs you wouldn't want in Git history. The project file is committed to source control and goes straight into the model's context every session. Point to where credentials come from ("read from .env.local, which is gitignored") instead.

One-off procedures. A ten-step release checklist doesn't need to be in every session. Claude Code has skills and path-scoped rules in .claude/rules/ for instructions that should load only when relevant. In Codex, a nested AGENTS.md keeps service-specific rules out of the root file.

Contradictions. If your user-level file says one thing and the project file says another, Anthropic's docs warn that Claude may pick one arbitrarily. Review all the layers together now and then.

Keep it short, because you pay for it every session

This is the part people underestimate. Your instruction file is loaded into context at the start of every session, before you type anything. Every line is input tokens you pay for, in money on the API or usage limits on a subscription, and room your actual task could use.

Length hurts quality too. Anthropic recommends keeping each CLAUDE.md under 200 lines and notes that longer files reduce adherence. Splitting a file with @imports helps organization but doesn't reduce the cost, because imported files also load at launch. Codex enforces a hard ceiling with its 32 KiB default, and anything past it simply doesn't get added.

Two small tricks help. In Claude Code, block-level HTML comments in CLAUDE.md are stripped before the content reaches the model, so you can leave notes for human maintainers at no context cost. And before adding a line, ask whether you've actually had to correct the agent about it. Anthropic suggests adding to the file when the agent makes the same mistake twice.

A concrete example

Here's an AGENTS.md for a hypothetical TypeScript monorepo, short on purpose.

# AGENTS.md

## Commands
- Install: `pnpm install` (never npm or yarn)
- Dev server: `pnpm dev --filter web`
- All tests: `pnpm test`
- One test file: `pnpm vitest run path/to/file.test.ts`
- Lint and types: `pnpm lint && pnpm typecheck`

## Layout
- `apps/web`: Next.js frontend
- `apps/api`: Fastify server; route handlers in `src/routes/`
- `packages/types`: shared types. Import from here, don't redefine.

## Conventions
- Return errors as `Result<T, AppError>` from `packages/types`; don't throw in route handlers.
- Use `zod` schemas in `src/schemas/` for all request validation.
- New UI components go in `apps/web/components/ui/`.

## Gotchas
- API tests need Redis running locally: `docker compose up redis`.
- Run database migrations from the repo root only: `pnpm db:migrate`.

## Do not touch
- `packages/api-client/generated/` (regenerate with `pnpm codegen`)
- `pnpm-lock.yaml`, except through `pnpm install`

## Before you finish
- `pnpm lint && pnpm typecheck && pnpm test` must pass.

Notice what's missing: no project history, no explanation of Next.js, no full file tree, no credentials. Every line is a command, a location, a non-default rule, or a trap.

One file for both tools

If your team uses both tools, you don't want two files drifting apart. The official docs offer three options:

Let Claude Code read AGENTS.md directly. Recent versions of Claude Code read AGENTS.md as the project instructions when there's no CLAUDE.md or CLAUDE.local.md in your working directory or above it. One catch: adding a CLAUDE.local.md counts, and by default it stops Claude from reading AGENTS.md. You can change that with the Project instructions setting in /config.

Import it. Create a CLAUDE.md next to your AGENTS.md whose first line is @AGENTS.md, then add any Claude-specific notes below it under their own heading. Claude Code expands the import at launch. This is the most predictable setup, and it works even in sessions that can't load AGENTS.md on their own. Anthropic's docs note that keeping the import never makes Claude read the file twice.

Symlink it. If you have nothing Claude-specific to add, ln -s AGENTS.md CLAUDE.md works. Anthropic recommends the import instead if anyone on the team uses Windows, where symlinks need extra setup and Git may check the link out as a plain text file.

Whichever you pick, verify it. In Claude Code, run /context and check that the file appears under Memory files. In Codex, the docs suggest running codex --ask-for-approval never "Summarize the current instructions." from the repo root and checking that it echoes your guidance.

A short checklist

The file lives where the tool looks: project root for team rules, ~/.claude/CLAUDE.md or ~/.codex/AGENTS.md for personal ones.
Build, test, single-test, lint, and type-check commands are written exactly as you run them.
The repo map covers only the important or surprising parts.
Conventions listed are ones that differ from what the agent would assume.
Gotchas and "do not touch" paths are explicit.
Nothing the agent can read for itself, and no secrets.
Bullets and headings, not paragraphs.
Comfortably under 200 lines, with niche rules moved to nested files or path-scoped rules.
No contradictions between user, project, and nested files.
Hard requirements are enforced with hooks or permissions, not just written down.
You checked that the file actually loaded.
You prune it when the project changes.

A good instructions file is less a manual than a list of things you're tired of repeating. Start with the /init draft, cut what the agent could figure out, and add a line each time you correct the same mistake twice.

Disclosure: I built TokenBar, a $15 Mac menu bar app that shows your Claude and Codex usage and cost, partly so I could see how much a bloated instructions file was costing me. It's at https://tokenbar.site if that's useful.