For example, Info-ZIP unzip prints file names as it extract them from an archive. This printout dominates extraction time of archives with many small files. Sometimes I run unzip without options, then my terminal floods with file names and I know that my extraction is bottlenecked. So I cancel and restart with -q (quiet) to avoid the bottleneck, because it’s faster to start over than wait. Conscious of this experience, I avoided the problem in tugz unzip without changing the user interface. You get a listing but you don’t have to pay for it.

$ unzip example.zip
Archive:  example.zip
  inflating: example.bmp
  inflating: example.svg
  inflating: example.txt

Consider this C program that prints three lines:

#include <stdio.h>

int main()
{
    puts("a\nb");
    puts("c");
}

If we examine the writes with, say, strace:

$ strace -o log -e write ./a.out
a
b
c

We might see (here glibc):

write(1, "a\n", 2)                      = 2
write(1, "b\n", 2)                      = 2
write(1, "c\n", 2)                      = 2

Yes, glibc takes line buffering quite literally, even splitting writes on a string. Some implementations are a little more sophisticated:

write(1, "a\nb\n", 2)                   = 4
write(1, "c\n", 2)                      = 2

CPython makes exactly those writes for this program:

import sys

sys.stdout.write("a\nb\n")
sys.stdout.write("c\n")

Its rule is to flush if its buffer contains a newline after appending the new output, with the consequence of possibly outputting partial lines. Building on the previous example:

enum {
    BUF_ERR  = 1 << 0,
    BUF_LINE = 1 << 1,
};

typedef struct {
    uint8_t  *buf;
    ptrdiff_t cap;
    ptrdiff_t len;
    int       fd;
    int       flags;
} Buf;

bool os_write(int fd, void *, ptrdiff_t);

void flush(Buf *b)
{
    if (!(b->flags & BUF_ERR) && b->len) {
        if (!os_write(b->fd, b->buf, b->len)) {
            b->flags |= BUF_ERR;
        }
        b->len = 0;
    }
}

Such line buffering might be achieved with a test-then-flush:

bool has_newline(Buf *b)
{
    int r = 0;
    for (ptrdiff_t i = 0; i < b->len; i++) {
        r |= b->buf[i] == '\n';
    }
    return r;
}

void append(Buf *b, uint8_t *src, ptrdiff_t len)
{
    uint8_t *end = src + len;

    while (!(b->flags & BUF_ERR) && src<end) {
        ptrdiff_t left   = end - src;
        ptrdiff_t avail  = b->cap - b->len;
        ptrdiff_t amount = avail<left ? avail : left;

        memcpy(b->buf+b->len, src, amount);
        b->len += amount;
        src += amount;

        if (amount < left) {
            flush(b);  // make room
        }
    }

    // test-then-flush if line buffered
    if ((b->flags & BUF_LINE) && has_newline(b)) {
        flush(b);
    }
}

If we’ve got a bunch of lines to print and append them one after another into the buffer, that’s a lot of writes which could have been one.

Eat all the cake

Let’s think about our goal: If the output is a terminal then we don’t want to hold back lines indefinitely. That’s not the same as a write on every newline. There’s already a solution for the problem where we’re in a hurry to send out data, but the underlying, buffer-oblivious caller makes lots of small writes: Nagle’s algorithm.

That is, flush the buffer if it’s been idle a short time. We don’t actually care about newlines in particular. The catch is that it requires tweaking the interface. Add a deadline to the buffer:

typedef struct {
    int64_t   deadline;
    // ...
} Buf;

int64_t os_monotonic_clock();

void deadline_flush(Buf *b)
{
    if ((b->flags & BUF_LINE) && b->len) {
        int64_t now = os_monotonic_clock();
        if (b->deadline && now>b->deadline) {
            flush(b);
            b->deadline = 0;
        } else {
            b->deadline = now + DEADLINE;
        }
    }
}

Where DEADLINE is something appropriate for human perception, like 100ms or so. We could poke this concurrently in a thread, awoken via futex when data is written to the buffer. But better to poke it between short stints of work, which is how tugz works. For example (using my strings):

    for (/* filename in filenames */) {
        Str pre = S("  inflating: ");
        Str suf = S("\n");
        append(&stdout, pre.data, pre.len);
        append(&stdout, filename.data, filename.len);
        append(&stdout, suf.data, suf.len);

        while (/* not done inflating */) {
            // 1. inflate block
            // 2. write block
            deadline_flush(&stdout);
        }
    }

If it processes multiple files within the deadline, their names write out together. No threads. The behavior difference compared to traditional flush-on-newlines is imperceptible to a humans, aside from the fact their program runs faster. One more reason not to bother with crummy C stdio.

Dark mode aficionados are covered, too:

Note that Prospero comes with no model providers built-in. You’re expected to supply that yourself, such as with llama.cpp, a workplace on-prem model, OpenRouter, Anthropic API, OpenAI API, etc. (You can’t use your Claude subscription.)

For those unfamiliar with coding harnesses: In a chat interface you and the AI take turns writing messages to each other. A coding harness extends this concept, allowing an AI to “talk” to tools offered by the harness. Tools “reply” with their outputs. A tool might read or write a file, or run a shell command. An AI will go from tool call to tool call on its own, looping on the results. Such an AI is called an agent. Occasionally the AI will send you a message to inform you of progress or to ask a question, and the chat interface is still there.

Some harnesses, including Prospero, allow agents to spawn subagents to do their bidding, to work in parallel or keep their context clean. That is, to not fill their working memory with subtasks. Agents can message one another and coordinate on tasks. Given SSH access to another machine, or over plain WSL, Prospero can deploy a headless copy of itself to other hosts so that agents can operate on those systems. The Professional Edition embeds engines for combinations of x86/x86-64 and ARM64 on macOS, Windows, and Linux. The Windows x86 engine even works on Windows XP, and can play solitaire and minesweeper if you ask.

The last is because Prospero is one of the few harnesses with desktop control capabilities. If your model supports vision — any any model worth using does — then it can “see” your desktop and interact with it. It can click, type, and drag to test and debug GUI applications live without a specialized, per-app MCP assist.

This headless engine is why no TUI is necessary. The harness engine runs on the headless system, and the UI runs on your desktop or laptop. With a little extra setup, the harness to run fully independently of the GUI, so that it will continue without the GUI system attached — re-attachable later.

Because Prospero is so lean, it may be the only harness that can drive a fuzz campaign, particularly on a headless system, without the Linux OOM killer targeting the memory-gobbling harness rather than the out-of-control fuzz target that triggered it. So many times I’ve checked back in on a fuzz campaign hours later, to find nothing was accomplished because the harness process is gone.

(Why have an agent run a fuzz campaign? Because it can fix discovered bugs on the fly and keep the campaign going! It’s a no brainer.)

Configuration

The configuration lives at ~/.config/prospero/prospero.ini. Easy to edit. No JSON, thank goodness. Check it into source control, copy-paste it. All the usual benefits. Alternatively, the Settings page can reach every setting from the GUI, so you don’t have to edit the INI by hand. INI files can also include each other, not just naming file system paths but URLs:

include = https://example.com/prospero.ini

The idea is to allow a live shared or managed configuration. Includes by URL are restricted in what they can set, with a hard rule against anything which might appear in shell command. Some trust is still required, as a configuration can extract an environment variable by using it as an API key and supplying an endpoint it controls.

Prospero fetches a model list and other parameters like context size from the endpoint, but you might want to tweak it. A typical configuration may look like:

model = falstaff/Qwen3.8-27B

[endpoint falstaff]
url = http://falstaff.local/
key = env:FALSTAFF_API_KEY

[model Qwen3.8-27B]
edit_format = replace
template.reasoning_effort = medium

[model Qwen3.8-27B-xhigh]
like = Qwen3.8-27B
template.reasoning_effort = xhigh

[web]
search = searxng
url = https://search.example.com/
key = env:EXAMPLE_API_KEY

Passive rendering

The ImGui paradigm typically uses active rendering, redrawing on vsync like a video game. This is appropriate in some contexts, like interfaces within video games. Less so for mostly-static text-oriented UIs, such as a coding harness. Instead Prospero uses passive rendering with settle frames to finish animations before going idle. When there’s nothing to do, Prospero does nothing. It won’t chew on the GPU while the agent is waiting on a build.

Never wait forever

An annoyance with most other harnesses is how easily they get stuck. I set a long-running task, go to sleep, and in the morning find the harness hung on a trivial issue two hours into the night, wasting the rest. Therefore Prospero prime design principle: Never wait forever. Every operation has a deadline. This decision influences everything. If you’re not there to grant a requested permission, the agent will get a denial by timeout and must do without. To assist, Prospero will raise a system toast when an agent requires your attention so that you’re less likely to miss it if you’re attending.

The harness itself plows through intermittent errors, trying its best to drive the agent to complete its task. All network requests have timeouts, and watchdogs prevent endless waiting. Agent mailboxes are bounded.

Shell commands that hit their timeout convert to asynchronous background commands. The agent can continue to wait on them, with a timeout, and so will be woken at regular intervals to decide if it should continue.

The one exception is Plan mode, where it waits indefinitely after offering a plan or requesting clarification (ask_user tool). It’s expected that a user is attending to the agent during Plan mode.

No stray processes

The harnesses I’ve used have improved, but another regular annoyance earlier this year was agents starting processes that never get cleaned up. An agent kicks off a parallel build, hits a timeout because it was too optimistic, the build “stops” by killing a piece of the build system. But actually the build continues anyway, at least in part. The agent tries again, and now two builds are going, interfering with each other, making a mess and bringing my system to its knees.

