Vibecoding
Build for the vibe, debug later
Start new thread

AI coding assistants are amazing… until you hit the usage limit😡 what do u do?

by•
One thing nobody really prepares you for when building with AI is how much your workflow depends on usage limits. You’re deep into a problem. You’ve finally figured out what’s wrong. Your AI assistant understands the context, you’re making progress, and then… You’ve reached your usage limit. Come back later. 🙃 And of course, it never happens when you’re casually asking a question. It happens when you’re debugging something that has already taken hours. I’ve been building my platform using Claude Code and Codex, and I’ve learned that managing usage limits is practically another part of the development process. Sometimes I switch between tools. Sometimes I have to stop completely. And sometimes I spend more time planning around the limits than actually fixing the problem. I understand why limits exist. AI models aren’t free to run. But when you’re using these tools to build a real product, the interruptions can seriously affect your momentum. I’m genuinely curious: How do you deal with AI coding assistant usage limits? Do you switch between models, pay for higher plans, plan your sessions around resets, or just accept that your AI developer has decided to take a coffee break? 😂
19 views

Add a comment

Replies

Best

Before cutting anything, it helped me to measure where the tokens actually go. On one Claude Code session in our repo, about 74% of input was the tools array, the tool definitions sent with every request, not the conversation. If you have a lot of MCP servers connected, running /context in Claude Code shows how much they take. Someone in another thread also pointed me to ENABLE_TOOL_SEARCH=auto, which loads MCP tools only when needed.

Reverting an agent's fix after blowing through limits chasing green tests showed the test still passed. It had never actually checked for that bug. Manually break the test first before letting an assistant spend tokens on a fix.

I try to be very intentional about which models I use. I mostly use Claude Cowork/Code. For simpler tasks, I use the older models and only switch to newer models when I want the absolute best version tackling a problem, or if I was unhappy with the version I got.

The limit hurts most when the progress only exists inside the conversation. What made it bearable for me is that my sessions write things down as they go: every finished piece gets committed and pushed right away, and anything the agent figured out that wasn't obvious goes into the project notes at that moment, not at the end. So when a limit or a crash cuts a session off, the next one, even with a different tool, starts from the repo and the notes instead of from zero. The part that's lost is maybe the last ten minutes, not the last three hours. Mertcan's point about measuring first is good too, a lot of the budget can go to things you're not even using.

the limit hitting mid debug is the worst part. agree with george on writing stuff down. when a different tool picks up from your notes, does it actually reach the same conclusion or do you end up re-checking its first few steps?

I'm on several Claude Code Max plans ($200 each), and they come with weekly token limits. I felt like I was losing money if I didn't use them up every week, so I built my own app that tracks token usage. It works with Claude Code, Codex, Antigravity and Grok, and I'm really happy with it.