[BUG] out of credits in 3 days, as a hobbyist.

Status Fixed / completed
Reported on v2.1.193
Maintainer reply None cached
Activity 7 comments · opened Jun 26, 2026 · closed Aug 17, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Low token quota

What Should Happen?

Being able to use this tool for the full length of my usage.
I’m not interested in an aperitif for 25usd.

Error Messages/Logs

Steps to Reproduce

Use claude code.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.193 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Xterm

Additional Information

_No response_

View original on GitHub ↗

6 Comments

yurukusa · 2 months ago

You're on the Anthropic API (metered, pay-per-token), so what you're seeing is billing-as-designed rather than a bug — but the upside is that API cost per session is very controllable, and a few changes usually cut it by more than half for the same work. Roughly in order of impact:

  1. Cache reads are the single biggest lever. On the API you re-pay for the whole context every turn unless it's served from the prompt cache. If your cache-read rate is low, you're paying full price to re-send the same files and instructions on every message. Keep the early part of the conversation stable — don't keep editing files that sit near the top of the context — and avoid actions that invalidate the cache mid-session.
  2. /clear between unrelated tasks. Carrying one long session forward means every new message re-sends all the prior context, at full token cost. A fresh session per task is usually the easiest large saving.
  3. Model choice. Opus is several times the per-token cost of Sonnet. Use Sonnet for routine reads/edits and only reach for Opus on the genuinely hard problems. "Sonnet-first" alone is often the biggest single drop in spend.
  4. Trim what's re-sent every turn. A large CLAUDE.md and many connected MCP servers both get injected into context repeatedly — on the API you pay for that on every message. Cut CLAUDE.md to the essentials and disable MCP servers you aren't actively using.
  5. /compact before a session gets huge (a ~120k-token context compacts to ~40k), so you stop dragging the full history forward.

None of these change what the tool can do — they change how many tokens the same work costs. If you want to see where it's actually going first, the per-message token breakdown (cache read vs. write vs. fresh input) tells you which of the above will help most; for most people who burn through credits fast, it's #1 and #3.

blixten85 · 2 months ago

I’m on a subscription called PRO. Don’t know if that’s what you’re talking about.
But nevertheless, the limit should be increased with the double, minimum. Or no limit at all.
If google could do it with their search engine then Anthropics can do it to.

People will jump ship as soon as there is a alternative and they won’t look back unless it’s a very very good reason to.

TheRealScarHomie · 2 months ago
I’m on a subscription called PRO. Don’t know if that’s what you’re talking about. But nevertheless, the limit should be increased with the double, minimum. Or no limit at all. If google could do it with their search engine then Anthropics can do it to. People will jump ship as soon as there is a alternative and they won’t look back unless it’s a very very good reason to.

theyre having massive issues with counting tokens for usage at the moment, huge error, affecting loads of people. Even on a max plan same thing, 1 message is 3% of weekly usage when before it wouldnt have even been 0.1%. The limit has been drastically reduced hopefully by an error and not anthropic shafting everyone without saying anything, so hopefully we can hope a reset and acknowledgement of the issue soon. Also ignore the AI slop response above, has no idea what its talking about and I dont even think they used claude to generate that lmao.

blixten85 · 2 months ago
> I’m on a subscription called PRO. Don’t know if that’s what you’re talking about. But nevertheless, the limit should be increased with the double, minimum. Or no limit at all. If google could do it with their search engine then Anthropics can do it to. > People will jump ship as soon as there is a alternative and they won’t look back unless it’s a very very good reason to. theyre having massive issues with counting tokens for usage at the moment, huge error, affecting loads of people. Even on a max plan same thing, 1 message is 3% of weekly usage when before it wouldnt have even been 0.1%. The limit has been drastically reduced hopefully by an error and not anthropic shafting everyone without saying anything, so hopefully we can hope a reset and acknowledgement of the issue soon. Also ignore the AI slop response above, has no idea what its talking about and I dont even think they used claude to generate that lmao.

In such cases they should remove the broken limits.
Why am I as end user going to suffer from a company’s wrong doing?
All I will do is to hate it and wait until there is a better opportunity around and jump ship as soon as possible.

