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

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.

Perhaps I'm myopic after working too long with Clojure's data structures, but isn't that exactly what you want? I don't understand the problem with this.

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.

I realise this isn't implemented yet, but does this mean that if I use /tree to go back to a previous point in my conversation, I'll actually get a new conversation rooted at the junction point in the previous conversation? I'm struggling to understand why this is preferable, I use /tree to jump around a lot in my conversations, and it seems like I'd end up with a lot of parallel conversations. With something like /tree, would those conversations be grouped as part of the same conceptual session, or are they then completely independent forks?

``` 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!

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

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"?

That said I also dislike many of those other changes and would prefer a hypothetical version of Pi which didn't have them, so this is in some sense just me looking up at the sound of a v1.0 release and realizing "oh hey, I don't really like the direction this has been trending for a while"

The codemode stuff/mcp has been explained to death at this point but I haven't seen anything around fullscreen.

(I don't have strong feelings either way, just curious)

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.

If only there was some way to... ah no time to be snarky. It's open source and MIT licensed and you're in a thread discussing AI coding agents.

Sounds to me like things people say just to have something to say. True, it is good to listen to feedback but feedback without evidence is only going to waste your time.

Thanks for all your hard work and keep going in the direction that makes sense to you!

I can't for the life of me figure out why people would think pi is bloated.

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

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.