Suvadu vs Atuin: Shell History and AI Agent Workflows

Atuin and Suvadu both keep shell history in a local SQLite database with far more context than a history file, both record commands run by AI coding agents, and both ship an MCP server. Feature checklists therefore do not separate them well. This comparison instead walks through four jobs you might hire either tool for: recovering a command, importing existing history, inspecting what an agent did, and finding out why a command failed.

Review note: I build Suvadu, so read this as a maker's comparison. On 20 October 2026 I re-checked every Suvadu claim against Suvadu 0.5.1 (its release notes and README) and every Atuin claim against the Atuin v18.24.0 release (published 15 October 2026), reading its threads, MCP and agent-hook docs at that release tag. This is a documentation and source review: I did not install and benchmark Atuin, so there are no comparative performance claims here.

The short decision

If you already use Atuin, switching to Suvadu 0.5.1 has real costs: there is no sync, no session resume across machines, and no Fish, Nushell or Windows support. Since Atuin 18.24 captures agent sessions too, Suvadu's case is narrower than it was: Cursor and Antigravity coverage, no daemon, repository-level change snapshots, risk rules and cross-agent skills. Check those against how you work before switching.

Suvadu vs Atuin at a glance

Task 1: recover a command you ran months ago

Atuin's interactive search is fuzzy by default and can switch between all history, one host, the current directory, the current Git workspace, or the current session. Its configuration also offers prefix, full-text, and daemon-backed fuzzy modes. Both Ctrl+R and Up-arrow open that interface by default; --disable-up-arrow keeps the shell's normal arrow behavior.

Suvadu's Ctrl+R search defaults to literal words: every typed word must appear as a substring, ranked prefix first, then contiguous, then in-order and any-order word matches. Since 0.5.1, a query that matches nothing is retried once with separators ignored, so hiveagent finds hive-agent, and within a tier the Smart rank weighs frecency, demotes commands that usually fail, and boosts what you usually run next. Since 0.4.2 that is one of four modes you can switch with Ctrl+X or --match: terms (the default), literal, prefix, and fuzzy, where gco does find git checkout. --scope (Ctrl+P) narrows to this directory, this Git workspace, or this shell session. Matching decides what is eligible and scope decides where to look, so neither is affected by how results are ranked. Up-arrow stays in the prompt and cycles recent commands, preferring the current directory on ties.

Fixed in Suvadu 0.4.2: typed search used to match only within the newest ~5,000 eligible entries, so an older command could be missing from the results even though it was still stored. Candidate selection and counting now happen in SQL across the whole eligible history, so an older command is found. A 5,000 limit remains, but it is a ranking window rather than a search window: the newest 5,000 matches are ordered by relevance and everything beyond them is paged newest-first, and the reported result count is always one you can page to.

Neither search model wins universally. Since 0.4.2 both tools offer fuzzy matching and scope switching, so the difference is the default and the framing: Atuin is fuzzy first and opens its UI on the Up arrow, while Suvadu defaults to literal words, keeps the Up arrow in the prompt, and asks you to choose a mode explicitly. If predictable literal inclusion and conventional recent-first arrow recall are easier to reason about, Suvadu may suit you.

Task 2: import the history you already have

Atuin's import reference documents atuin import auto, which detects your shell, and dedicated importers for Bash, Zsh, zsh-histdb, Fish, Nushell, xonsh, PowerShell, resh, and replxx.

Suvadu 0.5.1 imports four formats:

suv import --from zsh-history ~/.zsh_history --dry-run   # preview
suv import --from zsh-history ~/.zsh_history
suv import --from bash-history ~/.bash_history
suv import --from atuin-db ~/.local/share/atuin/history.db
suv import backup.jsonl                                    # a Suvadu JSONL export

Migration limits to plan for:

