On August 1, 2026, Zaguán Blade reaches v1.0.0.

That version number matters to me—not because it means the work is finished, but because it marks the point at which the product has become what I set out to make: a code editor and AI coding environment I genuinely want to use every day.

It is not perfect. There are bugs to fix, rough edges to smooth out, and features I still want to build. But it is useful, capable, and dependable enough to be my daily driver. That has always been the first goal.

And getting here has taken more than one attempt.

Before Zaguán Blade, there were five false starts

I started the work that eventually became Zaguán Blade in December 2025. I knew I wanted to explore AI-assisted development, but I did not yet know what the right form would be.

My first five attempts were discarded. None of them felt right. Some were too close to existing tools; others did not give me the foundation I needed to make the product feel like my own. Scrapping them was frustrating, but it was also necessary. Each failed direction made the next one clearer.

The turning point was finding Rust and Tauri.

That combination made the project feel possible. Rust gave me a strong foundation for the parts that need to be reliable: local files, terminal processes, Git state, project indexing, durable history, and the asynchronous coordination that an AI coding workflow demands. Tauri made it possible to pair that backend with a fast, focused desktop interface without adopting the full weight and architecture of a browser-based general-purpose IDE.

That was when I stopped looking for an idea and started building Zaguán Blade.

Why build another editor at all?

Part of the answer came from using Windsurf, itself a fork of VS Code.

I realised that I was not using 80 or 90 percent of its power features. They are valuable features for the people who need them, but they are not the reason I open the editor every day. The workflow I care about is much smaller and more direct: open a project, understand the code, work with an AI collaborator, inspect the changes, run the right commands, and keep moving.

That raises a simple question: what if an AI coding tool does not begin as a large general-purpose editor with an assistant added on the side? What if it is a lightweight GUI application deliberately shaped around the workflow I actually use?

Zaguán Blade is my answer to that question.

The goal is not to recreate every feature of VS Code. It is to build a calmer, more intentional tool for working with code and AI—one with a responsive editor, a proper terminal and Git workflow, real diffs, useful project context, and an assistant that can help without becoming an opaque black box.

The system existed before the name

Long before Blade, I had begun another project to explore agentic work. I called it zcoderd.

Over time, that project has become the heart of this system. Today, the name stands for Zaguán Coder Daemon.

zcoderd is the coordination layer: it manages AI sessions, works with model providers, keeps track of context, chooses and routes tools, and helps a task continue after local results come back. Blade is the local, visible side of the relationship: it has access to the project, files, terminal, editor state, and the user interface.

That split is one of the product’s most important ideas. The daemon can reason about the task; Blade can perform local actions and make them visible. Intelligence and execution collaborate, rather than being forced into one monolithic editor process.

I also noticed a practical problem in the tools I was using. Whenever Windsurf wanted to add a model, it had to ship a new application release for users to download. That seemed unnecessarily slow and limiting. A centrally managed model catalogue would let the available models evolve without requiring every user to update their desktop application first.

That thought has grown into something much bigger: a connected system in which Blade is the frontend, zcoderd is the orchestration layer, and model capability can evolve independently of the local application. The result is more than a GUI around a model. It is one coherent workflow.

The road from v0.1.0 to v1.0.0

The public journey began with v0.1.0 on February 4, 2026. It was the first release of Zaguán Blade—and, appropriately, a beginning rather than a declaration of completion.

What followed was a rapid series of releases. Looking back through the changelog, the work falls into a few chapters.

February: making an actual editor

The earliest releases established the essentials: an editor, screenshots and image attachments, PDF viewing, a native terminal, complete Git integration, and the first review loop for AI changes.

They also exposed the unglamorous work behind an AI editor. Chat ordering has to be correct. Tool calls have to appear where they belong. Diffs have to stay accurate. Terminal output has to survive real shells and real characters. By v0.3.0, the alpha label was removed and the application had been redesigned into something calmer and more usable.

March: context becomes central

March brought a major chat rewrite, Code and Planning modes, themes, and local-model support. More importantly, v0.5.0 introduced semantic code search and made the symbol_* tools central to how models understand a project.

That is an important change in direction. Good AI coding is not only about choosing a capable model; it is about giving that model the right information, at the right time, without drowning it in noise.

April and May: integration and daily use

The next releases deepened the foundations: better diff review, more reliable model communication, WebSocket-based history and language-protocol work, and a steady stream of fixes for streaming, terminals, file state, Git, and the editor.

Blade has increasingly become the environment I want to use myself. The chat was rebuilt and refined; CodeMirror became faster; and the terminal, project explorer, shutdown flow, themes, translations, and Git workflow received the attention that turns a feature list into a working tool.

June: memory, skills, and indexing

v0.8.0 introduced Fast Context: a more efficient way to give a model an initial picture of a project. The releases that followed added AGENTS.md support, local skills, Cognitive Interrupt, Zaguán Dimension Memory, conversation summarisation, and large gains in project-indexing performance.

The Symbols Index became dramatically faster—up to 20–30x faster in one release—and increasingly useful as a structured map of a codebase rather than a static list of files. This period reinforced a lesson I have learned repeatedly: reliability work is product work.

July: hardening for sustained use

The releases leading into 1.0 focused on making the system faster, leaner, and more trustworthy when conversations grow, projects get larger, and models differ.

The Symbols Index gained stronger cross-file resolution and multicore indexing. Conversation loading, streaming, Markdown rendering, history storage, startup, and long-chat performance all improved. zcoderd gained a more mature Skills system, model-aware orchestration, safer routing, and stronger recovery from large tool outputs.

The pattern is clear in the changelog: this is not a march toward a shiny demo. It is a march toward a tool that keeps working while the user gets on with the job.

What Blade is at 1.0

At 1.0, the defining idea is straightforward: Blade gives the model a structured map of the project before it reads code. The Symbols Index, targeted file-range reads, project memory, skills, and zcoderd’s orchestration work together so the model can locate relevant evidence quickly, make a scoped change, and leave the user in control of the result.

That is the product a new user can download starting tomorrow: not a general-purpose IDE with a chat panel added to it, but an AI-native coding workflow designed to stay grounded in the actual project.

A personal milestone, too

This project has changed me not only professionally, but personally.

I have an avoidant personality disorder diagnosis, and the fear of rejection and judgment has often been very real. Releasing the first version was difficult. Putting something I had built in front of other people meant accepting that it could be judged, misunderstood, or rejected.

But every release makes the next one easier.

With every bug fixed, every feature completed, every piece of feedback absorbed, and every version shipped, my confidence grows. So does my passion for the work. I have come to trust the process more: build something honest, release it, learn from it, improve it, and release again.

That is why v1.0.0 means more to me than a release milestone. It is evidence that I keep going.

v1.0.0 is a beginning, not a finish line

Calling a release 1.0.0 can imply perfection. I do not want to pretend that is what this is.

There are still bugs to fix. There are features planned. There are parts of the system I want to make faster, clearer, safer, and more powerful. There will be releases after this one because the work and the learning continue.

But Zaguán Blade has passed the test that matters most to me: it is a product I want to use daily.

It is a lightweight, Rust- and Tauri-based AI coding environment built around a specific conviction: the editor, the local workspace, the terminal, Git, project context, model orchestration, and human review should form one understandable workflow.

v1.0.0 is the first stable chapter of that idea.

Thank you to everyone who has tried Blade, reported issues, shared feedback, read the release notes, or simply followed along while this project finds its shape.

The journey has been interesting. The work has been hard. And honestly, this is just the beginning.