Hornet 0.19.0 is out, and it brings Hornet Coder to the release: a local-first desktop workspace for turning a coding mission into a reviewable project revision.

This is the sort of idea that shows up after a long night of games: coding assistants can write a lot of code, and someone still has to sort through the screwups. I wanted the work organized so I could see what changed, what was checked, and which version I could go back to. Sleep was apparently not the feature I chose to build.

Coder gives that work a home. It imports a project, builds a reviewable map, prepares a candidate revision for a mission, and keeps the evidence needed to inspect the result. You decide whether to accept the candidate. This is a walkthrough of the actual 0.19.0 workflow, including the parts that still need human judgment.

Release: Hornet 0.19.0 · PyPI · Source

What arrived in 0.19.0?

Hornet Coder, also called Mission Control, is a native desktop interface for project import, model-assisted project maps, coding missions, candidate revisions, and proposal review. This release also updates the existing CLI and registry. Chat, Tasks, and experimental conversational memory are not included in this release.

Coder's project revisions and mission records are stored locally. The project blueprint, selected source, mission and relevant outputs are sent to the model server you configure. A local-first workspace does not make a remote server local: choose the endpoint with that in mind.

1. Install and start Coder

You need Python 3.9 or newer with Tk support, and a compatible model server. LM Studio is one option. The server and model must support the structured JSON responses used for edit plans; a generic OpenAI-compatible label alone does not guarantee that. Coder's current interface does not send API keys, so an authenticated provider needs an additional connector or intermediary.

On Windows, in a new working directory:

py -3 -m venv .venv .\.venv\Scripts\python.exe -m pip install matrixswarm-hornet==0.19.0 .\.venv\Scripts\hornet-coder.exe

On Linux, install Python, venv and Tk support using your distribution's packages, then:

python3 -m venv .venv .venv/bin/python -m pip install matrixswarm-hornet==0.19.0 .venv/bin/hornet-coder

The signed GitHub release provides a wheel, signed checksum manifest and verification instructions if you prefer that route. Verify the signature and file hashes as described there. The release's starter ZIP is a separate walkthrough for the existing CLI and its worker VM.

Load your model and start the server before using model features. The default address is http://localhost:1234/v1; select the model exposed by your server. You can open Coder without a VM. Its optional test runner needs a separately configured VM; installing Coder does not create one.

2. Import a project

Choose New project or Import folder. For a first run, use a small project you understand. Review the import selection before continuing.

Hornet copies the selected files into its workspace and leaves your original folder alone. Hidden files, Git metadata, environments, caches and symbolic links are not importable. Other paths that often contain private data start unselected, but that is a heuristic, not secret detection. Check the list yourself, including any configuration your project needs.

The default project location is ~/.hornet/projects. It can contain source, prompts and model output, so back it up separately from the Hornet source repository.

3. Initialize and review the project map

Select the revision and model, then choose Initialize under Project setup. Review the selected files, the project blueprint and the destination server. Hornet sends included text files in bounded parts, one request at a time, and saves progress after each completed part. No source code is executed during initialization.

This can take time on a large project or a slow model. Activity shows the current file and part. If a model request fails, choose Initialize again to retry incomplete parts. If the underlying files have changed, Hornet starts a fresh draft so the map corresponds to the source it is describing.

Review the proposed blueprint, file summaries, excluded files and issues in Proposal. Choose Accept map when the included files are complete and the descriptions make sense. Hornet verifies source hashes and part coverage before creating an initialized revision.

The map is a useful orientation aid, not proof that the model understands every dependency. Python scans record declared imports and definitions; they do not resolve an entire dependency graph. Review the descriptions before accepting them.

4. Give Coder a mission

Select the accepted map revision, enter a focused task, and choose Run mission. For example:

In calculator.py, fix double(n) so it returns twice an integer. Preserve the function name and argument. Do not change the existing tests. Check the behavior for -3, 0, and 7 and report what changed.

Use a real file and requirements suited to your project. The example is deliberately small: it is easier to evaluate the workflow when you already know what a correct result looks like.

Coder sends the mission and project metadata to the model and asks it to select a bounded file scope. It then provides the selected file contents and relevant tool contracts. The file-tree selection does not restrict Run mission; that selection is used by Diagnose only. Review the revision and server before you run.

The desktop currently uses files.text.read and files.text.atomic_edit for its automated source work. Edits are checked against schemas, path scope and source hashes, rehearsed on a disposable copy, and checked again during execution with readback receipts. A candidate revision and a record of the proposal are created for review. Activity shows stages and receipts; the moving indicator means work is underway, not how much remains.

The model is instructed to follow the blueprint, but Hornet does not automatically prove arbitrary architectural rules. Mission limits include up to 20 planned paths, a 128 KB individual source-file limit and a 240 KB serialized-context limit. Large projects may need a narrower starting point.

5. Check the candidate

The optional VM check field starts empty. If it stays empty, automated checks are skipped. Run appropriate tests separately before accepting the result. With the separately configured test VM, you can supply a command; after a failed check Coder permits at most one scoped model repair. A failing check cannot be accepted through Accept mission.

The desktop VM runner requires a compatible host helper and a separately configured VM. It copies project files to a test directory in that VM, executes a command without a shell, and records output, exit status and source hashes. It does not provision the VM or install your dependencies. See the desktop guide for configuration and limits.

Read the Proposal: the actual changes, candidate revision, tool receipts and check results. Look at what the tests assert, not just whether they are green. A test that checks double(0) == 0 can pass even when double(n) returns n for everything. The test is pleased with itself. The function is still wrong.

When the result meets your requirements, choose Accept mission to make it the accepted default. A failed or malformed response does not change the accepted revision. Pending review can be reopened with Review pending; interrupted or failed records remain available for inspection and are not automatically replayed.

6. Branch, export, or diagnose

Each revision is a complete source copy with a recorded parent. Select an older initialized revision to branch from it without rewriting newer revisions. The colored dots and short IDs help show the relationship; use the IDs when colors look alike.

The Revision… menu and revision context menu let you name a revision, save a complete copy to a new folder, or move an eligible revision to recoverable project trash. Export does not overwrite an existing folder. Keep your workspace backup: revisions and records are project data, not a substitute for a backup strategy.

For an investigation without editing files, select a revision, enter a question and choose Diagnose only. You can select files and optionally include matching VM output. Hornet saves the report without creating a new revision. Treat the diagnosis as a lead to investigate.

Coder and the CLI

The desktop workspace and the existing Hornet CLI are related but separate workflows. Coder's revisions are not CLI goal directories. The CLI can organize coding goals into scoped cells with saved attempts, checks, questions and recovery evidence; its starter demonstrates a dedicated worker VM. Coder offers a visual project map and candidate-revision review. Pick the workflow that fits the job, and use the matching documentation.

The 0.19.0 release was installed and checked in a fresh Windows Python 3.13 environment, including a first-goal file-contract check. The earlier 0.15.0 live-model trial measured one small CLI task; it is not a general reliability benchmark or a Coder performance claim. See the release's validation record for the checks and limitations of the release itself.

The goal is practical: make model-assisted coding easier to inspect, keep revisions distinct, and leave the developer with evidence instead of a mystery. Try it on a small project, inspect the candidate, and tell us where the workflow helps or gets in your way.

🌐 Links & Resources