badlogic
it's still there and won't get removed.
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.
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.
``` 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"?
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'm making specific usage pattersn out to be the problem, and explain why those patterns can't work due to the way agents work.
i too had plenty of offers, but so far chose not to follow through with any of them, as i like my life as is.
also, peter is a good friend and gives plenty of credit. in fact, less credit would be nice, so i don't have to endure more vibeslopped issues and PRs going forward :)
And I'm personally very happy that Peter's project gets all the hype. The pi repo already gets enough vibesloped PRs from openclaw users as is, and its still only 1/100th of what the openclaw repository has to suffer through.
Or you use any of the packages people provide, like this one: https://github.com/nicobailon/pi-subagents