Cursor is behaving entirely as expected considering the responses it gets from the API. Unfortunately, there’s not much we can do about that and it’s not something we’re actively working on.
I don’t think that’s true. I’m on Tier 3, nowhere near my usage limit. And since I can’t use my own Gemini API with cursor, I’m forced to open gemini-cli in terminal. And funny enough, I never get 429, because of elevated rate limits. So it’s a shame team isn’t actively trying to solve this issue, as clearly it’s on the cursor side, as pretty much everyone on this topic demonstrated.
Thank you for looking into it. I have been testing since this post as well. I have been using Gemini API for other applications. The gemini 3 models are very unstable over the API. Now using the gemini 2.5 models which are much more stable. Quite annoying but unfortunately reality. Probably capacity problem.
I’ve used Zed, OpenClaw and notebook services with the same API key and those don’t seem to run into issues with API keys limits. Every other Agent I’m starting I’m hitting this API key limit. Asking the agent to continue resumes the work until getting interrupted again by the same error.
Here to chime in and support the thread since I have the same problem
Edit: I closed and opened Cursor to see if that fixes the issue and now I see a request ID: 020f4d93-e786-4ed6-816e-efb4329f83b4