• The Atuin importer reads the database itself. suv import --from atuin-db opens history.db read-only, so a running Atuin keeps working, and it is tested against Atuin 18.0.0 to 18.23.0; an untested schema is rejected rather than guessed at. Atuin 18.24 moved its data under ~/.atuin, and the importer has not yet been tested against an 18.24 database. Time, directory, exit code, duration, session, host, and author come across, and Atuin's -1 exit code and duration are stored as unknown rather than as a success. Unless you pass --no-backup, the Suvadu database is backed up first and the rollback command is printed.
• Bash history carries less than Zsh history. suv import --from bash-history ~/.bash_history works, but a file written without HISTTIMEFORMAT has no timestamps and no multi-line command boundaries, so each line is imported as one command with an explicit 1970-01-01 placeholder time. Directory, exit code, duration, and executor are never in a Bash history file and are stored as unknown.
• Zsh imports carry what the file has. With EXTENDED_HISTORY you keep timestamps and durations; since 0.5.1 plain-format lines get the explicit 1970-01-01 placeholder time, as Bash imports do, and a re-import adds nothing. Directory, exit code, and session were never in the file, so imported entries do not have them.
• New context starts at activation. Rich fields such as directory, exit status, and agent attribution exist only for commands recorded after the shell hook or agent integration is active.
• Nothing is changed at the source. Importing reads the file; your Zsh history file and any Atuin database stay as they are.

Running both tools side by side is not a tested setup yet. Both bind Ctrl+R and the arrow keys, so if you experiment, keep only one tool's bindings active.

Task 3: inspect what an agent session did

Atuin's agent hooks (atuin hook install claude-code, codex, opencode, or pi) record each Bash-tool command an agent runs, with the agent as author, plus directory, timestamp, exit code, and duration. Interactive search hides these by default, and atuin search --author filters by agent. Since 18.24, Atuin also captures the sessions themselves as threads once you run atuin threads enable, which turns on its daemon. A thread keeps the conversation, every tool call's input and output (the commands run and what they printed, the files read and written), and the diff the agent recorded for each edit, with recognised secrets replaced. Threads sync like history, and atuin resume reopens one on this machine or another, forks it, or continues it in a different agent. For Claude Code, Codex, opencode and pi, that is a fuller record of the conversation than Suvadu keeps.

Suvadu records agent commands too, and for Claude Code, Codex, and OpenCode it captures the native session through the agents' own hooks, with no daemon: your prompts, the assistant's responses, every observed model, and provider-reported token counts, including sessions that ran no commands. Since 0.5.1 Cursor conversations are sessions too, without token counts, which Cursor's hooks do not report; Antigravity's agent commands are recorded, without prompts. It does not keep tool-call output or edit diffs. Instead, each session in a git repository gets a snapshot of the commit, branch and changed paths at its first prompt and each turn end, so what_changed and the session timeline report what changed in the repository, including changes made by commands rather than edit tools, as observed rather than guessed. A typical 0.5.1 workflow:

# once per agent (rerun after upgrading, then fully relaunch the agent)
suv init claude-code        # or: suv init codex, suv init opencode, suv init cursor

# after some agent work
suv sessions                # one picker for terminal and agent sessions; Ctrl+T cycles All/Human/AI
suv agent sessions          # the same AI sessions as JSON, for scripts
suv agent session <id>      # events, commands, tokens, and saved summaries as JSON

For Codex, also review and trust Suvadu's hooks with /hooks in the Codex CLI. A transcript that was not captured live can be added with suv agent import-session <path> (Codex or Claude Code JSONL).

Atuin's atuin resume continues a session in another agent directly. Suvadu's way to hand work from one agent to another is a summary checkpoint the agent writes; allow connected agents to save them. This write is off by default; add it to Suvadu's config.toml and restart the agent so its MCP server reloads:

[mcp]
allow_session_summaries = true

Then ask the agent to "summarize and save this session". It finds the session (resolve_current_agent_session), reads it (get_agent_session), and saves a summary with references to the captured evidence (save_session_summary). The agent writes the summary; Suvadu stores it. Another agent, or you in suv sessions (press s on an AI session), can read it later. Token figures are what each provider reports, not a normalized cost estimate.

Shared skills work alongside this. Keep a recurring checklist once and write it into each agent's own files:

suv skills add deploy-checklist --description "Steps before a deploy" < deploy.md
suv skills sync             # Claude Code skills, Cursor rules, Codex AGENTS.md

Atuin also has skills, used by its built-in Atuin AI assistant; Suvadu's difference is managing one set of instructions across external agents. Suvadu's Prompt Explorer and agent reports add prompt-to-command browsing and risk summaries.

