badlogic

/settings > tui > regular

it's still there and won't get removed.

Multiple answers. Windows Terminal users constantly had problems because WT is ... not great. Fullscreen mode fixes that. This also applies to some other lesser used terminals.

I wanted the out of the box experience to be smoother for more people, so made it the default. Scrollback mode will stay though for users who prefer it.

scrolback buffer mode is definitely not going away.

The requestId is an imdempotency key, which is exactly how you get exactly once semantics.

I do not see any resemblence to Gastown at all? Pi Durable is a library for writing durable agents. You can plug in any sandbox solution you like (aka execution environment in Pi Durable speak).

Within a session, you can give each conversation its own sandbox, based on your application's needs and policies.

Oh, the tree is still there. It's just flatter :)

In Pinthe coding agent, each transcript entry is parented to another entry. That was actually exceptionally dumb.

If you do /tree in pi, pi needs to flatten that tree into linear, nested conversations.

In Pi Durable, we corrected this mistake. A conversation is a chronological, immutable list of entries. A conversation can be parented to an entry in another conversation, and thus inherits that parent's older conversation entries starting from that entry.

So, exactly the same functionality, just less dumb.

You can already (sort of, kind of) do that via a task (please excuse the agent slop, it's midnight and it's been a long day):

``` const SyncToPostgres = defineTask<{ entryId: string }, { phase: "send" }, void>({ kind: "app.sync-postgres", version: 1, initial: () => ({ phase: "send" }), phases: { send: async (task, runtime, context) => { const entry = await runtime.read(/* the entry */); await postgres.upsert("messages", { id: task.input.entryId, ...entry }); // idempotent by id await runtime.commit(() => ({ status: "terminal", outcome: { status: "completed" } }), context); }, }, });

   await root.commit(async (tx) => {
      const id = await tx.entry(AssistantEntry, answer);
      await tx.createTask(SyncToPostgres, { entryId: id }, { ownership: { kind: "conversation" },
 background: true });
   }, context);

```

The commit on the root conversation picks out the last agent answer id from the transcript, and durably schedules a task that then syncs it to postgres. inside the task, you fetch the answer by id and send it over to postgres indempotently.

What's missing here is sugar, basically a hook that runs inside each commit so the outbox write is atomic with the state change, with ordered delivery, and possibly a durable change feed with cursors.

Thanks for the input!

Things are still not settled, and while the API looks like store i/o it's actually more similar to Immer's drafts, just with a different encoding, as JSON patch can't deal with the kinds of data we encounter in our workloads, at least not in a way that keeps memory and perf within some bounds.

The good thing is that this more low level API can be easily papered over with a nice sugary thing.

Cheers, appreciate the answer!

I've read this a bunch of times around socials now these past days and I'd really like to understand what exactly indicates that the minimal agent TUI days are numbered for Pi?

I did not read this when I added support for AGENTS.md, skills, llama.cpp, extensions, alt TUI mode, mid-convo system messages and tool set changes to preserve KV cache, image model support, and everything else I added since November last year.

Codemode and MCP support are the latest additions. We follow what the models are trained on. E.g. the GPT family of models is actually trained on codemode for parallel tool calls now. The MCP spec has gotten a major update recently that makes it much less bad than it used to be in the past 24 months. Combined with codemode, it is now passable, so it got added to pi.

All of these features are still entirely optional and the only thing I could think of that could be considered "bloat" is the additional few megabytes for the QuickJS WASM blob.

So, I mean this in earenst and absolutely not combative: could you explain what exactly flips the switch between "pi is minimal" and "pi is not minimal"?

pi has /tree, which is basically the same, except in the same session.

ah. you can also ask pi to write a ui plugin for you. internals haven't migrated to plugin architecture yet tho.

pi also happily shows and stores deepseek CoT traces.

just read the paper, and there aee definitely some interesting ideas in it.

a plugin's registrations returning individual cleanup handlers is nice. in pi, you clean up all registrations in one go in the session-shutdown handler.

i also like the use of generator to to clean up partial registrations nicely.

the cross-plugin dependency injection and resolution i'm not so sure about. it comes with a lot of footguns and limitations as pointed out in the paper.

works ok within a single compilation unit, i.e. a plugin with many modules. does not help with typing of cross-plugin dependencies.

most plugins do not have dependencies on each other, so this more complex system doesn't win you much, e.g. with load order and conflicting registrations (i.e. two plugins registering the same tool).

being able to reload a single plugin on change while letting the others not in its dependents list jug along is neat. but that also only works if plugins actually declare dependencies (see last paragraph), and also has a lot of limitations. and the simple case, a plugin with no dependencies or dependents, which i'd say is the 90% case, does 't need that complexity either.

definitely cool stuff tho! remains to be seen how well it works in a real plugin ecosystem.

> they push the boundaries further, to the UI components

can you elaborate on this? pi extensions support contributions to the UI. in pi v1, they are limited to in-process UI. v2 splits server and client, and with that UI.

i don't remember endorsing any rust rewrite of pi.