When a coding assistant worked yesterday and refuses today, do not start by assuming the model got worse. Check plan limits, usage quotas, the signed-in account, company policy blocks, outages, and retired features in that order, because guessing wastes the afternoon.
Say you spend half a day rewording your prompts to get past a refusal, and the real cause is a usage quota on the wrong Google account. Your personal Pro plan never covered that editor tool in the first place. Your IT team could have answered in one ticket if your note had named the product, the account, and the exact error text.
Nothing kills trust like a tool that worked on Tuesday and refuses on Wednesday. The cause is often not quality at all, and is more likely a plan limit, a quota, a wrong account, a policy block, an outage, or a retired feature. This post is a diagnostic map that helps you stop guessing.
Why did it stop?
Write the stoppage in one sentence before you change any prompts. Name the product you were using (chat, an assistant inside your code editor, or a command-line agent), the account email, the plan or edition you think you are on, and the exact error text. Without those details, every Slack thread turns into folklore.
The diagnostic map
- Confirm which product you opened, because a chat window is not the assistant inside your code editor, and neither is the same as an agent in a terminal.
- Confirm which account is signed in, since personal Google AI plans and Workspace seats from your employer follow different rules.
- Check the usage quota and rate limits (caps on how much you can do per minute or per day) for that product and edition.
- Check policy blocks, which can come from your admin, from data-loss-prevention rules, from your region, or from data controls.
- Check the vendor’s status page and look for features that were retired or renamed.
- Only after all of that, go back to the prompt or the model picker.
Consumer transition reminder
Some consumer coding tools changed names and access rules during 2026, and install notes go out of date quickly. If your wiki still says “Gemini CLI” but the real program or your entitlement (what your plan lets you use) has moved, the refusal may be a mismatch between your edition and the tool, and no prompt will fix that. Re-read the current vendor docs in the week you escalate to IT.
Ticket template for IT
Product surface:
Account email:
Plan / edition (as shown in UI):
Exact error text / screenshot:
Last success date/time:
What changed since then (new laptop, new extension, new admin policy):
Workaround tried:Practice this week
Write your own “which product am I on?” card that lists the product, the account, the plan, and where quotas appear. Keep it next to your install notes, and update it whenever a rename lands.
Common mistakes
- Buying a new personal plan to fix a problem with an enterprise seat, which a personal plan cannot solve.
- Rewording prompts to get around a hard quota or policy refusal.
- Filing IT tickets without the account and the exact error text.
- Assuming that yesterday’s install guide still matches what your plan allows today.
What good looks like
In the example at the top, half a day went into rewording a refusal, and the fix turned out to be switching to the Workspace account that actually included the editor tool. The ticket template above would have cut that to about fifteen minutes, because it forces you to write down the account before anyone starts guessing.
Quick recap
- Sort the stoppage into a category before you blame the model.
- Work through the causes in order: product, account, edition, quota, policy, outage, then retired features.
- The next post covers when a full editor agent is more than you need.
Series notes
This post is Part 4 of the Gemini coding surfaces tutorial (GM25). The previous post covered the ask, edit, test, review loop, and the next one covers when a full agent is overkill.
Sources
Keep going
Same lessons in your feed
Short diagrams, hooks, and weekly tutorials on Substack, Instagram, X, and Facebook.
