Litho generates an architecture draft rather than API reference pages
Litho scans a source tree, extracts structure and relationships, sends selected material through language-model agents, and writes Markdown with Mermaid diagrams. The intended output covers a project overview, C4 context, containers, components, workflows, module notes, boundaries, and database structure. That is broader than generating API pages from comments because the model tries to infer why pieces exist and how they interact.
Its pipeline separates preprocessing, research, composition, and verification. Specialized agents examine system context, domain modules, workflows, boundaries, and important code. For a team approaching an undocumented service, the result can provide an agenda for code reading and design interviews. It should not replace those interviews.
A model can invent a relationship, miss behavior hidden behind runtime configuration, or mistake a directory boundary for a system boundary. Mermaid validation proves that a diagram parses, not that it describes the software accurately. Owners still need to check claims against source and decide which pages deserve maintenance.
What happened when we ran it
Our sandbox installed 271 Rust packages in 21 seconds and completed the build in 130 seconds. The checkout at commit 7620742 contained 198 files, about 25,662 lines of source, and 3 MB before dependencies. It had 1 CI workflow file, no Dockerfile, and no tests directory. We used an unprivileged rust:1-bookworm container with 3 CPUs and 12 GB of RAM.
Tests completed in 26 seconds with all 60 passing and 0 failures. Cargo exited successfully. No failed test, missing system package, or compiler error appeared in our measurement. Among these seven reviewed repositories, Litho was the only one whose provided build and complete test step both passed.
That clean result covers the Rust code at commit 7620742. It does not test the accuracy of generated architecture, model-provider reliability, token spending, latency on a large repository, or the privacy policy of an external endpoint. Those are workload checks rather than facts established by a 60-test source suite.
External knowledge gives the model context code cannot supply
Litho can mount Markdown, PDF, text, SQL, YAML, and JSON as extra knowledge. Files may be grouped into categories and sent to selected agents. Chunking, overlap, caching, file watching, and forced synchronization make this more useful than pasting one architecture note into a prompt. Existing decisions and domain terms can correct gaps that source code alone cannot fill.
Database analysis is similarly concrete. The tool can inspect SQL files and document tables, views, procedures, functions, relationships, and flows. Output includes a database overview and Mermaid entity-relationship diagrams. SQL-heavy services and warehouse projects are plausible targets, provided a database owner verifies the generated relationships and descriptions.
The files can be committed or published through an existing Markdown site. A separate Litho Book project provides browsing, search, Mermaid rendering, and questions. The README also points to Terrain as the evolving product built on top of Litho, while stating that Litho remains the focused C4 documentation generator. Buyers should choose based on the current CLI, not assume Terrain features are already inside it.
Provider configuration is where the real setup starts
The documented local requirement is Rust 1.70 or newer, followed by cargo install deepwiki-rs. A basic command chooses the project and target language, with output written under litho.docs. Useful runs also need an endpoint, credentials when required, model identifiers, caching choices, and any knowledge sources.
Release 1.5.0 added lenient parsing, provider-specific extraction, retries, and backoff after models returned malformed structured data. The notes specifically discuss Ollama and OpenAI-compatible providers. These fallbacks reduce brittle JSON failures without making providers equivalent. A small local model may have different context and reasoning limits from a hosted model, while a hosted service may retain code or charge for a long scan.
The README's advanced commands need correction. One example spells the powerful-model flag --model-poweruful, mixes hyphens and underscores in the API-key flag, and repeats the efficient-model option. That is a small documentation defect at the point where a new user most needs a copyable command. Run --help and confirm actual flags rather than trusting the example verbatim.
Closed scale reports still define useful pilot limits
Closed issue 107 describes 1,697 files analyzed over roughly 12,093 seconds with more than $100 in model cost before 8 retries ended in HTTP 504 during research. The user asked whether the expensive preprocessing was persisted. The report is one provider and configuration, and its closure on August 14 does not itself prove current large-run economics.
Closed issue 87 describes an internal repository containing 11,095 source files and about 400 MB of code. The reporter measured a 127.38 GB memory peak before allocation failed and no output appeared. Again, this is a historical report rather than our benchmark. It gives adopters a reason to start with one service, watch memory, inspect caching, and cap provider spending.
Issue 71 requested sentence-level citations for generated statements. It was closed, but the README does not list that feature. A document can look polished without making each assertion traceable to a file or symbol. Teams with audit or compliance needs should check citation behavior directly and preserve reviewer ownership.
The 60-test result earns a controlled trial
GitHub showed 1,703 stars and 2 combined open issues and pull requests. The repository was pushed on August 14, 2026, while release 1.5.0 was published April 5. The later push and same-day issue closures show maintenance after the release; the older tag alone is not evidence that work stopped.
Litho is useful when the deliverable is a reviewable first draft, not automatic truth. Its C4 structure, external knowledge, database analysis, and clean 60-test run justify trying it. Select a representative directory, set a hard budget, inspect every generated page, and only then expand. If deterministic API pages are enough, Doxygen is simpler. If architecture decisions require accountable authors, an arc42 document may be the better tool.