For awhile I was wary of letting agents run builds in certain harnesses, which is a terrible outcome. You want agents to close the loop and iterate independently. A human in the loop is like putting a ball and chain on the agent, giving up most of its advantages.

Prospero promoting a synchronous timeout to an asynchronous task is a huge improvement on its own, but there’s an additional principle at play: The whole process tree lives and dies together. When a command is stopped, it stops. This is trivial on Windows, though few harnesses seem to take advantage of it. It’s more difficult on macOS and Linux, but Prospero follows through.

Built-in self-help

Like every harness, Prospero supports skills, a pre-packaged set of instructions on how to accomplish some task (“I know kung fu.”). Prospero contains a skill on itself and can read its built-in documentation. Ask the agent how to do or configure something in Prospero, and the agent can only answers your question, it can provide a hyperlink taking you to the relevant place in the UI. It can also edit your prospero.ini and reload it, to configure things on your behalf. This is not unique to Prospero, but I’m not aware of any harness doing this nearly as well.

Choose your shell

On Windows, Prospero is designed to work well with w64devkit, and will prefer its shell if available. Models designed for coding know w64devkit out-of-the-box, so these tools are complementary. Of course you’re not locked into that shell, and you can freely choose a different default shell. But Prospero is a rare harness where you can change shells mid session. Sometimes PowerShell is more suited to the task, so you can pick it out of the dropdown. The agent is informed of the change, and told about known quirks (i.e. “this is an old Bash!”). On macOS you can switch between bash and zsh.

The usual features

Prospero has the usual sorts of features you can expect from an advanced shell. It can use Git worktrees, including subagent worktrees, so that agents can share a repository. It speaks the Model Context Protocol (MCP). It can search the web (if you allow). You can start side chats that share context, realized as subagents. You can fork sessions.

For now there is no built-in terminal or editor. Instead Prospero will open an external terminal or editor of your choosing. I’d rather use Vim than a built-in notepad.exe-equivalent. With Ctrl+G you can edit your prompt in an external editor.

Like all harnesses, the permissions system will not stop a malicious agent. Agents are writing and running programs on your computer, and so can ultimately access everything the harness can access. Permissions are about gently reminding the agent of your wishes, and catching simple mistakes. More like, “Whoa there, stay within the project” or, “Do not control my desktop at this time.” If you want to lock an agent out, you have to restrict the harness itself, putting it in a container or on a Raspberry Pi, at the usual cost of inconvenience or cutting off useful resources.

Community Edition versus Professional

I’m really excited about Prospero, and I honestly feel it’s one of the best coding harnesses available. It’s how such tools ought to be built, but until now nobody else stepped up to do it. It would take a video to do it justice, and maybe I’ll do that sometime, but that’s currently outside my experience.

Most of the audience for my projects are hobbyists, even w64devkit. But if Prospero goes beyond me and my little circle, I expect most users would be professionals building commercial products. I’ve also invested more than just my time into this project — already true for w64devkit, even more true with Prospero. So while it’s an open source project, I’ve split it into two tiers:

• Community Edition: the build you find on GitHub at no cost. It has no built-in headless engines, so remote deployments are limited. Plus a little nag text to remind you you’re on the Community Edition. Suited for hobbyists.

• Professional Edition: Pay a nominal fee, get a DRM-free download with free updates. All the headless engines are built in so you can push remote deployments and remote sessions on other systems at the press of a button. A serious feature for professionals.

Windows and macOS builds are code-signed in both cases (some of the cost). If Prospero is useful for you professionally, even without the remote deployment feature, you’re still encouraged to buy a copy to support my ongoing costs!

Let’s begin with the simplest case: An integer hash set, no deletions, only one insert thread (single producer), and consumers do not care about insert order. That is, the producer inserts A then B, but consumers may observe B in the table before A. Suppose this is the hash table in the single-threaded case:

int32_t *lookup(int32_t key, int32_t *table, int exp)
{
    uint64_t hash = ((uint64_t)key * 1111111111111111111u) >> 32;
    uint32_t mask = ((uint32_t)1 << exp) - 1;
    uint32_t step = (hash >> (32 - exp)) | 1;
    for (uint32_t index = hash;;) {
        index = (index + step) & mask;
        if (!table[index] || table[index]==key) {
            return table + index;
        }
    }
}

Keys must be non-zero, and tables are zero-initialized. Usage example:

    // Initialization
    enum { exp = 8 };
    int32_t table[1<<8] = {};

    // Producer
    for (int i = 0; i < nkeys; i++) {
        *lookup(keys[i], table, exp) = keys[i];
    }

    // Consumer
    int32_t key = 1234;
    bool present = *lookup(key, table, exp);

