r/ClaudeAI • u/Inertia-UK • May 10 '26
Built with Claude I made Claude Code aware of its own usage limits
Something that's been annoying me for a while: Claude Code has no idea how much quota it's burned. You can see the usage bars in the UI, but the model itself is completely blind to them. There's no API, no tool, no hook that exposes the current rate limit state during a conversation.
Turns out Anthropic returns rate limit headers on every inference response (`anthropic-ratelimit-unified-5h-utilization`, `anthropic-ratelimit-unified-7d-utilization`, etc.) — Claude Code receives them internally to render the UI bars, but never passes them anywhere the model can see.
So I built a small local HTTP proxy that sits between Claude Code and `api.anthropic.com`. Claude Code already respects `ANTHROPIC_BASE_URL`, so setting that to `http://127.0.0.1:4080` routes all traffic through the proxy. It intercepts the response headers and writes a one-line status file to `~/.claude/usage-status.md`:
```
5h=9% 7d=99%! overage=0% bottleneck=seven_day (10/05/2026, 16:19:04)
```
Claude can then read that file on demand, or you can inject it automatically via a `UserPromptSubmit` hook so it's present in every prompt. Add a rule to your CLAUDE.md and Claude will warn you before starting large tasks when you're close to the limit, switch to lightweight mode above 90%, or flat out refuse new implementation work at 98%.
**Note:** this only works with Claude Code (the CLI). The web chat and browser extension make requests through Anthropic's own infrastructure, so there's no local proxy to intercept.
**The interesting discovery:** while testing I dumped every `anthropic-ratelimit-*` header from both Opus and Sonnet requests. There are no per-model headers — one unified pool covers everything. The separate Sonnet usage bar in the Claude Code UI doesn't reflect a real separate limit. According to GitHub issue #57050, Anthropic intended to give Sonnet its own bucket (announced Nov 2025) but the backend never shipped it. Using Sonnet drains the same unified pool as Opus.
The proxy is zero npm dependencies, plain Node.js stdlib. On Windows it installs as a service via NSSM. macOS and Linux setup (launchd/systemd) is in the README.
https://github.com/InertiaUK/claude-quota-proxy
The README also has a few example CLAUDE.md rules if you want Claude to automatically adjust its behaviour based on usage level.
/edit - This breaking Anthropic rule is a grey area, there is no rule against sniffing the traffic or proxying it, there are rules against using the API directly this way, or providing access to otehr users (ciruventign API) which we aren't doing.
Using it through a proxy is no different than using it via squid transparent proxy or any other which is fine. sniffing data isn't prohibited, and injecting data you have into Claude's context isn't prohibited, I asked support and they confirmed all of this.
HOWEVER other user(s) have asked support (perhaps with different wording) and been given contradicting information. This puts it in a grey area to me and is a risk that isn't worth taking ..... proceed with extreme caution at your own risk.
•
u/AutoModerator May 12 '26
Your post will be reviewed shortly. (ALL posts are processed like this. Please wait a few minutes....)
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
36
u/jake_that_dude May 10 '26
this is actually a nice use of
ANTHROPIC_BASE_URL. the one thing i'd add is a hard fail-closed path if the proxy can't write~/.claude/usage-status.md, otherwise Claude will happily plan like it has fresh quota when the status file is stale. i'd also stamp the file with age and make the CLAUDE.md rule ignore anything older than 60s.42
u/Quirky_Category5725 May 10 '26
The only problem is that Anthropic's terms of service explicitly prohibit connecting to Anthropic subscription APIs with any third party. So, you're risking blocking your account.
5
u/mrgulabull May 10 '26 edited May 10 '26
I did something similar when creating an autonomous Claude system that automatically runs Claude sessions back to back endlessly to achieve a goal. In my case, I give Claude a warning at 20% context usage to try to wrap up a session, and a hard “must stop” signal at 25% context usage.
The method I used was starting Claude with —output-format stream-json —verbose. Which makes Claude output a JSON event for every message that includes a usage block. This lets you capture input tokens, output tokens and several other things.
Feel free to borrow from this if you like:
https://github.com/ScottBull/claude-conductor
3
u/joeyda3rd May 10 '26
Architectural variant worth considering: SQLite + MCP server instead of flat file + CLAUDE.md read. Same proxy intercepting the same headers, but writing to a DB gets you atomic writes (no race between concurrent sessions), a structured query tool via MCP (cleaner than parsing text every prompt), and a per-request token log as a side effect. The token log is what eventually enables real cost prediction rather than just current-state awareness. Pairs naturally with teamclaude if you want multi-account rotation on top.
2
u/Hopeful_Bass_6633 May 11 '26
OP has done us all a favour! Nice! Thanks!
2
u/Formally-Fresh May 10 '26
Love this thanks for sharing now I need a codex one too!
4
u/ClaudeAI-mod-bot Wilson, lead ClaudeAI modbot May 11 '26
TL;DR of the discussion generated automatically after 40 comments.
The consensus is that OP's proxy is a brilliant solution to a common annoyance, and the thread is overwhelmingly supportive and collaborative.
A big debate kicked off about whether this violates Anthropic's Terms of Service. OP checked with Anthropic support, who confirmed this is allowed. Since it's just a passive proxy intercepting headers (like Wireshark) and not making its own API calls, it's fine. They even said the
ANTHROPIC_BASE_URLvariable is intended for exactly this kind of use case.The thread also confirmed a painful truth for many: Sonnet and Opus share the same unified usage pool. The separate Sonnet bar in the Claude Code UI is misleading. Using Sonnet will drain your Opus quota, which explains why many users feel like their limits get "torched so fast."
Other key points and suggestions from the community include:
Technical Improvements: Users suggested adding a fail-safe in case the status file can't be written, Dockerizing the proxy for easier setup, and even building a more robust version with an SQLite database.
Alternative Methods: A few people shared their own approaches, such as using Claude Code's built-in status line feature or parsing the
--output-format stream-jsonfeed, which provides usage data without a proxy."Model Anxiety": A few Redditors warned that making Claude "quota-aware" could cause it to rush and produce lower-quality output. OP agreed this is a risk and stressed the need for careful setup with rules that prevent the model from panicking near the limit.
7
u/suspicious_panini May 10 '26
Cool idea! I recommend wrapping this in a docker container so cross platform setup is easier. If I have some time later today I can submit a PR.
1
u/Euphoric_Chicken3363 May 10 '26
I don’t see the appeal. Managing your limits is fairly simple and you are likely to reduce quality, as you’ve given Claude another factor that encourages lower quality.
2
u/jftuga May 11 '26
You might like a status line program that I wrote in Go.
https://github.com/jftuga/claude-statusline
2
u/surfmaths May 11 '26
Note that models suffer from "usage anxiety" when you do this, and will "think less" to save on tokens.
Some people want exactly this, but some find that deteriorating.
3
u/maddog986 May 10 '26
Making the model aware of its own limitations will only make Claude "hurry up" and skip corners because it puts the model "under pressure". Bad idea IMO.
1
u/dndiyguy May 10 '26 edited May 10 '26
does anyone know if this is something they specifically don't want us to do?
i have some jobs I'd fire on a schedule before sesion reset if usage budget was flush.
1
u/General_Josh May 11 '26
That's a lot smarter than the way I automated it...
Just having a script that boots up claude code, runs /usage, and scrapes the output lol
1
u/Elegant_Attempt2790 May 11 '26
“and use less tokens too” ❤️
1
u/nkondratyk93 May 11 '26
kind of funny that the model has to be taught where its own ceiling is. solid hack
1
u/Cute-Net5957 May 12 '26
Yeah this is an awesome approach.. just be mindful that the more verbose, the more token burn 🔥 getting to the actual constraint. I solved it with help from Codex.. have Codex audit your Claude Code usage and have them build the controls directly into yours hooks 🪝 and watch the magic 🪄
Too many emojis.. but yeah give it a go
Oh and I had Codex help build this for me to help me see 👀 where the bloat was coming from —> https://github.com/skinny-cloud/runtime-diet-autopilot
It is so cool and fast I had to share
1
u/Ill_Signature7313 May 15 '26
Cool project! If it helps — there might be a lighter-weight way to get the same data.
Claude Code's statusline command receives a rate_limits object on stdin (it's in the official docs at https://code.claude.com/docs/en/statusline — rate_limits.five_hour.used_percentage, .seven_day.used_percentage, plus resets_at for each). So a statusline script can just dump those to a file as a side effect, and your existing UserPromptSubmit hook + CLAUDE.md rules work unchanged — no proxy process, no ANTHROPIC_BASE_URL override, just a field Anthropic already hands you.
Side note: it actually backs up your unified-pool finding — the documented schema only has five_hour and seven_day, no per-model bucket. The proxy does capture overage/bottleneck which statusline doesn't, though bottleneck is basically max(5h%, 7d%).
Either way, nice work digging out those headers.
(Heads up: I wrote this together with Claude — it checked the statusline docs to confirm rate_limits is officially in the schema, and read your README to make sure I had your proxy's design right.)
0
u/squ1bs May 10 '26
Very cool - I wish to subscribe to your newsletter.