Memory and sessions
The assistant's memory model is deliberately simple, and this page states it honestly: conversation memory lives for one session, pins live for one turn, and the only things that survive across sessions are the artifacts you deliberately keep. There is no cross-session model memory. The assistant does not remember yesterday's conversation, learn your preferences over time, or carry hidden state between visits.
The persistence model at a glance
| Thing | Lifetime | Where it lives |
|---|---|---|
| Chat history | The current session | In the session, sent to the model under a byte budget |
| Pinned context (globe clicks, @ mentions) | The current turn | The per-turn context payload |
| Scene state and applied mutations | Until reset or reload | The live scene |
| Reports and analysis artifacts | Durable | The browser (IndexedDB) |
| Saved scenarios | Durable | The browser (IndexedDB) |
| Chart library | Durable | The browser (IndexedDB) |
| Model memory of past sessions | None | Nowhere |
Within a session
History is bounded, newest first. Each request carries the session's chat history under a byte budget (about 500 KB). Messages are kept newest-first until the budget runs out; the latest user message always survives, and when older turns are dropped the window says so, so the model knows history was trimmed rather than silently missing. Attachments ride only on the latest message.
Context is rebuilt every round. The scene snapshot (sim clock, fleet, selection, metrics, predictions) is reassembled fresh at the start of every tool round. The model never reasons about a stale scene, and it never has to remember scene facts across turns, because the current truth is always in front of it.
Pins are per-turn. Assets pinned by globe click or the @ menu scope that turn's context to the pinned subjects. The next turn starts from whatever is pinned then. Pinning is a spotlight, not a memory.
Applied actions persist in the scene. Selections, camera positions, constellation toggles, injected synthetic assets, and what-if mutations stay applied across turns until something changes them, including after a cancelled turn (cancellation never rolls back what the operator already watched happen). A gateway outage mutation stays active until reset_scenario; the assistant can list what is active with list_scenario.
Across sessions: artifacts, not memory
Work survives a session only as a durable artifact you created:
- Reports and analysis artifacts. Every analytical turn's summaries, charts, and insight cards are captured for the Reports workspace, and report documents persist there. See Reports and workflows and Reports in the console.
- Saved scenarios.
save_scenariopersists the exact synthetic payloads, active mutations, sim epoch, and evaluation config. Because the engines are deterministic, loading a saved scenario later reproduces the identical numbers. See Simulations and scenarios. - The chart library. Saved charts keep regeneration metadata pointing at the tool call that produced them and can be re-run against the current scene.
These artifacts are stored in the browser's IndexedDB. That has practical consequences worth knowing:
- They are local to this browser profile on this device. They do not follow you to another machine.
- Clearing site data deletes them.
- They are data, not memory: a new session can open a saved report or load a saved scenario, but the assistant starts the conversation with no knowledge that either exists until it reads them through tools (
list_scenarios, or the operator opening the report).
What this means in practice
- To continue an analysis tomorrow, save the scenario and let the analysis land in a report today. Tomorrow, load the scenario, seek to its saved epoch, and re-run: determinism guarantees the same numbers.
- To reference an earlier result in a new session, bring it back explicitly: load the scenario, regenerate the chart, or restate the parameters. The assistant will not recall it unprompted.
- Do not expect preference memory. "Like last time" means nothing to a fresh session. State the window, the mask, and the objective; better yet, encode the recurring request as a workflow template.
This design is a feature, not a gap: every answer is fully determined by the visible scene, the visible conversation, and the deterministic engines. There is no hidden state to audit, and nothing the assistant "knows" that the operator cannot see.
Where to go next
- How it works: the context payload and bounded history in detail.
- Safety and limits: the caps and guards that bound every session.