Next step: the sessions guide covers capture coverage per agent, the session browser, and saving and reading summaries in detail.

Task 4: find out why a command failed

Both tools record the exit code, so both can list failed commands, including through MCP: Atuin's history tool has a failed-only filter, and Suvadu has what_failed, which groups recent failures by the prompt or session that triggered them, and learn_from_failures, which reports recurring failures in a project.

Seeing the actual error text is different. Atuin can capture command output when you enable its daemon and PTY proxy (off by default). In 18.24.0 captured output is stored on disk, by default up to 1 MB per command within a budget of 10% of the disk holding Atuin's data, and the oldest output is dropped first; Atuin's output-capture page still describes an earlier in-memory store. Its MCP output tools let an agent read one command's output or search across all captured output, which atuin output search also does from the shell. Suvadu 0.5.1 can keep the end of a failed command's output, opt-in ([capture] failure_output = true): the last 4 KB, redacted, where an agent hook already carries it (Claude Code, Cursor, Codex, OpenCode) or under suv wrap. Its what_failed, command_status and learn_from_failures tools then show it. It never captures output from commands typed in your shell, keeps nothing for successful commands, and has no output search. It also says what fixed a failed command last time, inferred from what ran next. If agents searching real output of everything you ran is central to your workflow, Atuin has the direct answer.

MCP: both expose history to agents

Atuin 18.24.0 ships a read-only MCP server with six tools: atuin_history, a history search returning command, time, directory, exit code, and duration with scope, failure, and author filters; atuin_output, which reads a command's captured output by line range; atuin_output_search, which finds commands whose captured output contains all of the given words; and atuin_ai_session_search, atuin_ai_session_list and atuin_ai_session_read for threads. atuin mcp install <agent> registers it with Claude Code, Codex, opencode or pi. The output and thread tools need the daemon and the matching capture turned on.

Suvadu's local MCP server exposes 22 read-only tools by default, covering command history, project context, recurring failures, risk assessment, skills, bookmarked command templates, agent sessions and what they changed, plus resources and prompts. Two write paths, saving session summaries and proposing skills for human review, are off until you enable them. A larger tool count is not proof of better answers; compare the specific questions you want an agent to answer.

Local storage and sync

Both tools store history locally. Atuin's sync setup is optional and end-to-end encrypted; users can choose its hosted service, self-host, or stay local. If seamless history across several machines is the requirement, Atuin has the direct answer.

Suvadu has no sync service. It can export JSON, JSONL, or CSV and import JSONL; JSONL re-import skips duplicates by default. Moving and scheduling those files is your responsibility. In either tool, an MCP client that reads your history receives that data and may send it to its model provider under the client's settings.

Performance and maturity

Both command-line clients are written in Rust. This review did not run comparable benchmarks on the same hardware and history dataset, so it would be misleading to name a speed winner. Test startup, search responsiveness, and search completeness with your own history if they are deciding factors.

Atuin is much older and more widely used, with broader shell and platform support, more import paths, and since 18.24 synced, resumable agent sessions. Suvadu is a young project with a narrower shell focus; its investment is in agent coverage beyond Atuin's four agents, repository-level change snapshots, risk rules, and shared skills.

Should you switch?

Stay with or choose Atuin when shell recall is the main job, when you need its import coverage, wider shell and platform matrix, fuzzy scoped search, encrypted sync, captured command output for agents, or agent sessions you can resume on another machine or in another agent. Try Suvadu when Bash or Zsh is enough and you want agent sessions without a daemon, Cursor and Antigravity covered, token counts, repository snapshots of what each session changed, risk rules and cross-agent skills, and the migration and search limits above are acceptable for you.

brew tap AppachiTech/suvadu && brew install suvadu

curl -fsSL https://downloads.appachi.tech/suvadu/install.sh | bash

cargo install suvadu

eval "$(suv init zsh)"

source ~/.zshrc

eval "$(suv init bash)"

source ~/.bashrc

suv doctor

If neither description settles it, keep your current history data intact and try Suvadu on one agent session first; the sessions guide shows what to check. For the broader field, see Atuin, fzf, McFly, hstr, and Suvadu compared.