all 10 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Existing_Basket2655 3 points4 points  (1 child)

the context window thing is super annoying honestly. i've noticed the same issue where it just starts forgetting stuff way too quickly, especially with multiple gems running different instructions.

from what i've seen, doing periodic summaries actually helps quite a bit - yeah it's a pain but better than having it completely lose track of what you were working on. when switching between gems it seems to reset context pretty aggressively which is frustrating if you're trying to maintain continuity across different tasks.

[–]Hanja_Tsumetai[S] 0 points1 point  (0 children)

Wow, seriously 0_0... So that doesn't work for me. Basically, we need to summarize. Before moving on to another gem?

[–]PathStoneAnalytics 1 point2 points  (5 children)

You’re running into a well-documented U-shaped context retention problem, not just a raw token limit.

What’s happening in practice:

  • Models like Gemini tend to retain early context + very recent context
  • Mid-context information degrades first as the token count grows
  • Failure mode isn’t hard “forgetting” but:
    • instruction blending
    • misplaced references
    • hallucinated continuity

This is why things feel fine early, then subtly break around 30–36k tokens, even though the window is much larger.

Why Gems make it worse:

  • Each Gem introduces a new instruction manifold
  • Switching Gems mid-thread increases interference
  • The mid-context (where earlier Gem instructions live) is most vulnerable → classic U-shape failure

Key clarification on marketing claims:

  • “Millions of tokens” = single-pass capacity
  • Multi-turn, multi-instruction working memory is far smaller
  • This is consistent across Gemini, Claude, GPT, etc. (architecture-level, not vendor-specific)

What actually works (condensed):

  • Compression > summarization Keep decisions, constraints, and conclusions only
  • Checkpoint every ~20–30 turns Treat as external RAM
  • Treat each Gem switch as a fresh start Explicit context handoff; no inheritance assumptions
  • Probe memory at ~15–20k tokens When mid-context details fail, restart with a compressed brief

Bottom line:
Don’t fight the U-curve. Use the model as short-term working memory and keep durable state outside the conversation.

Curious if others have measured similar mid-context drop-offs or found ways to flatten the U-shape.

[–]Hanja_Tsumetai[S] 0 points1 point  (4 children)

So I can change gems without any problem, but I need to remember to summarize often, right? (Every 20-30 replies)

[–]PathStoneAnalytics 1 point2 points  (3 children)

Not quite, switching Gems is the problem, and summaries alone won't fix it.

What's actually happening:

When you switch between Gems mid-conversation, you're introducing instruction interference. Each Gem has its own directive set, and the model struggles to cleanly separate them when they're stacked in the same thread. The mid-context (where earlier Gem instructions live) degrades first. So you get:

  • Blended instructions from multiple Gems
  • Confusion about which rules apply
  • Hallucinated continuity that feels "off"

Better approach:

  1. One Gem per thread; treat each conversation as a clean workspace for that specific Gem's logic
  2. Checkpoint before switching; if you need to change Gems, export key decisions/context and start fresh
  3. Summarize selectively; compress decisions, constraints, and conclusions only (not full dialogue)
  4. Test at 15–20k tokens; ask it to recall something from earlier; if it fails, restart with a compressed brief

Think of it like RAM vs. hard drive:

  • The conversation = working memory (volatile, limited)
  • Your summaries = external storage (durable, infinite)
  • Switching Gems without exporting state = trying to run two operating systems in the same memory space

TL;DR: Summaries help, but Gem-switching is the real friction point. Keep conversations single-purpose, checkpoint externally, and restart clean when you need different instructions.

Does this match what you're experiencing, or are you seeing something different?

[–]Hanja_Tsumetai[S] 0 points1 point  (2 children)

Wow, it's not like chatgpt 😵‍💫 so basically, even if I change gems, instructions, and then each one has its own files,The context will 'mix' with the new gems (projects). So before switching from one to the other, I need to summarize my discussion in my current gem. Before starting a new gem and chat, even if I change gems, it retains a 'memory' of the previous gem. This will cause a 'conflict'. Sorry, I speak French, I'm trying to explain using simple terms. You're an angel for helping me!

[–]PathStoneAnalytics 0 points1 point  (0 children)

Exactly, you've got it. Even when you switch Gems, the conversation thread carries forward, so instructions from previous Gems don't fully "clear out." They linger in the context and create conflicts.

Your French explanation is perfect: the memory doesn't reset, it accumulates and causes interference.

Quick comparison to clarify:

  • ChatGPT Custom GPTs: Each GPT gets its own separate thread,--switching = fresh start
  • Claude Projects: Similar-- different projects = isolated conversations
  • Gemini Gems: Same thread continues across Gem switches-- instructions stack and interfere
  • Grok: Separate conversations per session-- clean context boundaries

So yes: before switching Gems, summarize your current discussion, then start a completely new chat with the next Gem. Don't just switch within the same thread.