Leviathan is an open-source memory and search layer for AI agents working with large operational datasets. It turns records from JSONL, JSON, CSV, TSV, SQLite, or database CLI exports into a local ranked full-text index, then gives an agent short cited result cards instead of raw logs. The project is packaged as a single Rust binary, so teams can run it next to exports and avoid adding another hosted datastore for agent memory.
The core workflow is simple: map an id field, optional title, group, date, filters, and display fields; build the index; then let an agent search with plain-language questions. Leviathan supports group-scoped lookup, phrase matching, exclusions, date filters, field filters, describe commands, get by id, upsert, and delete. Its README shows database-friendly ingestion through psql, SQLite, DuckDB, and other command-line exporters, which makes it useful for support tickets, maintenance logs, audit trails, customer histories, and other tabular corpora.
The most useful detail for builders is the token-control story. On the repository's synthetic maintenance-log benchmark, the author reports about 436 median tokens per question at one million records, compared with more than 107,000 tokens for a grep strategy using entity and question words. The same benchmark reports 99 percent relevant-record return in the top five and 33 ms median latency. Those numbers are benchmark-specific, but they explain the product idea well: keep bulk data outside the model context and pass only the records that answer the current question.
Leviathan fits teams that are building coding agents, support agents, ops copilots, or internal assistants that need trustworthy recall over large histories. It is not a hosted knowledge base and it does not replace a vector database for semantic search across unstructured documents. It is a small local indexing tool for structured records, citations, and deterministic retrieval. The optional MCP path also makes it easier to connect to Claude Code, Cursor, Codex, and other agent clients without writing a custom bridge.
Because the project is Apache-2.0 and ships prebuilt releases plus a cargo install path, the pricing model is straightforward: the software is free to use, with your only cost being local compute and any agent tokens consumed downstream. Builders should still budget time to design the field mapping carefully; the quality of result cards depends on useful ids, titles, group keys, dates, and display fields.
In day-to-day use, Leviathan is most valuable when the dataset is too large for a prompt but still structured enough to map cleanly. A support engineer can index tickets by customer, date, priority, and resolution. A site reliability engineer can index incident notes or maintenance events. A product team can index feedback exports and ask for the few records that explain a pattern. The important constraint is that the user still owns the source data and mapping. Leviathan makes retrieval cheap and repeatable, but it does not decide which fields are trustworthy or which records should be included.
For adoption, start with one export and write a clear config. Check that ids, titles, dates, groups, and display fields produce useful cards. Then test the exact questions your agent will ask. If the cards cite the right records, connect the command to your agent workflow. If results are noisy, fix the field mapping before adding more data. That loop keeps the index explainable and prevents the agent from treating unrelated rows as context.