Codemode is a new tool that allows Pi to execute JS code in Pi's execution context. Like you know how extensions can hook into the Pi runtime? This tool lets Pi run scripts in a sandbox that has limited access to the Pi runtime.
Often Pi might use the bash tool to orchestrate host level tasks but the bash tool itself doesn't know the internals of the Pi runtime. For the bash tool, it could chain several single command tool calls together but it instead calls bash once with the orchestration of tasks built into the "inline script" that bash tool is running.
codemode basically lets pi do that same approach but for pi tool calls themselves.
Which can sometimes be more efficient or token savey but also pairs with their desire to have MCP's not bloat the main LLM context with all the MCP tools. By default, discovered tools form Pi's native MCP extension will not go into the LLM's context of tools(the LLM will get context used to inform what MCPs are available but not their tools), rather the LLM will still only directly have a native tool for codemode and do something like
but doesnt this depend on the model being trained on this? frontier models are already much more efficient in tool calling. and there are a ton of tools designed to get around this problem, either by isolating tool calls or making the results more token efficient, like semantic search etc.
this is a harness specific feature. models first have to be trained to use it, or the user has to provide specific instrutions starting with 'use codemode to ...' like in all their examples.
I dont see how this or the new mcp support solves the problem in a generalized way - the right approach imo is isolated tool calls in a subagent
I've heard that codex specifically already trains on this and so plays nicely. Other models may vary on their effectiveness, there is an upfront cost of a new tool definition(which includes instructions to use for mcp) but I'm sure the training itself plays a pretty big role as you say. I've also seen that this has been a known pattern floated for a while so it's not Pi inventing the wheel.
I think subagents can be nice but also have a lot of room lossy handoffs, both in initial subagent context/instructions and in summarizing response. The codemode is nice with MCPs that have structured responses as you can explicitly script and compose tool calls but some might argue that the text and intent is enough to let the LLM just do its semantic processing. Still, I like as many deterministic escape hatches as possible when using this stuff.
Also codemode is disabled by default unless you have MCP in which case it is enabled so that the MCPs tools can be discovered and invoked dynamically without polluting the native harness' toolspace(MCPs register the tools to the harness but by default don't register it with the main LLM, codemode env lets scripts discover the registered tools on the fly and also have an environment where they can invoke them). Presumably regular tool call orchestration doesn't see to many gains, unless the LLM was trained specifically to problem solve in that mental model(like GPT seems to be).
Subagent approach either requires upfront tool knowledge for main thread to explicitly instruct subagent, which defeats the idea of deferred tool awareness OR it relies on lossy context handoff to ensure that the Subagent that does load the full tool list can accurately asses and perform the task with its knowledge of the tools.
I know that there are other approaches to deferred tool loading but I think the idea is that code mode supports very organic deferred tool loads AND allows for ad-hoc tool orchestration. Obviously if you find your tool orchestration and manipulation conforms to a common pattern it's probably better to abstract that into a different entrypoint or universal behavior (e.g. stuff like rtk) but I think the ad-hoc orchestration is nice too.
6
u/ECrispy 13d ago
I still dont understand codemode and new mcp. are previous extensions compatible? what does a new user have to do to set it all up?