LocalGPT: a Rust assistant and a Bevy world generator in one repository
Local AI assistant, dreaming explorable worlds.
At a glance
- What is it?
- LocalGPT ships two binaries: a local-first chat assistant with markdown memory, and localgpt-gen, which turns natural language into Bevy 3D scenes. The interesting part is the split, not the branding.
- Who is it for?
- Adopt localgpt if you want a single Rust binary for a local chat assistant with a markdown memory store, or if you are building Bevy scenes and want prompts plus a headless batch mode to drive geometry, materials and lighting. Do not adopt it if you need a stable released version, a documented upgrade path, or a tool whose full configuration reference you can read without leaving the repository.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 86 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Two products behind one crate name
The repository publishes two separate binaries, and the README treats them as distinct products. localgpt-gen is described as a standalone binary for AI-driven 3D world creation on top of the Bevy game engine. localgpt is described as a local-first AI assistant with persistent memory, autonomous tasks and multiple interfaces. They install separately: cargo install localgpt-gen for world building, cargo install localgpt for chat, memory and the daemon. That split matters when you evaluate the project, because the two halves have different audiences, different failure modes and different dependencies. A studio evaluating scene generation does not care about the Telegram bot. Someone who wants an offline chat assistant with a searchable knowledge store does not need Bevy pulled into their build. The README does not state whether the two binaries share a memory system or whether Gen's style learning writes into the same workspace layout as the assistant's MEMORY.md. That is a question to settle before you assume one tool feeds the other.
The memory layout is the actual architecture
The assistant's design is visible in the workspace tree the README prints. Four entries sit at the workspace root: MEMORY.md for long-term knowledge that is auto-loaded each session, HEARTBEAT.md as an autonomous task queue, SOUL.md for personality and behavioral guidance, and a knowledge/ directory for a structured knowledge bank. Indexing is handled by SQLite FTS5 for keyword search and sqlite-vec for semantic search with local embeddings. This is a plain-file design with a database index bolted on, and the trade-off is explicit. You can read and edit the assistant's long-term memory in any text editor, and you can put the workspace under version control. What you give up is any schema guarantee: MEMORY.md is prose, so retrieval quality depends on how the model wrote to it in earlier sessions. The README does not describe a compaction or pruning policy for that file, which is the thing most likely to degrade over months of use. HEARTBEAT.md as a task queue has a similar shape: the queue is a file, and the README does not document concurrency behaviour if the daemon and a CLI session both process it.
Getting either binary running
Installation is two cargo commands, and the README is explicit about which is which. From crates.io, cargo install localgpt-gen and cargo install localgpt. From a clone, cargo run -p localgpt-gen -- "Create a desert scene with pyramids" for world building, and cargo run -- chat or cargo run -- daemon start for the assistant. Gen mode takes flags the README lists: --scene ./world.glb to load an existing scene, --verbose for logging, and a positional prompt. Headless generation is localgpt-gen headless --prompt "Build a cozy cabin in a snowy forest", with an optional --style "Studio Ghibli" hint. The MCP server starts with localgpt-gen mcp-server, and the README gives the Claude Desktop config block verbatim: a mcpServers entry named localgpt-gen whose command is localgpt-gen and whose args array is ["mcp-server"]. For CLI tools such as Claude CLI, Gemini CLI or Codex CLI, the README points at a --connect flag that routes tool calls to an existing window. Assistant configuration lives at <config_dir>/config.toml. A fully offline setup uses default_model = "openai/qwen/qwen3.5-35b-a3b" under [agent] and an [providers.openai] block with api_key = "lm-studio" and base_url = "http://127.0.0.1:1234/v1". A cloud setup swaps in default_model = "claude-cli/opus" and api_key = "${ANTHROPIC_API_KEY}" under [providers.anthropic]. Run localgpt paths to see how the XDG-compliant config, data, state and cache directories resolve on your machine.
Gen mode is a constrained scene DSL, not a general 3D agent
The feature list reads like an inventory of primitives rather than an open-ended generator. Parametric shapes cover box, sphere, cylinder, capsule, plane, torus, pyramid, tetrahedron, icosahedron and wedge. Materials are PBR with color, metalness, roughness, emissive, alpha and double-sided. Lighting is point, spot and directional with color and intensity. Behaviors are a fixed set: orbit, spin, bob, look_at, pulse, path_follow, bounce. Audio is ambient beds (wind, rain, forest, ocean, cave) plus spatial emitters. Export targets glTF/GLB, browser-viewable HTML and screenshots. This is a closed vocabulary, and that is a reasonable engineering choice. It means the model is choosing from a known set of operations rather than emitting arbitrary Bevy code, which is why headless batch runs can be scripted without a window. The cost is that anything outside that vocabulary presumably requires dropping into Rust. The README does not describe an escape hatch for custom components or shaders, so if your scene needs a shader effect or a physics constraint that is not in the behavior list, treat that as unsupported until you find documentation saying otherwise.
The security claims need reading against the platform
The assistant advertises what it calls defense-in-depth: a kernel-enforced sandbox using Landlock and seccomp on Linux and Seatbelt on macOS, HMAC-SHA256 signed policy files in a LocalGPT.md with tamper detection, prompt injection defenses described as marker stripping, pattern detection and content boundaries, and a hash-chained audit log of security events. The mechanism names are specific enough to be checkable, which is better than a vague claim. Two caveats follow from the material. First, the sandbox is described in terms of Linux and macOS kernel facilities, and the README does not state what happens on Windows; if you run the daemon there, verify the fallback before trusting the sandbox line. Second, prompt injection defenses that operate on markers and patterns are a filtering layer, not a proof. The signed policy file is the stronger primitive here, because tamper detection is a property you can reason about, while pattern detection is a moving target. The README points to website/docs/sandbox.md and website/docs/localgpt.md for detail, and those are the files to read before enabling the daemon with network-facing endpoints.
Where the documentation stops
The README links a full config reference at website/docs/configuration.md and a full API reference in the website docs, but the supplied material truncates mid-URL, so the endpoint table is only partly visible: GET / serves the embedded web UI, POST /api/chat handles a request, POST /api/chat/stream does SSE streaming, and GET /api/memory/search?q=<query> searches memory. There is no authentication scheme described for those endpoints in the material, which matters because the daemon is the component that would be reachable from other machines. The repository shows no retrieved releases, so there is no changelog or version history to read here, and no upgrade notes. The last push date is 2026-06-21, which tells you the project is active but not what changed. For a tool that writes to a markdown memory store and a SQLite index, the absence of a documented migration story is the practical risk: if the FTS5 schema or the workspace layout changes between versions, your existing MEMORY.md and knowledge/ directory are the things that have to survive. Verify that against the crate versions you actually install, not against main.
What to compare it against
For the assistant half, the natural comparison is a local model front end such as Open WebUI or a plain Ollama plus a chat client. The difference in approach is where state lives. Those tools keep conversations in a database behind a server; LocalGPT keeps long-term knowledge in MEMORY.md and knowledge/ inside a workspace you can open, edit and commit, with SQLite FTS5 and sqlite-vec as the index rather than the source of truth. If you want a shared team chat UI, the file-based model is the wrong shape. If you want memory you can diff and hand-edit, it is the right one. For the generation half, the comparison is writing Bevy code directly or using a glTF authoring tool. LocalGPT Gen's difference is the headless experiment queue: localgpt-gen headless --prompt with an optional --style hint lets you generate variations without a window, which is a batch workflow that neither hand-written Rust nor a GUI editor gives you. What you trade is control over the exact component graph. A Bevy developer writing the scene by hand gets anything Bevy can express; Gen gets the primitive list above.
Licence and the cost of keeping up
The project is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files and state significant changes. That is a permissive licence with an explicit patent grant, and it is compatible with shipping LocalGPT inside a closed product. It is not legal advice; read the LICENSE file in the repository for the terms that bind you. On maintenance, the honest position from this material is that you cannot estimate it. There are no retrieved releases, so there is no cadence to extrapolate from and no deprecation policy to read. The repository is a Rust workspace with two published crates, localgpt and localgpt-gen, installed independently, which means an upgrade can move them out of step if their versions diverge. The concrete thing to check before committing is whether the crates.io versions match the main branch behaviour you are reading about, because the README documents cargo run from a clone and cargo install from the registry as equivalent paths, and that equivalence is an assumption worth testing on your own machine rather than trusting.
Editorial conclusion
Adopt localgpt if you want a single Rust binary for a local chat assistant with a markdown memory store, or if you are building Bevy scenes and want prompts plus a headless batch mode to drive geometry, materials and lighting. Do not adopt it if you need a stable released version, a documented upgrade path, or a tool whose full configuration reference you can read without leaving the repository. Before installing, verify three things: the resolved paths from localgpt paths, the exact provider block you need in config.toml, and whether the crate versions on crates.io match the main branch you are reading.
Community notes