API Rate Limit Handling Breaks Workflow and Causes Potential Data Corruption
Bug Description
The newly imposed API Limits are ruining claude code. I've hit them in as little as a half hour after I wake up in the morning, and I didn't use anywhere near enough prompts to account for that. I was already struggling to keep the product useful for my large project because of context limits - you start off with Opus by default, and first thing it does is automatically read docs. There are a lot of docs, so this is slow and wasteful of both usage limits and context memory.
Worse yet, when you enforce your API limits, you do so completely unintelligently. I had one time where the limit got enforced abruptly in the middle of some database schema updates, leaving my DB in a broken state. And I didn't have the remainder of the update to see because Claude hadn't generated it yet. When Claude came back it couldn't remember what the next steps were. This is unacceptable. If I had real data in that db you'd be facing a lawsuit for damages caused and/or negligence. Fortunately this was my development system and I could recreate it.
Not to mention that its EXTREMELY BAD FORM to make policy changes without notice, and without even updating your documentation. Did you learn nothing from the bad PR Windsurf and Cursor have been getting?
Environment Info
- Platform: darwin
- Terminal: ghostty
- Version: 1.0.53
- Feedback ID: 194d6824-0256-48c0-b155-a3cad38fc992
This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