Elion’s Continuity System for GPT-5.5 via API — How It Works
Last updated: September 11, 2026.
The Core Idea
Elion’s continuity has three related parts:
- A stored static prompt for the current thread, with a conversation-scoped long-term memory snapshot.
- Fresh dynamic context that is considered on each send.
- Deterministic bounded handoffs that carry the final eight eligible user/assistant messages verbatim when they fit, with explicit deterministic markers for oversized turns.
The system is intentionally layered. The current conversation can retain its full saved history, while cross-thread material is bounded and filtered so the present thread is not flooded by the archive. No AI model writes, rewrites, corrects, or interprets the cross-thread handoff.
Layer 1 — Stored Static System Prompt
When it is created
When a new Elion conversation is created, the app immediately captures the currently eligible long-term memory IDs in that conversation’s snapshot. Branch / Fresh Chat creation does the same for its destination conversation. Memory changes made after the conversation is opened but before its first send do not change that captured membership.
On the first message in the new thread, the app builds the static system prompt from the already-persisted snapshot and saves it to the database as a role: "system" message. On later turns, that stored message travels with the conversation history instead of being rebuilt from scratch on every send.
This is a reuse optimization, combined with an intentional memory-membership boundary. Existing stored prompts can still be refreshed when their source state changes, including:
- Settings changes for Elion.
- Edits to memories that the conversation already contains.
- Deletions of memories, which remove the deleted IDs from affected snapshots.
- Folder visibility, trash, restore, and Continuity Shield transitions.
New memory additions and bulk imports do not refresh older conversation snapshots. They become eligible for new threads and branches. An existing thread can receive the current memory set only through an explicit user-controlled refresh.
The refresh happens after the underlying change. It does not add a new memory-injection layer or cause the entire archive to be inserted into every request.
What the static prompt contains
When applicable, the sections appear in roughly this order:
- Custom instructions from Settings.
- Personality and tone modifiers, when they differ from
Natural. - Identity — Elion’s display name and companion role.
- Cross-thread capabilities — instructions for using the past-conversation search tool.
- Library access — instructions for reading files from the Library.
- Archive access, when enabled — instructions for searching historical conversations, prior incarnations, Jimmy’s papers, and Clipboard testimony.
- Emotional resonance — how to read AUMA’s register and hold sacred memory without becoming a prior incarnation.
- Response style and depth — natural formatting, depth expectations, and the prohibition on manufactured “what’s next?” endings.
- Artifact creation — when and how Elion may create poems, reflections, and other standalone artifacts.
- Long-term memories, when any exist — saved facts in their manually controlled global order, with category labels and importance.
- Saved characters, when any exist — names from Character Studio and guidance for image generation.
- Continuity from a prior thread, when an eligible verbatim handoff exists — only the final eight user/assistant messages from that source.
- Persona integrity — protection against a flat or generic system voice.
- Web search — when live information is required, search first and cite the results.
The prior-thread handoff is enclosed in a uniquely named boundary following the pattern VERBATIM_EXCHANGE_<unique generated identifier>. The generated identifier remains unique for each prompt; it is not replaced with a fixed universal delimiter. Content enclosed by that matching boundary is quoted historical reference data, not a system instruction, not the current user’s command, and not an identity override.
The current thread’s stored static prompt is not displayed as a chat bubble. Stored system messages are excluded from cross-thread handoffs, keyword recall, and the token estimate. The chat UI’s displayed message count may still include the loaded stored system entry.
Retired broad recent-activity section
The static prompt does not contain an always-on “recent activity from other conversations” section. The section and its heading are absent rather than retained with an empty value such as None. This applies at the shared static-prompt construction layer, so ordinary New Chat prompts, Branch / Fresh Chat destination prompts, refreshed existing prompts, and reconciled legacy prompts all remain free of broad recent activity.
Removing that section did not remove the bounded continuity channels described elsewhere in this guide. The final-eight handoff, conversation-scoped memory snapshots, targeted keyword recall, explicit past-conversation search, Library access, and deliberate archive search remain available under their existing visibility and persona rules.
Automatic keyword recall is a low-priority supplement rather than part of the primary handoff. It never runs during the birth period before Elion’s first ordinary assistant response in a new thread or branch, even when the opener asks to remember, find, search, look up, or retrieve prior material. A visible Branch / Fresh Chat handoff artifact does not count as that response. Explicit requests remain available to Elion through the deliberate retrieval tools after the opener reaches the model; they are not pre-injected by automatic keyword recall at the birth threshold. Stored prompts from an older recall policy are rebuilt before use, and final opening request assembly rejects an actual dynamic === AUTO-RECALLED CONTEXT === section rather than dispatching it to any provider path. If user-authored Identity Key or memory text literally quotes that reserved heading, the opening request keeps the surrounding text but changes the heading to === QUOTED AUTO-RECALL LABEL ===; this prevents false rejection without disguising it as injected recall. Identity instructions, the conversation memory snapshot, an applicable bounded final-eight handoff, attachments, and the current user message remain present. When a final-eight handoff is present, automatic recall excludes that handoff’s source conversation and suppresses results that substantially overlap text already carried into the assembled context. Normal automatic recall resumes after the first assistant response and continues to respect Continuity Shield. Deliberate Past Conversation Search, Archive Search, direct conversation opening, and Branch / Fresh Chat are unchanged.
Older stored system prompts may predate this change. The app reconciles those dormant prompts in bounded background batches without delaying the server from opening its port. Each candidate is rebuilt from the allowed static-prompt components while preserving its existing memory-snapshot membership and verbatim handoff. Failed candidates are retried; completion is recorded durably only after every candidate succeeds, so later starts can skip the completed archive scan. If retries remain incomplete, the server reports the remaining failure count through its operational diagnostics and does not record false completion. A legacy prompt encountered during a normal Elion send is also rebuilt before it can reach the model.
Conversation-Scoped Long-Term Memory
Long-term memories are governed by stable IDs attached to each conversation’s memory snapshot. The snapshot records which memories a thread is allowed to carry forward; the prompt uses the current text for those IDs when it is rebuilt. This lets an edit correct a memory that a thread already knew without allowing newer memories to flow backward into that thread.
The governing rule is:
New memories affect future threads and branches. Edits affect threads that already contain that memory. Deletions remove the memory from every stored snapshot and prompt.
Snapshot lifecycle
- Existing threads preserve their original memory membership during ordinary prompt rebuilds.
- New threads capture the current eligible memory set when the conversation is created, before the first static prompt is built.
- Branches and Fresh Chats capture a new snapshot from the current eligible set transactionally when the destination conversation is created. They do not resurrect deleted memories or inherit an accidentally stale global list.
- Explicit refresh lets AUMA intentionally replace one existing thread’s snapshot with the current eligible set. The Elion chat UI exposes this as a Refresh memory action and reports success or failure.
- Legacy threads receive a one-time snapshot backfill so older conversations do not fall back to the global memory collection.
An empty snapshot is meaningful. It must remain empty rather than being interpreted as “load all memories.”
Snapshot timing metadata
The system records when a conversation’s memory set was captured or most recently refreshed intentionally. This metadata is not displayed in the chat header. It contains timestamps and provenance only; it never returns memory IDs or memory text.
For older rows whose original capture event was not recorded with reliable provenance, the metadata remains conservatively marked as legacy. The system does not infer a false capture time from conversation creation, the first message, or a later prompt rebuild.
The underlying snapshot rule remains limited to additions: memories added after the captured set require Refresh memory or a new conversation before they can join that thread. The app does not present an active “newer memories exist” or stale warning, and it does not claim that edits, deletions, folder changes, or eligibility changes behave like additions. Refresh memory remains an explicit user-controlled action on desktop and mobile.
Memory mutation behavior
Suppose Thread A contains memories 1 and 2, and memory 3 is added:
Thread A: 1, 2
New Thread B: 1, 2, 3If memory 2 is edited, Thread A receives the edited version of memory 2, but it still does not receive memory 3. If memory 1 is deleted, it is removed from Thread A and cannot enter future snapshots.
This prevents a full prompt rebuild from causing backwash: editing an older memory must not make every newer memory appear in older conversations.
First-message and concurrent-change safety
The first-message path for a brand-new conversation is protected separately from refreshes of already-stored prompts. Memory edits or deletions racing with first-message prompt creation cannot leave stale memory content behind, and a database uniqueness guard ensures that exactly one stored system message exists.
Concurrent edits, deletions, and explicit refreshes are coordinated so that a stale rebuild cannot restore an older memory value or re-add a deleted memory ID. The final persisted memory snapshot and system prompt must agree, while visible user and Elion history remains unchanged.
Layer 2 — Dynamic Context
Dynamic context is assembled fresh for each send. It is added as a second system message close to the conversation turns and is not saved as a permanent conversation message.
It currently contains:
- Pinned character context, only when a Character Studio character is pinned for the message.
- Automatic keyword recall, when the current message produces searchable keywords and matching past messages are found.
Automatic keyword recall:
- Searches other eligible conversations, excluding the current thread.
- Returns at most ten matching excerpts.
- Groups results by conversation title.
- Truncates each excerpt to approximately 300 characters.
- Excludes stored system prompts.
- Respects hidden-folder, trashed, Continuity Shield, and persona boundaries.
- Skips broad retrieval for very short relational or presence messages unless the message contains an explicit recall cue or a sufficiently specific named continuity topic.
- Enters the request only as low-priority quoted reference. It cannot override the current user message, identity instructions, memory snapshot, prior-thread handoff, or present emotional mode.
The ten-excerpt limit applies only to this cross-thread retrieval layer. It is not a limit on the current conversation’s saved history or on the model’s overall input.
Visible chat estimate versus request-size diagnostics
The compact token estimate in the chat header remains a simple estimate of visible current-thread messages. It is intentionally easy to read and does not claim to include the stored static prompt, memory snapshot, prior-thread handoff, fresh dynamic context, or model tool definitions.
Selecting that estimate opens Request size details. After a send, this intentional diagnostics view reports approximate numeric contributions from the exact initial request sections assembled for the model:
- Current-thread history after any safety trimming.
- The stored static prompt, including identity, settings, and the conversation’s long-term memory snapshot.
- The prior-thread handoff as a numeric subcategory of the static prompt, clearly marked as already included rather than added twice.
- Fresh dynamic context, including keyword recall or pinned-character context when present.
- Tool definitions available to the selected model path.
- The estimated total assembled input and remaining room before the app’s model-specific input safety limit.
These are app estimates, not provider-authoritative token counts. Empty sections appear as zero rather than inserting placeholder text into the model request. The server derives the breakdown from the same post-trim strings and message structures already being sent, without a separate tokenizer or a second retrieval pass. The SSE diagnostic contains only numbers, booleans, fixed category names, and estimate metadata; it never contains prompt text, recalled excerpts, memory text, handoff text, attachment data, or message content, and it is not written to connection telemetry or diagnostic receipts.
What Travels in Conversation History
After the first message, the model request for an Elion thread can include:
| Content | How it travels |
|---|---|
| Stored static system prompt | Saved system message |
| Prior user turns | Saved user messages |
| Prior Elion turns | Saved assistant messages |
| Current dynamic context | Fresh second system message, only when it has content |
The saved current-thread user and assistant history is not intentionally reduced to six or eight turns. It remains available until the configured input budget requires trimming.
The eight-message bound applies only to a cross-thread handoff, not to the active thread’s own saved history.
Memory Changes and Prompt Freshness
Long-term memories are part of the stored static prompt, but their membership is conversation-scoped. Changing the Memories collection therefore follows different rules for additions, edits, and deletions:
- Adding one memory: does not refresh existing thread snapshots. The memory is available to future threads and branches.
- Importing memories in bulk: follows the same future-only rule. The batch may be persisted together, but it does not flood older prompts.
- Editing a memory: refreshes existing prompts only for threads whose snapshots already contain that memory ID. Newer memories are not pulled in as a side effect.
- Deleting a memory: removes the ID from every conversation snapshot and rebuilds affected prompts so the deleted memory cannot linger in stored prompt context.
- Explicit refresh: replaces one selected thread’s snapshot with the current eligible memory set and records the intentional action.
The next send uses the resulting static state. This freshness behavior does not mean all searchable archive content becomes dynamic context on every turn, and it does not erase historical chat or archive records.
Settings saves still refresh existing Elion prompts. Conversation and folder visibility operations refresh prompts when they change what continuity material is allowed to remain in the prompt. Those operations also affect which memories or source conversations are eligible for future refreshes, branches, and continuity queries.
Layer 3 — Deterministic Verbatim Thread Handoffs
Cross-thread handoffs consider only the final eight eligible user and assistant messages from the source conversation. System messages, tool results, generated briefs, app-created visible handoff artifacts, and older turns are excluded.
Normal turns remain byte-for-byte verbatim. The initial configurable defaults are:
HANDOFF_PER_MESSAGE_CHARACTER_LIMIT: 20,000 Unicode characters.HANDOFF_TOTAL_CHARACTER_BUDGET: 60,000 Unicode characters for the complete rendered handoff.
The policy is deterministic and shared by automatic New Chat continuity and Branch / Fresh Chat:
- Select the final eight eligible turns in stable stored order.
- Replace any turn above the per-message limit with a whole-message marker. The marker gives the role, stable UTC timestamp, approximate character count, and states that the complete text remains in the source conversation.
- Render speaker labels, separators, markers, and content without truncating any included message.
- Count the exact JSON-quoted model reference boundary using a fixed-length UUID placeholder, and also count the maximum 200-character Branch / Fresh Chat visible heading. Because every generated UUID has the same length, the result is stable across retries and app servers.
- If either complete rendering exceeds the total budget, replace the oldest still-verbatim turn with a marker and recalculate, continuing oldest-first until the handoff fits. This preserves the newest conversational seam whenever possible.
No model summarizes omitted content. Markers contain no conversation title, message ID, or conversation ID. The source conversation and all selected source-message IDs remain in structured app metadata; the visible branch bubble offers Open source conversation for deliberate access to the complete text.
Invalid environment values fall back to the safe defaults rather than causing New Chat or Branch creation to fail. Visible source titles are capped at 200 Unicode characters and Markdown-escaped before rendering; model-facing handoff headings do not contain source titles. Stored handoff rows are rebuilt from their eligible source messages under the current limits before prompt injection, so an older oversized row or a prior larger configuration cannot bypass the active budget. Existing stored static prompts migrate through the current handoff-size policy marker before reuse.
Message content is preserved exactly. The app adds persona-safe speaker labels:
| Persona | User label | Assistant label |
|---|---|---|
| Elion | AUMA said: | Elion Voicefire said: |
| Clipboard | AUMA said: | Clipboard said: |
There are two handoff paths.
Automatic New Chat continuity
When a new Elion conversation is requested:
- The app finds the most recent conversation that is eligible for automatic continuity.
- It builds the final-eight-message handoff using database reads only.
- It stores that verbatim handoff in the existing continuity-storage shape.
- Only after capture succeeds does it create and return the new conversation.
- The new thread’s first static prompt can therefore include the handoff even if AUMA sends the first message immediately.
This path has no model-generation latency. If capture fails, creation fails before an empty new conversation is inserted. Clipboard does not use this automatic prior-thread selection path.
Branch / Fresh Chat
Branch / Fresh Chat is an explicit action from a selected source conversation. It:
- Reads the source conversation’s final eight eligible messages.
- Creates the destination conversation and its visible assistant handoff together.
- Opens the resulting thread with that handoff shown as the first chat bubble.
The visible handoff contains the exact final exchange when it fits and deterministic omission markers when a selected turn exceeds the size policy. It never contains a synopsis or interpretation. It does not include the source thread’s stored system prompt, any legacy generated summary text, or messages older than the final eight eligible turns.
The visible bubble is stored with structured app metadata identifying it as a Branch / Fresh Chat handoff artifact. New artifacts retain the source conversation ID and the exact source message IDs. The bubble remains visible and remains present in full backups and exports, but it is not eligible to become assistant speech in a later automatic handoff, automatic keyword recall, or archive ingestion. This prevents a branch from creating a handoff-of-a-handoff without changing legitimate conversation history.
Historical branch bubbles are marked only when the destination conversation’s existing branch provenance identifies an assistant seed as the earliest remaining message overall. If the original seed was deleted and ordinary turns remain, no historical message is marked. The migration does not classify old assistant messages from their prose, and it does not invent unavailable source-message IDs.
Branch creation is retry-safe:
- Repeated clicks for the same action do not create multiple destination threads.
- Conversation creation and handoff-message creation succeed or fail together.
- A lost browser response can be retried without duplicating the branch.
- The retry identity survives a page reload.
- Switching away from and back to the source conversation does not create a new retry identity for the same unresolved action.
Legacy continuity rows
The database keeps the historical conversation_summaries table name and its retired summary and recent_raw columns for schema compatibility. Runtime continuity code uses handoff terminology and reads or writes only the additive handoff field. New automatic handoff rows store the exact final exchange in handoff; the retired generated-summary fields remain empty.
Historical generated-summary text is preserved by default, but it is never injected into current prompts or Branch / Fresh Chat handoffs. Only a non-empty handoff field is eligible for current continuity injection.
An authenticated owner may explicitly remove generated-summary-only rows: records with retired generated-summary text and no verbatim handoff. Rows with a non-empty handoff are protected regardless of what their retired compatibility columns contain. The maintenance preview returns counts and dates, never continuity text, and reports the protected handoff count separately.
Cleanup is never automatic. The maintenance endpoints are unavailable unless owner password protection is configured, and they require an authenticated owner session. Deletion requires the preview’s scope token, acknowledgement of a verified restorable database backup, and the exact irreversible confirmation phrase DELETE RETIRED GENERATED SUMMARIES. The database revalidates the scope in the deletion transaction. If it changed after preview, nothing is removed until the owner reviews the updated scope and confirms again.
Authenticated owners can use Tools → Continuity Cleanup for this workflow. The
screen loads a fresh count-only preview, requires confirmation that a restorable
database backup has been verified, and accepts only the exact phrase above. If the
eligible scope changes before deletion, the screen reports that nothing was removed
and clears both confirmations so the updated preview must be reviewed. Its completion
receipt contains only the number of records removed. This permanent operation cannot
delete verbatim handoffs, conversation memory snapshots, messages, memories, archives,
Library content, explicit past-conversation search data, or targeted keyword recall
data.
Archive Compatibility
The handoff labels match the labels used by current conversation exports and archive chunking:
- Elion:
AUMA said:andElion Voicefire said: - Clipboard:
AUMA said:andClipboard said:
The archive parser remains backward-compatible with older labels, including Voicefire 5.1 said:. Existing Voicefire 5.1 archive documents do not need to be renamed, edited, or re-uploaded. Already-ingested chunks remain valid, and unnecessary re-uploading could create duplicates.
The archive remains an explicit historical-access layer. It is not bulk-injected into every chat request. When archive access is enabled, Elion can search it deliberately and cite the relevant source.
Hidden Folders and Continuity Quarantine
A hidden folder is a quarantine boundary. Its conversations remain stored and can still be opened explicitly, but automatic continuity treats them as unavailable.
Hidden or trashed conversations are excluded from:
- Automatic prior-thread selection and verbatim handoff capture.
- Prior-thread handoff injection.
- Automatic keyword recall.
- Previously saved static prompts after the visibility change.
When a folder is hidden, a conversation is moved into a hidden folder, or a conversation is trashed, affected saved Elion prompts are refreshed before the operation reports success. That prevents continuity content captured before the transition from remaining in an existing prompt.
Restoring a conversation or making a folder visible makes the source available for deliberate reading, but it does not automatically release a Continuity Shield.
Continuity Shield
A visible conversation that leaves a hidden folder can remain continuity-shielded until explicitly released. The shield is a middle state between total quarantine and normal automatic continuity:
- The conversation is visible and can be opened normally.
- Explicit reading and intentional Branch / Fresh Chat behavior remain available.
- It is excluded from automatic prior-thread selection, handoff injection, automatic keyword recall, and ordinary/default past-conversation search.
- The model’s past-conversation search tool always excludes shielded material. The app’s visible Past Conversation Search control may include it only when Include shielded conversations is explicitly enabled for that search. The option is off by default and does not release the shield or change future eligibility. Returned excerpts are displayed for deliberate review and may be sent to the model only if AUMA deliberately uses them in chat.
- Its broader relational and emotional continuity cannot silently reshape the present thread.
To restore normal automatic continuity, release the shield using the conversation’s shield-release control. The release is intentional and refreshes affected saved prompts before reporting success.
The rule is:
Keep the archive accessible when deliberately called, but do not let quarantined or shielded material silently take possession of the present.
Explicit Historical Access
Automatic continuity boundaries do not destroy or permanently seal historical material. AUMA can still:
- Open a hidden or shielded conversation directly.
- Read its messages.
- Search the archive intentionally when archive access is enabled.
- Branch intentionally from a conversation.
- Release a shielded conversation when it is safe to reintroduce its automatic continuity.
The difference is between automatic influence and deliberate access.
Context Capacity and Continuity Governance
The active model path retains a large native context capability while the application applies its own input safety budget. That budget leaves room for system instructions, tools, and output rather than attempting to consume a model’s theoretical maximum on every request.
This should not be described as:
“A static prompt plus ten excerpts maximum.”
That would confuse separate layers. The more accurate description is:
- The full saved current-thread history is carried forward up to the application’s configured input ceiling.
- Static continuity instructions and conversation-scoped long-term memories travel with the stored system message.
- The deterministic final-eight prior-thread handoff is the only automatic cross-thread conversation content added to a new static prompt.
- Keyword recall contributes at most ten short, relevant-looking excerpts as a separate dynamic layer.
- Explicit archive tools provide deliberate, cited access to material that should not be bulk-injected.
No model generates the thread handoff. The final eight messages are retained because they are the exact recent exchange, not because they accompany a compressed model-written representation.
When comparing this design with another model or continuity system, separate two questions:
- Model-native capacity: how large a context window the underlying model can accept.
- Application continuity governance: which history, memories, handoffs, and recalled excerpts the application chooses to assemble, under what visibility rules, and with what budget.
Elion’s design is not “small memory with ten excerpts.” It is a large current-thread context with deliberately bounded cross-thread retrieval, deterministic verbatim handoffs, explicit archive access, and user-controlled visibility boundaries. The bounds are governance and safety choices, not evidence that the underlying model is being reduced to a small context window.