Skip to main content

Sessions

A session is one ongoing conversation with Anyy. It has its own message history, active turn state, role, model selection, tool results, approvals, artifacts, and metadata. Sessions are owned by the gateway so they can survive a client restart and be reached from more than one surface.

This page covers the user-facing session model: how sessions start, how to resume them, what context is carried forward, and how branching and compression work in the current build.

Fast Paths

GoalUse
Start a new interactive sessionanyy
Resume a known session in the TUIanyy --resume SESSION_ID
Continue one session from the shellanyy chat --session SESSION_ID "Continue this"
List recent sessions in a live surface/sessions
Inspect the current transcript/history
Try another direction/branch optional title
Shorten a long session/compress optional focus

anyy chat talks to the resident gateway. If the TUI works but chat fails, check anyy gateway status and start the resident gateway.

How Sessions Work

Every message you send belongs to a session. The session id is the stable handle for that conversation:

  • The TUI creates a session when you start chatting.
  • anyy chat creates a new session unless you pass --session ID.
  • Messaging channels map each accepted conversation to a stable session.
  • Background child work and branch/compression operations create related child sessions.

The gateway records messages, turns, tool calls, approvals, generated artifacts, and session metadata in the profile's local state database. The visible clients are thin surfaces over that shared state.

What counts as context

A new turn does not blindly replay every byte ever written. The runtime assembles context from the active session, recent messages, relevant summaries, memory, skills, tool configuration, and surface metadata. Tool outputs and attachments can be represented in compact form when they are too large or no longer useful as raw transcript.

Memory is related but separate. Session history is the transcript of this conversation; memory is the durable cross-session layer. Compressing or pruning a session does not mean a fact has automatically become memory.

Session sources

Sessions can come from several surfaces:

SourceHow it starts
TUIRun anyy, or use /new inside the TUI.
CLI chatRun anyy chat "prompt", optionally with --session ID.
Messaging channelSend a message that the channel access policy accepts.
BranchUse /branch in the TUI to fork the current session.
CompressionUse /compress to create a shorter continuation session.
Background workUse TUI background commands or assistant delegation features.

All of these live inside the selected profile. A session in one profile is not visible from another profile.

Resume Sessions

Use the TUI when you want interactive resume:

anyy --resume SESSION_ID

Inside the TUI:

/resume SESSION_ID

Running /resume without an id opens the session picker. /sessions lists recent sessions, and /history opens the current session's message history.

For one-shot CLI usage, send another prompt to an existing session:

anyy chat --session SESSION_ID "Continue from where we left off."

--role only applies when creating a new chat session; it cannot be combined with --session.

There is no --continue shortcut in this build. Keep the session id from the TUI picker, /sessions, command output, or state tooling when you need a shell command to target a specific conversation.

Session Naming

Sessions have titles. The CLI uses the first prompt as the starting title for a new one-shot chat. The TUI can show and update titles through the session command catalog; /title is the gateway command for reading or changing the current session title when it is available in the connected runtime.

Branching preserves the parent title unless you provide a new one:

/branch alternate plan

If no title is provided, the branch title is based on the parent title with a branch suffix.

Cross-surface Continuity

Continuity comes from the gateway, not from a single client. If the same profile and gateway are in use, a session can be resumed from the TUI after it was created by anyy chat, and a CLI prompt can continue a TUI-created session when you pass its id.

Messaging channels use channel-specific routing. For example, a chat app direct message and a group conversation are different channel sessions. They share the profile's memory and configuration, but they do not share one transcript unless the channel adapter explicitly routes them to the same session.

The current user-facing surfaces expose recent-session and current-history views:

/sessions
/history

Anyy also has session search support in the runtime and state layer. When the session-search toolset is available to the assistant, it can search past transcripts and summaries to recall earlier work. There is not a standalone anyy session search CLI command in this build.

Current CLI Limits

Session management is mostly surfaced through the TUI, gateway commands, and runtime tools. The current top-level CLI does not expose standalone commands for session rename, delete, export, search, or prune-by-title.

Use /save from the TUI to export the current interactive transcript. Use maintenance commands for retention work that affects stored session data.

Session Compression

Session compression creates a new child session that carries a continuity summary and a protected tail of recent messages. The parent session remains stored. Use compression when a long conversation is still useful but too large to keep driving directly.

/compress

You can provide a focus:

/compress keep the deployment decisions and unresolved follow-ups

Do not confuse /compress with /compact. In the TUI, /compact on and /compact off only change transcript display density; they do not rewrite or summarize the session.

Session Branching

Branching creates a child session by copying the current session's messages and preserving parent/root metadata. It is useful when you want to try another path without disturbing the original conversation.

/branch
/branch compare a simpler approach

Branching is rejected while a turn is running. Stop or finish the active turn first, then branch.

Failure Modes

SymptomLikely causeFix
anyy chat --session ... cannot connectResident gateway is not running or the socket path is wrongRun anyy gateway status, then anyy gateway start.
/branch is rejectedA turn is still running, or there is no active sessionStop or finish the turn, then branch from an active session.
/compress creates another sessionThis is expected; compression creates a child session and keeps the parent storedUse retention/deletion commands if you intend to remove local data.
/compact on does not reduce context/compact is only a TUI display toggleUse /compress for session context compression.

Session Storage

The profile's local state database is the authoritative store for sessions, messages, turns, approvals, compactions, and related metadata. Raw JSONL segments, logs, artifacts, and generated files live under the same Anyy home directory.

Common paths under a profile home:

PathPurpose
state.dbLocal SQLite state store.
raw/Raw JSONL transcript segments used for inspection and recovery.
logs/Runtime and service logs.
private/blobs/Artifact blob storage for generated or attached files.
memory/Profile memory files and archives.

Cleanup And Retention

Retention is local to the profile. The default storage policy keeps a hot window of recent content and supports raw-log TTLs, state database maintenance, archive indexes, and inactive-session pruning.

Useful maintenance commands:

anyy maintenance compact-state
anyy maintenance checkpoint-state
anyy maintenance prune-inactive-sessions
anyy maintenance cache-token-estimates

Back up before destructive retention work:

anyy backup create

For the storage and deletion details, see Data, Retention & Deletion.