The only problem is the data race on table slots. Since consumers can tolerate out-of-order insertions, ordering does not matter and relaxed atomics eliminate the data race. Insert and query now have different requirements, so it makes sense to distinguish them. Starting with the latter:

bool contains(int32_t key, int32_t *table, int exp)
{
    uint64_t hash = ((uint64_t)key * 1111111111111111111u) >> 32;
    uint32_t mask = ((uint32_t)1 << exp) - 1;
    uint32_t step = (hash >> (32 - exp)) | 1;
    for (uint32_t index = hash;;) {
        index = (index + step) & mask;
        int32_t k = __atomic_load_n(table+index, __ATOMIC_RELAXED);
        if (!k) {
            return false;
        } else if (k == key) {
            return true;
        }
    }
}

Note how all elements are accessed by atomic loads, as a producer may store to any slot at any time. Now producers:

bool insert(int32_t key, int32_t *table, int exp)
{
    uint64_t hash = ((uint64_t)key * 1111111111111111111u) >> 32;
    uint32_t mask = ((uint32_t)1 << exp) - 1;
    uint32_t step = (hash >> (32 - exp)) | 1;
    for (uint32_t index = hash;;) {
        index = (index + step) & mask;
        if (!table[index]) {
            __atomic_store_n(table+index, key, __ATOMIC_RELAXED);
            return true;
        } else if (table[index] == key) {
            return false;
        }
    }
}

This function may load elements non-atomically because there’s only one producer: the current thread. This idea could not be expressed were the type system involved, e.g. _Atomic, but GCC atomics do not involve require such special qualifiers. Stores on the other hand are concurrent with consumers, requiring an atomic store. Single-producer, multiple-consumer (SPMC) usage is nearly identical to the single-threaded case:

    // Producer
    for (int i = 0; i < nkeys; i++) {
        insert(keys[i], table, exp);
    }

    // Consumer
    int32_t key = 1234;
    bool present = contains(key, table, exp);

A concurrent integer hash table is contrived and unrealistic. In a real program a key likely carries some broader semantic meaning. For example, if that “integer” is actually a memory offset known as a pointer, then it points at some object, and it is important that stores to that object happen before consumers observe the pointer in the table:

bool   insert(Thing *thing, Thing **table, int exp)
Thing *lookup(Key key, Thing **table, int exp)

Where usage might look like:

    // Producer
    for (int i = 0; i < nthings; i++) {
        things[i].key = ...;  // update/init object
        insert(things+i, table, exp);
    }

    // Consumer
    bool present = !!find((Key){...}, table, exp);

In this case relaxed atomics are insufficient. Updates to the inserted object may be reordered after the insertion, and consumers will race on those updates. In this case we upgrade to acquire-release:

Thing *lookup(Key key, Thing **table, int exp)
{
    // ...
    for (...) {
        // ...
        Thing *thing = __atomic_load_n(table+index, __ATOMIC_ACQUIRE);
        if (!thing || thing->key==key) {
            return thing;
        }
    }
}

bool insert(Thing *thing, Thing **table, int exp)
{
    // ...
    for (...) {
        // ...
        if (!table[index]) {
            __atomic_store_n(table+index, thing, __ATOMIC_RELEASE);
            return true;
        } else if (table[index]->key == thing->key) {
            return false;
        }
    }
}

In this case producer and consumer synchronize on the atomics. Producer stores are ordered before the release, and consumer loads are ordered after the acquire. Objects are not modified once in the table, so atomics are not required for their fields. On some architectures, including x86, there will be no indication at the ISA level that atomics are in use — i.e. this likely generates the same code as the single-threaded version — and these atomics merely constrain the compiler’s instruction scheduling.

As a side effect of synchronizing, consumers will now observe insertions in the same order as the producer. This is a more realistic and practical situation than an integer hash table.

Multiple producers

The multiple-producer case (MPMC) is more complicated for producers, but consumers are unaffected, so we need only modify insertion. Still without any locks, we will optimistically update the table. We look at the current slot item, and if nothing is present compare-and-swap the new element in place. On failure we acquire the element that won the race, continuing as though it’s what we saw in the first place.

bool insert(Thing *thing, Thing **table, int exp)
{
    // ...
    for (...) {
        // ...
        Thing *current = __atomic_load_n(table+index, __ATOMIC_ACQUIRE);
        if (!current) {
            int pass = __ATOMIC_RELEASE;
            int fail = __ATOMIC_ACQUIRE;
            if (__atomic_compare_exchange_n(
                    table+index, &current, thing, 0, pass, fail)) {
                return true;
            }
        }
        if (current->key == thing->key) {
            return false;
        }
    }
}

This is quite similar my hash trie concurrency enhancement a few years ago.