You spent 15 minutes crafting a custom Gem — instructions, knowledge files, sample prompts — hit Save, and it’s either gone, greyed out, or loads with empty fields. Worse, the Gem manager on gemini.google.com shows it exists but won’t open. This is almost never “data lost on Google’s side.” It’s one of four predictable failures: account tier (Gems requires Gemini Advanced / AI Pro / Workspace Business), browser session corruption, a slow Workspace sync, or a stale Gem record that needs to be recreated.
The fix takes under five minutes once you know which cause applies.
Common causes
By frequency in the field:
1. Account doesn’t have Gems access (most common)
Gems is gated. Free-tier Gemini accounts can see the Gem manager UI in some regions but cannot save new Gems — clicking Save silently fails or reverts. You need one of:
- Google AI Pro (consumer paid tier)
- Google AI Ultra
- Gemini for Google Workspace Business / Enterprise / Education
- A grandfathered Gemini Advanced subscription
How to judge: open gemini.google.com/gems — if you see “Upgrade to access” or the Save button is greyed, you’re not eligible. Also check one.google.com for your active subscription.
2. Browser cache holding a stale session
If you upgraded your plan in the last 24 hours but Gemini still thinks you’re on free, the Save call hits the wrong endpoint and the Gem never persists. Same thing happens after a Workspace admin grants you Gemini access — your client session lags the entitlement.
How to judge: incognito window loads Gems correctly while your main browser doesn’t.
3. Workspace sync delay (admin just enabled Gems)
For Workspace accounts, when an admin flips on Gems in Admin Console, propagation can take 24-72 hours. During that window the Gem manager loads but writes don’t stick.
How to judge: personal Google account can save Gems, work account can’t, and your admin says “I turned it on today.”
4. Knowledge-file attachment failed silently
If you uploaded a PDF or doc to the Gem and the upload errored out (size limit, unsupported type, network drop), the entire Gem save sometimes rolls back without a visible error.
How to judge: removing all knowledge files lets the Gem save fine.
5. Browser extension interfering
Privacy extensions (uBlock with aggressive filters, Privacy Badger, Ghostery) sometimes block Gemini’s save endpoint. Same for some VPN browser extensions that strip cookies.
Shortest path to fix
Step 1: Confirm you have Gems access
Visit one.google.com and check your plan. If it doesn’t say AI Pro, AI Ultra, or you don’t have a Workspace Gemini license, that’s the answer — Gems requires a paid tier. Free Gemini cannot save Gems.
If you do have a paid plan, continue.
Step 2: Hard refresh and sign out / in
Cmd/Ctrl + Shift + R on gemini.google.com
If that fails:
Profile icon → Sign out
Close browser fully
Reopen, sign in, retry SaveThis forces a fresh session token that picks up your current entitlement.
Step 3: Try an incognito window
Open an incognito / private window, sign in, and recreate the Gem. If it saves there, your normal profile has a stale cache or extension issue:
- Clear cache for
gemini.google.comonly (Settings → Privacy → Cookies and site data → Search “gemini”) - Disable extensions one by one — start with ad blockers and privacy tools
Step 4: Recreate the Gem from scratch
If a specific Gem keeps failing to load, the record may be corrupted server-side:
- Note down its instructions and knowledge files
- Delete the broken Gem from the Gem manager
- Create a new Gem with the same content
- Add knowledge files one at a time, saving between each
Adding files incrementally surfaces which file (if any) is breaking the save.
Step 5: For Workspace — confirm admin enabled it
Have your admin verify in Admin Console → Apps → Google Workspace → Gemini → Service status that Gems is on for your OU. After they confirm, wait 24 hours before testing again. Workspace propagation is not instant.
Step 6: Try a different browser entirely
If incognito in Chrome also fails, try a different engine (Chrome → Firefox, Edge → Safari). A surprising number of save-failure reports turn out to be a single browser’s storage layer hitting a quota or a corrupted cookie. Firefox especially tends to surface errors Chrome silently swallows.
Step 7: Re-verify after Workspace admin changes
If admin just made any change to Gemini access — adding a license, enabling extensions, changing OUs — wait at least an hour, then sign out / in fully (not just close the tab). A “fast” admin change is often slow on the client side because of cached entitlement tokens.
Step 8: File a ticket if all else fails
If you have AI Pro, no extensions interfere, incognito also fails, a second browser fails, and recreate doesn’t work, this is a real bug. Report at support.google.com/gemini with: account email, Gem name, browser version, screenshot of the Save attempt, and the network-tab response from the Save request (DevTools → Network → click the failing request → Response tab).
Prevention
- Treat the first save with just instructions as a “smoke test” — if it doesn’t save with only instructions, no point adding knowledge files
- Save the Gem with just instructions first, then add knowledge files one at a time — this isolates which file (if any) breaks the save
- Keep the Gem instructions in a separate doc (Drive, Notion) as a backup so a lost Gem isn’t a lost workflow
- Use the same browser profile you’ve authenticated Gemini in; avoid switching between work and personal Google accounts mid-edit
- After upgrading plans, always sign out and back in before creating a Gem — never trust the cached session
- For Workspace: ask your admin to confirm Gems is on for your OU before you invest time building Gems
- If you maintain many Gems, version them in a Doc with date stamps — when a Gem mysteriously changes behavior after a Google update, you have a record of what it used to say
- Avoid editing the same Gem from two browsers at once — last-write-wins behavior can wipe a careful edit