- Rust 95.9%
- JSON-with-Comments 1.7%
- Inno Setup 0.5%
- Shell 0.5%
- Tree-sitter Query 0.4%
- Other 0.7%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
| .blitz | ||
| .cargo | ||
| .config | ||
| assets | ||
| crates | ||
| docs | ||
| extensions | ||
| script | ||
| tooling | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .prettierrc | ||
| build_output.txt | ||
| Cargo.lock | ||
| Cargo.toml | ||
| LICENSE-AGPL | ||
| LICENSE-APACHE | ||
| LICENSE-GPL | ||
| README.md | ||
| run_editor_tests.sh | ||
| rust-toolchain.toml | ||
| rustfmt.toml | ||
| TODO_WORKGROUP.md | ||
| typos.toml | ||
🦊 Blitz
Code at the speed of an asynchronous fox!
Welcome to Blitz, a high-performance, multiplayer code editor built on work by the original Zed developers, who also created Atom and Tree-sitter.
Fork Credits
Blitz is a fork of Zed. This project builds on the excellent foundation created by the Zed team and community, and we gratefully acknowledge their original work.
Fork Direction
I forked Zed because I got tired of waiting around for the editor to feel fast and predictable when I run local models all day. Zed is still the upstream, but Blitz is now focused on one tight local-first AI runtime that stays out of my way.
The main change is how the conversation actually moves. I switched the whole thing to OpenAI-compatible Responses over a single websocket and made llama.cpp the main reference server. That gives one continuous stream through the entire turn instead of stopping and restarting after every tool call. The runtime can pick up right where it left off with response.create, output deltas, completed signals, and previous_response_id, so everything keeps flowing without resending the whole history.
After that I started removing stuff that was making the code more complicated than it needed to be. I dropped the big cloud-provider matrix and most of the other inference paths because they kept adding extra branches everywhere in request handling, event parsing, and settings. The changelog shows all the places I did a hard narrowing pass across the runtime, settings, docs, and tests. It is not as flashy as saying we support everything, but now the editor and the agent use exactly the same websocket language all the way through, which makes things a lot easier to follow and fix when things get busy.
I also cleaned up the agent side quite a bit. All the old ACP and external-agent code is gone. There is now one native thread runtime that handles the full conversation, tools, terminals, diffs, and checkpoints. Fewer pieces means fewer surprises when I am actually using it.
Right now I am adding two new layers that will live in a fresh blitz_runtime crate. The first is a sandbox that runs every tool and terminal through systemd-run --scope by default, using a bunch of properties for memory limits, cpu quota, network blocking, filesystem protection, and syscall filtering. I made bwrap an optional layer on top if someone wants tighter mount control, and there is also a pure-Rust Landlock fallback. You can switch the whole thing off, or set it globally, per-thread, or per-tool, and it works the same way over ssh to a remote machine that has systemd.
The second layer is an optional virtual filesystem that turns the agent experience into something where everything really is just files. Tools show up as writes to /tool/execute, terminal output lives at /term/42/out, llama calls sit under /api/llama, and the real project is mounted read-only at /project. The agent never has to deal with raw function calls or APIs anymore. It just reads and writes files, and every single operation still runs inside the same systemd sandbox. You can turn the virtual filesystem off with one setting if you prefer the normal style.
The indexing and context work follows the same smaller-and-clearer approach. I moved storage to appdata slots, tightened the hashing and snapshots, added proper Merkle incremental rebuilds, and made cancellation and progress solid so long jobs never feel scary. On the prompt side I added real controls for memory budgets and editable system prompts so context use is always intentional.
In the end Blitz does fewer things than the original, but it does them with less friction, continuous streaming, and the exact sandbox and file-only runtime (This is yet to be actually implemented) I always wanted when I am running local models all day.
Installation
On macOS, Linux, and Windows you can download Blitz directly or install Blitz via your local package manager (macOS/Linux/Windows).
Other platforms are not yet available:
- Web (tracking issue)
Developing Blitz
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/blitz-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/blitz-licenses.toml, as specified in the cargo-about book.