Architecture documentation from code and model calls
Litho takes a source tree and tries to turn it into the architectural explanation most repositories lack. The command-line application scans files, extracts structure and relationships, sends selected material through language-model agents, composes Markdown and Mermaid diagrams, checks the result, and writes an organized documentation tree. The intended output covers a project overview, architecture, workflows, deeper module notes, external boundaries, and database structure.
This is broader than generating API pages from docstrings. Litho tries to infer why components exist and how they interact. Its four-stage design separates preprocessing, research, composition, and verification. Specialized agents examine system context, domain modules, workflows, boundaries, and important code. For a team approaching a poorly documented service, that can create a useful agenda for conversations and code reading.
The key word is draft. A language model can produce plausible explanations that the source does not support, miss behavior hidden behind configuration, or misunderstand a business boundary. Mermaid syntax validation can show that a diagram renders, not that the architecture is true. Owners still need to review claims, correct diagrams, and decide which generated pages deserve long-term maintenance.
More than a one-shot prompt
Litho has several thoughtful pieces around the model calls. It caches analysis so unchanged work can be reused, runs research agents in parallel, and supports separate efficient and powerful model choices. Version 1.5.0 added layered parsing fallbacks after models, particularly local and non-OpenAI providers, returned malformed or unexpectedly wrapped structured data. It also added retry and backoff controls plus provider-specific extraction behavior.
External knowledge is the strongest feature for serious documentation. A team can feed the tool existing Markdown, PDFs, SQL, YAML, JSON, and plain text, group those files into categories, and target them at specific agents. That gives the generator architecture decisions and business context that source code alone cannot reveal. Chunking, caching, file watching, and forced synchronization make the feature more than a single extra prompt attachment.
Database analysis is similarly concrete. Litho can inspect SQL projects and SQL files, then document tables, views, procedures, functions, relationships, and data flows. The output can include Mermaid entity-relationship diagrams and a database overview alongside the application pages. SQL Server and warehouse-heavy projects are a particularly plausible fit.
The resulting files can be committed, published with an existing Markdown site, or read through the separate Litho Book project. Keeping documentation current still requires rerunning Litho in CI and reviewing changes. The README says CI integration is supported, but it does not turn generated prose into an automatically trusted source of truth.
Installation is the easy part
The documented prerequisites are Rust 1.70 or later and Cargo. cargo install deepwiki-rs installs the binary, and a basic command points it at a project and output directory. Source builds are conventional Cargo builds. The repository offers an English README, a Chinese translation, and documentation directories for both languages.
Configuration adds the real work. Users must provide a compatible model endpoint, credentials, model identifiers, and language choice. Local models avoid sending code to a hosted provider, but the 1.5.0 release notes acknowledge that local providers were a major source of structured-output failures. Hosted models raise privacy, rate-limit, and token-cost questions. Before scanning proprietary code, verify what the chosen endpoint logs and whether policy permits uploading source and internal documents.
The README itself needs editing. Its advanced command includes --model-poweruful, later switches from --llm-api-key to --llm_api_key, and repeats the efficient-model option. The basic documentation section also shows a sentence where a runnable command should be. Detailed architecture diagrams and configuration samples help, but these mistakes make the most important first-run path less dependable than it should be.
Large repositories are the danger zone
Issue activity provides specific warnings about scale. In issue 107, a user reports analyzing 1,697 files for more than 12,000 seconds and spending over $100 before repeated 504 responses stopped the research stage. The user could not find persisted analysis in the expected cache directory. That is one environment and provider, not a universal benchmark, but it demonstrates how a long run can fail after the expensive part.
Issue 87 describes a roughly 400 MB internal repository with 11,095 source files. Memory reportedly peaked at 127.38 GB before an allocation failure, with no generated output. Another report says a project with more than 2,000 files ran over 12 hours and exhausted an 8-core, 16 GB machine. These reports were later closed with a suggestion to try the project’s agent skill, not with evidence in the thread of a bounded-memory fix for the CLI.
Start with one service or directory, watch memory and token usage, and inspect intermediate caching. Set provider budgets and request limits. Compare a sample of generated claims against code before increasing scope. A fast language and parallel pipeline cannot eliminate the amount of source being read or the number of model calls the workflow requests.
Health and the buying decision
The code was last pushed on July 24, 2026. GitHub lists 1.5.0 from April 5 as the latest release, while crates.io published 1.5.1 on July 16 after a user reported that the tagged 1.5.0 artifact failed on tool calls. The repository has six open issues and pull requests combined. Recent maintainer responses and a post-release fix show continued work, although formal GitHub release metadata lags the package registry.
Litho is an interesting architecture assistant, especially when C4-shaped output, external context, and SQL documentation align with the job. It is not yet a low-risk batch job for an enormous repository. Adopt it as a supervised documentation accelerator, keep humans responsible for accuracy, and prove the economics on a narrow code slice first.