pond

Pond solves the problem of "agent sessions scattered across tools and impossible to search": the AI agent sessions you've run (Claude Code, Codex, any tool, any machine) stay on local disk, full of decisions, fixes, and dead ends, yet trapped inside their own unsearchable tools. Pond automatically and losslessly ingests them all into storage you own (a local directory or your own S3 bucket), making the entire corpus searchable, queryable with SQL, and handing that recall capability back to agents via MCP—so "how did we fix this before?" becomes a query, not archaeology. Sessions are no longer locked to the tool that created them: any session can be restored to any supported client and continued.

Purpose and Positioning Pond is the underlying storage and retrieval layer. Memory tools store the facts, summaries, and chunks they decide you need, and the session itself is already gone; what Pond preserves is the session itself: every message, every tool call and result, with full values, cross-client, in your own storage, never pruned, searchable via MCP, and restorable to any client. Memory is a derived view that can be rebuilt from the archive at any time, while the archive can never be rebuilt from memory.

Key Capabilities

• Automatic ingestion: automatically picks up sessions from Claude Code, Claude desktop app (local agent mode), Codex CLI, opencode, pi-coding-agent, oh-my-pi, OpenClaw, NanoClaw, Hermes Agent, letta-code, grok-build, Antigravity CLI (including its ACP server), and Devin CLI, among others. Claude.ai data exports can be imported with pond sync claude-ai-export --path <path> (manual download is required, so it is not auto-discovered).
• Lossless storage: a normalized Session / Message / Part intermediate representation; unknown record shapes can still be ingested losslessly; storage, indexing, OCC, schema evolution, blob columns, versioning, and time travel are all handled by Lance.
• Search: BM25 full-text search by default (word-level tokenizer + English stemming + ascii folding, with any language indexed equally); optional semantic search (intfloat/multilingual-e5-small, FP16 weights, macOS uses Metal, CUDA optional, CPU fallback), with only one retrieval arm per query, no server-side fusion.
• SQL: read-only SQL queries (same surface as the pond_sql MCP tool), planned by DataFusion over the same set of Lance datasets.
• Transport: HTTP+JSON (axum) and MCP (rmcp) share the same set of handlers; wire operations include pond_search, pond_get_session, pond_get_message, and pond_ingest, and MCP also exposes the read-only pond_sql tool and the schema://pond, schema://pond-sql, and stats://pond resources.
• Multi-tenancy: each tenant is a namespace string provided by the integrator; Pond does not do authentication, authorization, or identity modeling, and object storage IAM is the storage boundary.

Usage Installation and initialization: pond init registers Pond as an MCP server for Claude Code and installs the bundled pond skill; for Codex it prints the commands to run—then restart the client to load the tools. Manual approach: claude mcp add -s user pond -- pond mcp, codex mcp add pond -- pond mcp; skill: mkdir -p ~/.claude/skills/pond && pond skill > ~/.claude/skills/pond/SKILL.md (this whole line is POSIX-only; mkdir -p, &&, and > will error or break in Windows PowerShell 5.1, so use the PowerShell block in Connect your agents instead). You can also simply prompt the agent: "Please install and set up pond (see github.com/tenequm/pond)". Sync and search: pond init sets up storage, adapters, MCP registration, and an optional sync schedule all at once (idempotent, can be rerun at any time to repair or update); afterward, import local adapter sessions, update the index, and search. pond sync only ingests enabled adapters—Enabling is an explicit step (pond adapters enable / pond adapters discover / pond init), never a side effect of syncing. Storage: by default stored locally in ~/.local/share/pond (on Windows, %LOCALAPPDATA%\pond\data). Object storage can have credentials added and the target switched: pond init --storage-path <url> configures a remote target at setup time and prompts for credentials inline when the target is remote; s3+https://host/bucket form applies to any S3-compatible storage (Hetzner, R2, B2, MinIO); s3://, gs://, az:// use the standard cloud SDK credential chain when there is no matching [creds.*]. pond copy --from <local> --to <url> brings existing local data into a bucket (idempotent, never deletes the source, rebuilds the target index after completion and verifies every row, exiting with code 6 on missing or duplicate). Status and introspection: pond status prints each table's storage table, indexes (text readiness, including the semantic part only when embeddings are enabled), stored sessions and messages, source agents, and the local view (per-adapter sessions pending sync, last sync result including failure exposure from scheduled tasks, next scheduled run). pond status --hosts splits shared storage by ingest host; --include-subagents counts each subagent as an independent agent. pond sync --dry-run previews what the next sync will read; pond search --explain returns the Lance analyze_plan output for each retrieval arm. Maintenance: pond sync folds indexes by default on each run; pond optimize --only index runs on demand; embedding backlog is filled in one go with pond optimize --only embed. Periodic updates can be configured per platform with launchd, a systemd user timer or cron, or Windows Task Scheduler (must be run from a regular rather than administrator shell).

Platforms and installation channels Supports Linux, macOS, and Windows. macOS/Linux provides installation methods; the primary channel for Windows is Scoop (also bundled with pondw.exe, the windowless launcher used for scheduled sync runs); when there is no package manager, each release includes precompiled binaries (for Windows, pond-x86_64-pc-windows-msvc.zip, about 223 MB after extraction), just extract and add the directory to PATH. It can also be installed via cargo (requires the Rust toolchain; only installs pond.exe, for Windows scheduled sync use Scoop or the zip install instead, or build from source with --features windows-launcher; cargo install also requires the protoc and NASM prerequisites), or build from source (on Windows, run git config --global core.longpaths true first, and you must explicitly specify --target x86_64-pc-windows-msvc). Linux CUDA acceleration requires the corresponding feature; macOS automatically selects Metal, and other systems default to CPU fallback. Building from source on Windows also requires protoc (winget install Google.Protobuf) and NASM (winget install NASM.NASM, then add C:\Program Files\NASM to PATH yourself).

Use cases and limitations Suitable for developers and teams who want to uniformly retain and retrieve agent session history across tools and machines; for scenarios that need to archive sessions into their own object storage and ask structured SQL questions about the history; and for scenarios that need to hand history recall back to the agent and be able to restore any session to any supported client. Limitations and cautions: the status is pre-v1, and schemas, wire formats, and configuration keys may undergo breaking changes before v1; complete documentation is at pond.locker, and the contract is in docs/spec.md. Adapters are maintained on a best-effort basis, and format drift is designed to be safe (unknown record shapes are still ingested losslessly, and malformed input is surfaced as typed errors naming the file). Pond itself does not perform authentication, authorization, or identity modeling, nor does it hold keys or add application-layer encryption; encryption is an operational concern (bucket SSE and filesystem encryption). Semantic search is off by default, and when off no Pond process downloads or loads embedding models. Storage backends are supported via Lance's object_store integration for local FS / S3 / GCS / Azure. Adding new adapters is routine work; see Contributing.