跪拜 Guibai
← All articles
Frontend · Architecture · Frontend Framework

When AI Forgets Mid-Chat: Three Token-Management Strategies That Keep Context Alive

By 禅思院 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Context-window overflow is a silent failure mode: the API doesn't warn until the request is rejected, and by then the user has already lost trust. Choosing the right compression strategy determines whether an AI feature can sustain long, multi-turn workflows or collapses into a short-term toy.

Summary

A chat session that runs 50 rounds deep eventually exceeds the model's token limit, causing the API to reject the request and the AI to lose track of facts stated minutes earlier. The root cause is the Transformer attention mechanism's O(n²) complexity, which enforces a hard ceiling on context length. Frontend code that naively sends the full history simply breaks at scale.

Three mitigation strategies sit on a cost-versus-retention curve. A sliding window keeps only the last N rounds and costs nothing, but it permanently discards earlier context, making follow-up questions about the past impossible. Summary compression periodically calls a cheaper model to condense older history into a short paragraph, preserving key entities and conclusions at roughly 15% extra LLM cost per compression cycle. Structured memory goes further by extracting typed facts into a vector database or relational store, then injecting them alongside a summary and the most recent turns.

A production-ready implementation triggers compression when token usage passes 70% of the window or when round count exceeds a threshold, and it always surfaces a UI indicator so users know the conversation has been truncated. The next installment in the series will tackle persistence and reconnection so that a page refresh or spotty network doesn't wipe out the session.

Takeaways
Transformer attention scales quadratically, so every model has a fixed token ceiling; exceeding it returns a 400 context_length_exceeded error.
A sliding window is free but permanently deletes early context, breaking any question that references the past.
Summary compression uses a cheaper model to distill old history into a 200-word paragraph, keeping key entities and conclusions.
Each compression cycle adds roughly 15% extra LLM cost but saves far more tokens than sending the full history.
Structured memory extracts typed facts (preferences, tasks, entities) into a database and injects them into the system prompt alongside a summary.
Trigger compression when estimated tokens exceed 70% of the context window or when rounds pass a set threshold; don't compress every turn.
Always show a UI indicator when context has been truncated, or users will blame the AI for getting dumber.
Conclusions

Context-window management is fundamentally a frontend problem once the conversation state lives in the client; the API won't solve it for you.

The three strategies map cleanly to product tiers: sliding window for demos, summary compression for most SaaS, structured memory for assistants that need persistent user profiles.

Transparency in the UI isn't optional — without a visible truncation notice, users attribute memory loss to model quality rather than a design trade-off they could understand.

Concepts & terms
Context Window
The maximum number of tokens a large language model can process in a single request. Determined by the Transformer architecture's O(n²) attention complexity, it creates a hard limit on how much conversation history can be included.
Summary Compression
A strategy that calls a smaller, cheaper LLM to condense older conversation turns into a short paragraph, preserving key facts while drastically reducing token usage for subsequent requests.
Structured Memory
Extracting typed entities (user preferences, facts, tasks) from conversation and storing them in a database or vector store, then injecting them into the system prompt so the model retains long-term knowledge without carrying full history.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