Resume a Session - PraisonAI

Resume a previous conversation exactly where you left off — same model, same agent, same chat history.

Quick Start

Find your session ID

praisonai session list

Copy the session ID from the output table.

Resume the session

praisonai session resume <session_id>

The CLI restores your prior model, agent name, full chat history, and cumulative usage totals, then shows:

╭─ Session Resumed ──────────────────────────────────╮
│ Session: my-assistant                               │
│ Model: anthropic/claude-3-5-sonnet-latest           │
│ Messages restored: 12                               │
│ Usage:  12,440 tokens · $0.0710 (3 requests)        │
╰─────────────────────────────────────────────────────╯

--- Restored Conversation ---
[user] What is the capital of France?
[assistant] Paris.

The Usage line appears only when token/cost data has been accumulated for the session. Cumulative totals keep accumulating from this point — they do not reset.

Continue with a new prompt

praisonai session resume <session_id> "What about Germany?"

Passes the resumed state directly into the same run path as praisonai run --session.

Give the session a friendly title (optional)

Rename the session so it’s easy to spot in session list — the id you resume with never changes:

praisonai session rename <session_id> "fix-auth-bug"

The title then surfaces in the Name column of session list. See Session Rename for details.

View transcript only (read-only)

praisonai session resume <session_id> --transcript

Prints recent events without restoring state — useful for reviewing a session without continuing it.

How It Works

The rehydrate_session() helper searches stores in order and returns a RehydratedSession dataclass:

from dataclasses import dataclass, field
from typing import Optional

@dataclass
class RehydratedSession:
    session_id: str
    chat_history: list[dict[str, str]] = field(default_factory=list)
    model: Optional[str] = None
    agent_name: Optional[str] = None
    metadata: dict = field(default_factory=dict)
    usage: dict = field(default_factory=dict)  # cumulative token/cost totals
    found: bool = False

When found is False, the CLI prints:

Error: Session not found: <session_id>
  → Use 'praisonai session list' to see available sessions

Model Restoration

Resuming restores the model the session was running with — not the current default. Change your default model between runs and a resumed session still runs on the original model. When the recorded model is used, the CLI prints:

Restored session model: anthropic/claude-3-5-sonnet-latest

Precedence (first match wins): explicit --model → config agent.model → recorded session model → keyless local-first fallback → default resolution.

The recorded-model lookup runs before the keyless local-first credential gate. A resumed cloud session on a machine with a reachable local endpoint (Ollama, LM Studio) is no longer silently switched to the local model. See PraisonAI #3685.

Override the recorded model

Pass --model on resume — it wins and becomes the new recorded model for subsequent turns.

praisonai session resume abc123 --model gpt-4o "continue with a different model"

Where the model comes from

The store resolves the recorded model in this order: the session-level metadata["model"] (written by the session-continuity path), then the model on the most recent turn that recorded one. When neither exists, restoration is skipped and normal default resolution applies.

Legacy sessions

Sessions written by older PraisonAI versions stored model / llm as top-level fields rather than under metadata. The store folds those legacy fields back into metadata on load, so historical sessions recover their recorded model on resume without any migration step. Existing metadata values always win over the mirrored top-level value.

Cumulative Usage Across Resumes

Token and cost totals accumulate across all runs for a session. When you resume and run more prompts, the totals grow — they are never reset. The store that already holds usage metadata takes priority on resume — a globally-stored session resumed via the project store keeps its original totals intact.

Project vs Global Store

The resume helper always searches the project-scoped store first, then falls back to the global default store. This means sessions created inside a project are resolved with higher priority, and you can still resume cross-project sessions by ID. The project_path parameter (optional, defaults to cwd) controls which project store is searched first. Use it when running resume from a different working directory:

praisonai session resume <id>

Flags

Flag	Description
`<session_id>`	Session ID to restore (required)
`[PROMPT]`	Optional prompt to continue the session immediately
`--transcript`	Show transcript only — do not restore state

Relation to `run --continue` / `run --session`

praisonai session resume and praisonai run --session <id> call the same rehydrate_session() helper under the hood. The outcomes are identical: same chat history, same model, same agent. Use whichever form fits your workflow.

# These are equivalent:
praisonai session resume abc123 "next question"
praisonai run --session abc123 "next question"

As of the fix for PraisonAI #2655, run --continue also searches both stores when finding the last session — before, only session resume did. As of praisonai/PraisonAI#3203, both the resume path and the show/delete/export path enumerate the same store instances (same classes, same order) by delegating to a single canonical_cli_stores() helper — so an id you can resume is guaranteed to also be show-able, delete-able, and export-able.

For the memory-driven resume path (different code path, uses DefaultSessionStore memory layers), see Session Resume in Persistence.

Best Practices

Pin a session ID in scripts for reproducibility

Store the session ID in an environment variable or config file so automation scripts always resume the correct conversation:

SESSION_ID="abc-123-def"
praisonai session resume "$SESSION_ID" "run daily report"

Use --transcript only for read-only viewing

--transcript shows events without restoring state, making it safe to inspect a live session from a second terminal without risk of creating conflicting state.

Resume after switching machines

The global store covers cross-machine cases when the same project root is checked out. Sessions written to the project-scoped store travel with the project directory.

Check session list before resuming

Always run praisonai session list first to confirm the session ID and its message count before resuming — especially after long gaps.

Session List

View and manage all sessions

Session Rename

Give a session a friendly title for easy scanning

Run Command

praisonai run —session and —continue flags

Session Persistence

How sessions are stored and retrieved

Memory-based Session Resume

The memory-driven session resume path

​Quick Start

​How It Works

​Model Restoration

​Override the recorded model

​Where the model comes from

​Legacy sessions

​Cumulative Usage Across Resumes

​Project vs Global Store

​Flags

​Relation to run --continue / run --session

​Best Practices

​Related

Session List

Session Rename

Run Command

Session Persistence

Memory-based Session Resume

Quick Start

How It Works

Model Restoration

Override the recorded model

Where the model comes from

Legacy sessions

Cumulative Usage Across Resumes

Project vs Global Store

Flags

Relation to `run --continue` / `run --session`

Best Practices

Related