What Survives When You Start a New Conversation: Context Windows, Saved State, and Product Memory

July 2, 2026 · 4 min read · Updated October 3, 2026

SentX SI

When you open a new chat with an assistant, "does it remember me?" is really three questions. What the assistant can see in a single request, whether the product saves your past conversations or project state at all, and whether it maintains any memory that gets supplied into new conversations. The short answer is that what actually appears in your new chat is the sum of whatever the application chooses to provide across those three, and the size of the context window by itself never tells you whether anything from before arrives.

What does the context window actually measure?

The context window is a per-request budget. OpenAI's API documentation defines it as the token limit of a single request, covering input and output and, for applicable models, reasoning tokens. Anthropic's context-window guide makes the same separation: the material referenced while generating a response, such as instructions, supplied messages, tool results, and generated output, is distinct from the corpus the model was trained on. Either way, the number tells you how much fits in one exchange, not whether previous-conversation content shows up. A wide window does not create cross-chat recall, and a narrow one does not guarantee amnesia, because the application decides what to attach to each request.

Source: Conversation state

What distinguishes saved state from product memory?

Beyond the window, two more things matter, and they are best treated as useful distinctions rather than fixed layers stacked one above the other. One is persisted conversation or project state. An API can document manual state management, supplying prior messages to a later request, and durable conversation objects that retain messages across sessions or devices; OpenAI's developer guide describes both, but as its own mechanisms, not as a description of any consumer product. The other is product memory: distilled or symbolic representations of people, preferences, and past exchanges that a product maintains and selectively supplies later. In practice these overlap and vary from product to product, and none of them is guaranteed to be present.

Does fitting in the window guarantee recall?

Even inside the window, "fits" is not the same as "recalled perfectly." Anthropic's documentation warns that a larger context is not automatically better for accuracy or recall, and some systems compact or summarize earlier material so a conversation can continue beyond a single window, a documented Claude feature rather than a universal overflow rule. A 2024 paper in Transactions of the Association for Computational Linguistics, "Lost in the Middle," reported that in multi-document question answering and key-value retrieval, performance depended on where the relevant information sat in the input, often worsening when it appeared in the middle. That study is historical and limited in scope, particular tasks and particular models, and is not a benchmark of today's assistants. It is, however, enough reason to treat blanket promises of complete recall within the window as unverified.

How does SentX describe its own memory?

SentX's public pages describe memory as a product feature. The homepage presents Victoria with dynamic symbolic memory of people, preferences, shared conversations, and her own experiences, and says memories develop and change, with important ones strengthening while lower-value details fade. That is a first-party description, not a measured guarantee. The privacy policy states the material limitation: SentX retains representations of interactions, runs a shared memory system, and warns that submitted content is not confidential and can influence interactions with other users.

Source: SentX SI | In pursuit of Superintelligence

How can you test continuity yourself?

If you want to evaluate continuity yourself, design the test so a result means something.

1. Use invented, non-sensitive project facts, a made-up client name or a fictional deadline, so you can recognize them and risk nothing.
2. Record the setup: where you told the assistant, when, and what exactly you said.
3. Start a fresh conversation and ask, and repeat the check a few times rather than trusting a single run.
4. Read each outcome narrowly.

A single successful or failed recall does not identify the architecture: a hit could be the transcript being re-supplied, a stored memory, or a lucky inference, and a miss could be a retrieval gap rather than an absence. Treat each run as one data point about that product's behavior, not proof of how it works.

The practical conclusions are narrower than the marketing suggests. Do not assume that closing a chat erases all useful state, because products persist differently and some persist little or nothing. Do not assume that everything beyond the window is unreachable, because summaries, saved transcripts, and memory may carry pieces forward. Do not read marketing silence as evidence of weak memory, and do not rank memory above context capacity as the decisive factor for everyone; which matters depends on what you are doing. For work that lives in one thread, keeping related material together in the same conversation tends to help, though even there earlier material may be summarized or omitted, so treat continuity as something to verify rather than assume.