the_mitsuhiko

> Like what does this passage even mean:

It means that a LLM side tool (bash) can expose larger (and structured) outputs to Codemode than it normally does when that tool is executed straight to the LLM back as text.

Well that was my best attempt so far. I have to say that I find it quite tricky to convey.

We might be talking past each other here. The point of codemode is to orchestrate the LLM side tool calls, not to orchestrate scripts that it might execute within Bash.

In a world where brain and hand are on different machines, getting the bash hands to reach back into the harness brain is something that requires a) putting tools in its hands that it does not know about b) are tricky to set up, usually involving some sort of socket based back channel.

I tried this quite a bit, by having pi be always there on the hands side, but it causes a lot of complexity and the LLMs really do not understand it well at all.

> Agree, but this orthogonal to JS or bash question.

It is not from my perspective because Codemode runs in the brain, and bash necessarily runs where the hands are. So if the hands need to reach into the brain, I need to set up a communication layer from the hands to the brain.

MCP or codemode do not enable automatically, so not sure why they enable in the first place for you. Ask pi to figure out why it's one :)

    { "extensions": ["-builtin:codemode"] }

Is all that is needed to turn off codemode entirely. And -builtin:mcp would independently get completely rid of mcp.

> But I don't know why it's crude to be honest. I'm running pi in tmux and have a CLI to prompt it from any shell session / neovim and it works good. So such way of communication is already needed besides codemode.

It becomes much crummier when hands and brain are on different machines.

> I'm not sure why almost all codemode implementations choose Javascript

Because the models are trained on JavaScript for code mode. You get away with way fewer instructions. They also want to be able to express concurrency and that works very well with the Promise global.

But a big reason is that code mode runs on the harness side so bash is a tricky target in particular.

I find it quite unfortunate that the Tolkien lore has been taken hostage by one type of company. Maybe we can counter this a bit.

> Can someone explain how these durable agents handle state present on the VMs/Sandboxes ?

That greatly depends on your agent design. If you give a user a full sandbox then you're going to be in a position where you probably need to snapshot it. But there are plenty of agent designs that are not using full VMs and for those the state story is way easier.

> why directly write/read to the store, why not abstract it and do more of a reducer/redux pattern and hide the persistence of the documents?

We tried so many things. At one point it pulls in so much more complexity. At one point we had half of automerge's proxy system in there. In the end we felt like this is a reasonable line to draw, but we will see!

It's quite an interesting place to hack on, because it's both a well understood problem but with so many wrinkles to it. I can't count how many earlier designs we chewed through before we ended up with the final one and I would not be surprised if we learn even more about it.

We did not want to waste this opportunity this early but we released at 3:14 ET :)

> The point of Pi is that the user can tell the agent to improve itself and give it the tools it does need.

The point of Pi is to be minimal but also follow what the models need. We were pretty outspoken that models need code execution, and that's why Pi to this day has a very small set of tools available. However as more and more training with these models abstracts even over toolcalls themselves with code mode and similar things, it requires changes to Pi.

Mario and I talked about this last week if you want to know our thinking: https://x.com/pidotdev/status/2104510506627121451

And yes, that's why there is no Jev tool in Pi either.

It is in that sense not integrated with the coding agent. It's just that some things cannot be done with bash alone, at least not as trivially. So if you were asking Pi to utilize Jev, it would not really have the right tools available to make sense of it, even though pi-ai, the underlying library, can make requests to it.

Codemode as a mechanism can expose non LLM functionality to the coding agent. In that sense, Pi does not have a tool for Jev or other classifiers. It just now makes it easier for the agent to utilize it in the same way as it's otherwise quite creative in using bash.

A year later, some things have changed: https://earendil.com/posts/you-said-no-mcp/

Not what we stand for: https://earendil.com/values/

Armin from Earendil here. I think the question is fair, and quite frankly the answer is pretty disappointing: we look at what the models are doing. They are trained on their respective harnesses and we're not here to fight their behavior.

Codex in particular is using responses lite internally and relies on codemode for parallel tool calling. So codemode was a given.

Jev on the other hand is new but it's not the first type of model we had troubles with supporting in Pi and we looked at how to make that make sense. The internal pi-ai SDK supports image generation and classifier models, but without building an extension it was never possible for you to utilize it.

So there was a while functionality of Pi that few people used, because there were no obvious ways to hook it up with the coding agent. Codemode also allows us to close that gap.

And once you have codemode, modern MCP can work quite well if the servers cooperate.

> @the_mitsuhiko - How is the session replay of Pi embedded in the article?

Some bespoke slop :)

We will write about it. The best way to think about it is that codemode solves a different problem than bash in that bash is a way for the agent to run a particular tool: running bash.

Codemode is a way for the LLM to orchestrate harness level tools. The reason this happening now, is because the models by the labs are increasingly trained on this. Codex for instance in responses lite requires codemode to even perform parallel tool calling.

To be clear: absolutely not the plan and nothing is loaded by default that was not loaded before.

As we said in the post, we will write about Codemode more in the future. This post in many ways was necessary to address an Elefant in the room.

Author of the post here: I don't think it's a good idea to put your clanker to a PR and then try to explain it. That's because you are then reading a derivative work of a derivative work instead of going to the source.

If we fail to explain it, then we need to do a better job explaining it :)

I think this is a case of pangram's attribution being confused. All code examples are AI generated but it places the attribution on the text that surrounds it.

Doubt is always good.

I really don't know anything here, but I'm assuming that Astra's weird coding [1] is probably more a result of RSI than intentional behavior. And if it's not, then it's some other change in their training process.

[1]: https://lucumr.pocoo.org/2026/9/7/astra-why/

Not sure what you call it, but new accounts are no longer able to use librespot.

> Several countries require AC installation to be approved by the equivalent of a homeowners association or impose noise ordinances that increase compliance costs and paperwork.

This is not unique to ACs. Anything on the outside of a building requires your co-owners to agree.

> Sounds pleasant and vaguely inspirational. Then you read it again and notice guy thinks I don't always have the RIGHT to DECIDE to RESIST.

Author here: maybe I wasn't too clear about this, but I have seen people direct their anger about about what AI does to their jobs at people who themselves are not in a situation to do anything about it (eg: line managers or leaderships in businesses who are trying to roll out AI based coding tools).

I have never ever seen this behavior. For something that shows up on hackernews I would expect at least someone to provide a way to reproduce it.