Version 0.4.0 in the manifest, date stamps in the tags

Version 0.4.0 in the manifest, date stamps in the tags

The manifest declares version 0.4.0. The releases are named with dates instead, a tag carrying a year, a month, a day and a sequence number. The newest is `v2025.09.27-01`.

Two numbering schemes, one project, and no statement anywhere explaining which one is authoritative. A dependency or a bug report that says 0.4.0 cannot be matched against a release page that says nothing of the sort.

The documentation makes it worse by one year. The developer notes explain that to cut a build for others, tag the main branch with something in the shape of a later-year tag, and the three releases that actually exist are all from the year before. So the instructions to the maintainer, the tags on the repository and the version in the manifest are three different strings, and only two of them match anything real.

A directory named after an IP address sits in the repository

The top-level listing contains an entry that is not a source directory, a document or an asset. It is named after a login and an address, with an at sign and a dotted-quad in the directory name.

That is the shape of an scp or copy destination with the colon left off, so a tool created a folder from the string rather than copying anything into it. It is committed, and it carries an internal network address belonging to whoever made the mistake.

Two other directories point the same way. A temporary directory is tracked rather than ignored, and a directory of test simulation data sits beside an evaluation script, an evaluations directory and a directory of evaluation results. None of that is mentioned in the README, which documents the feature flags and the cross-compilation and says nothing about how the project is measured.

For a repository whose whole premise is drawing on someone else's hardware, having someone else's address committed in it is the sort of thing worth cleaning up before you fork.

The install path reaches the tablet as root

Getting the binary onto the device is four commands from your laptop: download the release artefact with wget, using one of two file names depending on the tablet model, then copy it to the device with scp, then mark it executable over ssh and run its help output.

scp ghostwriter [email protected]:

The copy target is a root login at a hard-coded example address, so the whole documented workflow assumes ssh access as root on the tablet and manual addressing of the device on the local network.

Credentials are handled the same way. The setup section exports one or more provider keys in the tablet's own shell startup file, which means the keys live in plain text in a dotfile on the device and are inherited by every shell the agent starts.

Running it in the background is a single nohup invocation, and the next line of the documentation is an unresolved note about how to run it on boot. There is no service file, so the process does not survive a reboot without work.

Two HTTP clients and a web framework nobody mentions

The dependency list is the best description of how the program works, and it contains some surprises. Two HTTP clients are present, a blocking one and an asynchronous one with TLS provided by a pure-Rust stack. Nothing in the README explains why both are needed.

A web server framework is in the list too, at a version whose line has never left pre-release. The README describes a terminal program on an e-ink tablet with no web interface at all, so whatever that framework serves is undocumented.

The rest is legible and interesting. An input-events library with async support is how the pen and finger are read. A vector graphics rasteriser, a library that converts SVG geometry into polylines, an image processing crate and a byte-order helper together form the pipeline that turns a model's drawing into individual dots on the screen. One crate embeds assets into the binary with compression, and two more provide layered configuration from files and environment variables.

The manifest also builds a second binary named after an experiment, alongside the main one.

The linter is listed as a library dependency

The development dependencies are four entries, and one of them cannot work the way it is written.

clippy = "0.0.302"

Clippy is a component of the Rust toolchain, installed through the toolchain manager rather than fetched as a crate. The version number given here is the pattern the toolchain uses for its own releases, which is a strong sign that a tool version was pasted into the dependency list by mistake.

The release profile is the other place to look. Every option is present and every one is commented out, including symbol stripping and size optimisation, with an automatic note above them. So the release profile is the default profile, and a binary being pushed to a tablet over a network connection is built without the size reductions the file was set up to allow.

The rest of the development section is careful, in contrast: two architectures, two toolchain targets, a cross-compilation tool installed from its git repository rather than from the registry, and a wrapper script that takes the tablet model as an argument.

Two flags only do something on one engine

The option list is long and mostly self-explanatory. Two entries are not, because they are named after a vendor's feature rather than a capability.

The flag that enables model thinking and the flag that enables web search are both described as Anthropic features. The engine is auto-detected from the model name across three providers, so passing either flag while running an OpenAI or Google model selects a capability that engine does not have. No warning is described for that case.

The rest of the list is a testing surface, and a good one. The pipeline can be taken apart stage by stage: skip drawing the output, skip submitting to the model, disable the touch trigger, and disable the two output tools individually, one for vector drawing and one for text. Input can come from a PNG file instead of a live screenshot of the screen, and the screenshot, the rendered bitmap and the final output can each be written to a file.

There is also a segmentation switch for spatial awareness, which is the only option in the list with an experimental label attached to what it does rather than to the program.

The journal admits the drawing path is a workaround

The status section is the most valuable part of the README, and its first entry is dated in October 2024 with the tone of someone reporting to themselves. Drawing back onto the screen does not work well: the model's vector output is rasterised and then replayed as a large number of individual dots, and when a filled region covers the screen the tablet's refresh behaviour goes wrong, the display flips out, and the drawing does not complete.

What did work at least once is listed under it, and it is a short list: filling in a maths answer, and drawing a simple line-art picture of a dog.

Later entries add a touch trigger with a status marker drawn on the page, a virtual keyboard the author found surprisingly limited to one large text area per page with basic formatting, a text-assist mode that answers through that keyboard, and a release pipeline. The last visible entry is a refactoring note that stops mid-sentence.

So the journal ends in 2024 while the tags run into 2025 and the last push is later still. The most useful record of this project stopped being written about a year before the releases did.

Editorial conclusion

Treat it as the experiment its author calls it, and read the journal before the feature list, because the drawing path is the fragile part and the author says so. Two things to check in your own checkout: the committed directory named after an IP address, which looks like an accidental artifact, and the release naming, since the manifest version and the tag series have nothing to do with each other and the README's tagging example is a year off from the tags that exist.

Frequently asked questions

Official sources

1. awwaiid/ghostwriter on GitHub
2. Issues
3. License: MIT
4. README
5. Releases