I guess I’m not the only one. Really irritating these limits. And on top of that I’m feeding this machine with new data that it will train on, regardless if i have given my consent about it or not.

Maybe china is the solution, a new version of their DeepSeek will probably be golden.

yurukusa · 1 month ago

@blixten85 I owe you a correction — you told me you're on Pro, and I answered as if you were on the pay-per-token API. That was my mistake, and it changes the advice, so let me redo it properly. I re-checked and verified the Pro usage-limit and /usage behaviour against the current Claude Code docs before writing this, so I don't steer you wrong twice.

The key difference: on Pro, usage is included in the subscription — you're not paying per token, so "out of credits in 3 days" isn't per-request billing, it's you hitting your plan's usage limit. On a subscription that usage is measured over rolling windows, and /usage shows you the last 24 hours and the last 7 days — which is why it can feel like you burn through it in a few days and then it resets.

The concrete thing to run is /usage inside Claude Code. On a subscription plan it shows a breakdown of what is counting against your plan limit — attributed to skills, subagents, plugins, and individual MCP servers, each as a percentage of the total — and you can press d / w to switch between the last 24 hours and the last 7 days:

/usage

That breakdown is the actual lever, because on Pro you can't change a per-token setting — the only way to get more done before you hit the wall is to consume less per turn. From the /usage view, the usual culprits and fixes:

  • Subagents / parallel work burn the limit fastest — each one is its own context. Cut back on spawning them for small tasks.
  • /clear between unrelated tasks, so you're not re-sending a long history on every message.
  • MCP servers you're not using still load their tool definitions into context — disable the ones you don't need.

One honest caveat, because @TheRealScarHomie raised it above: if your /usage breakdown looks abnormally high for the amount of work you actually did — e.g. a single message eating a big chunk of the weekly limit — that isn't something you can fix by trimming your own setup. That would be a usage-accounting problem, not a config one, and the right move is to report it separately with your /usage numbers attached.

If, after trimming, you still hit the weekly wall doing normal work, then it's a genuine capacity mismatch, and the honest answer is that no setting removes the cap on Pro — it's either pacing the heavy work across the reset, or moving up to Max, which gives more headroom (Anthropic lists it as roughly 5×–20× the Pro usage) but is still a higher cap, not an unlimited one. Sorry again for the wrong first read.

blixten85 · 1 month ago

Yes I understand, but I don’t like it. I don’t want to juggle this around all the time just so i maybe could reduce token usage, guessing when I can do it without harming the task of my hobby project.

This is an Anthropics problem that has been pushed over to the users to ”solve” by either this manual labor you are describing with /clear and /compact and starring at /usage all the time.
Or, their absolute favorite; pay more.
And i don’t feel like doing any of that. And i don’t care about their situation regarding hardware cost, the so very often subsidy’s of electricity they use.

They are training their models on my data, on my input in every imaginable aspect. And I’m still to pay for subscription, a higher subscription, pay per use on top of that. And it’s no small money either.
Google managed to keep their stuff free from cost for the user, at least money wise.
Linux does it as well.
But this race of AI, I’m going to be one of the buckets these companies suck dry? Money, input of data, limitations by the hour, by the week, by classifications, still have to babysit the AI.
Like I’m paying with all of this just to be a beta and bug tester and hopefully I could get something done on my projects?

Let me put it in this way, Anthropics can use and abuse this all they want with any excuse they deem fit.
But when a better solution pops up that are more accurate, faster, less politics in the classification system that decides what is allowed to create/develop, cheaper / preferable free then I’m going to jump ship right away and I won’t look back or being loyal or something like that. And i don’t care if this tool comes from China or even North Korea.

EDIT:

```You are currently using your subscription to power your Claude Code usage

Current session: 22% used · resets Jul 9, 8:39am (UTC)
Current week (all models): 100% used · resets Jul 12, 7:59pm (UTC)
Current week (Fable): 0% used

breakdown · sonnet: 96% · opus: 3% · haiku: 0% · cache hit: 99%

The weekly limit is the biggest issue by far.

Showing cached comments. Read the full discussion on GitHub ↗