Lessons from Burning $100 on Claude Code

When I was a kid, I heard an old parable about a technician who was hired by a factory owner to fix a problematic machine. After careful investigation, the technician fixed the broken machine with a single, powerful hammer strike. The owner was really happy to see it working again but was immediately dismayed to see the $101 bill. He complained that all the technician did was strike the hammer once. "Anyone can strike a hammer!" The technician replied, "True, but it's $1 to swing the hammer, and $100 to know where to strike."

Like the factory owner, I just paid Claude $101 to fix my website. And although it eventually did find the issue, it was far from a single strike and even farther from knowing where to strike!

The setup

I had to fix a small bug in the AI Pilots Club website. For better user experience, I wanted a table of contents to flow along with the article, allowing people to see the titles before they read the contents. But for some unknown reason, it wasn't scrolling along and was fixed on top. Now any respectable frontend developer would be able to fix this in an instant, but with limited frontend experience and no expert at hand, I turned to the next "reliable" assistant: Claude.

My Usual Claude Setup

Usually I use Claude Code along with my monthly subscription because it's cheaper.

The drawbacks are:

• It offers only Claude Sonnet 4.5 in Claude Code
• There's a ~44,000 token limit which gets reset every 5 hours

For the most part, I'm able to manage with these limits, but it's becoming more and more restrictive as my dependency on Claude Code increases.

Another slightly frustrating thing: the 5-hour refresh window doesn't get kicked off until you pass your first token. This means that if you're doing token-intensive work (i.e., going through lots of files), you can exhaust your quota fairly quickly.

How I Burned Through My Quota

This is exactly what happened in this case. To investigate the scrolling problem, Claude Code went through some CSS files (which are gargantuan) and within about 30 minutes I exhausted my token quota. To make matters worse, I wasn't even able to isolate the problem and Sonnet was making edits that made no difference.

Usually, when I exhaust my quota, I switch over and do something else. But this time I was keen on solving this problem at the earliest because I wanted the website to be up with this feature! Also, the frustration of not finding the cause was overbearing.

I saw this as an opportunity to do two things:

• Try out the Claude API to test if I really needed a monthly subscription (or just use a pay-per-token plan)
• Try out the Opus 4 model (bigger in size and predicted to be better in performance)

So I did just that. I used AWS Bedrock as a model provider (I will talk about using Bedrock in another post, it's just another provider for model inference)

Switching to Opus via API

It didn't take much to set it up and I was all set. The session started and I was using the shiny Opus model.

Opus, being a "bigger model" than Sonnet is expected to be better at complex tasks, so I thought it was worth invoking.

Model Comparison

The one disappointing point was that the TFFT (Time for First Token) was relatively high, so every request had quite some latency. I didn't really feel it so much when using Claude directly with Anthropic. Probably something to do with the selected AWS region but it didn't investigate it further at the time.

Ignoring that, I had the familiar usage experience. I must note that Opus didn't seem significantly superior, and it was making similar mistakes as Sonnet (i.e., code edits without any real solution to the actual problem on loop)

The Psychological Shift

But psychologically, something had changed: Before, I used to keep monitoring my token usage with the fear that a single operation would nuke my token count. But now, I knew that I could keep working with the only risk being a massive bill. (But we can worry about that later!)

So I started doing some serious root cause analysis, slicing through the codebase, and reducing files till I could reproduce the error.

After a nearly two-hour search, we found the problem. (A stupid line of CSS I had introduced to fix horizontal scroll) Phew!

It felt so good, my mood completely changed. My monthly subscription token count was also about to be reset so life was so good!

Of course, until I shut down the API billing and was slapped with a $101 bill. Hahaha!

The Cost Reality

The issue is that while Opus is touted to be superior, it is also very costly if billed per token.

($15 / MTok Input tokens and $75 / MTok output tokens, /MTok stands for per million tokens)

If I had to do it all over, I would have used the smaller and cheaper Sonnet 4.5 ($3 / MTok Input and $15 / MTok output) but hey, I had to try out opus!

So a bittersweet end, where on one side the website is slick and ready for you to browse, but on the other I'm paying through the nose just so that I can identify my problems in a faster and more engaging way. (Collaborative coding with an agentic model is a very engaging experience.)

My Recommendations

Based on this experience, what would be my recommendations?

If money is not the top concern for you: Use Opus/Sonnet unrestricted (through API).

Why? Because all you should be worried about is solving the problem. Rationing token limits while working can get very distracting.

But that's unrealistic, especially for people in countries like India. ($100 is roughly about ₹9k which is my cook's monthly salary.)

In which case, I have good news. You have two paths:

1. For sure get a Claude Pro subscription. 44k tokens per 5 hours is reasonable if you ration your tasks. Bonus: use a free provider in tandem like Gemini CLI. (Poor integration with VS Code, but great model capability. And did I tell you it's free?)
2. Do consider a Claude Max subscription with 5x usage limits for $100. I now think it's worth it (after burning that in 3 hours!)

That's it for this one.

For more AI news and views, subscribe to AI Pilots Club.