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

And every later version should add a digit.

https://tex64.com/learn/getting-started/about

I had the same concern last time I looked at Pi. There's no way to tell which are useful and semi-vetted and which are junk. I came to the conclusion that most people had their AI build them whatever plugin they needed, and I think this is even something they recommend.

What harnesses do you recommend?

Can you explain your workflow a bit please? Do any of these tools work with Claude/Codex subscriptions or are they API only?

I actually built my own tool that maintains a work graph (DAG-like) with task leases. It allows me to copy and paste pre-written prompts into Claude Code, Codex, or OpenCode and all the agents self-coordinate through MCP calls.

I built this after trying hermes and Openclaw but not liking the lack of human-in-the-loop judgement. So I'm wondering if I should keep refining my tool, or evaluate something like pi?

I wouldn't go as far as calling it a joke language (in some ways, it's incredible), but I did come here wondering if other people felt this way. The language choice has always confused me.

On the other hand, I don't think there's anything Pi does that another language would do noticeably better from a user's perspective. Any performance complaints I have using Pi come from twiddling my thumbs waiting for Sam Altman's servers to bestow tokens upon me.

At any rate, they'll probably have Opus 6.5 and GPT-7 Galactica rewrite it in rust in a couple months...

What would be a better language? Most of the harness apps will be spending most of their time waiting for the models response and tool calling rather than running their code.

Languages with less opensource footprint or too verbose are at the losing side in a llm-driven world.

Pi is extensible, and to iterate new extensions, install them, create your own, even if the agents needs to, it is much faster and easier to manage that than a compiled language I would suppose. Most of the time it's really the waiting time than anything else. If any, the "resource intensive" parts of the app could be turned into low-level extensions such as writing or reading files, maybe, but the main part of the app makes total sense. The language and ecosystem is fairly accessible as well, which serves as a further argument. Interesting choice of words when it comes to calling it "joke language" really.

One reason: it's really easy to have a lightning-fast dev loop when the entire running process can hot-swap almost every piece of code, when then also extends to all extensions written against the core functionality.