More than a year ago I wrote a few posts here that recommended people not to\nload custom tools into their context (or\nMCP servers) but to just\nuse more scripts. Most importantly I wrote that Code Is All You\nNeed and I wrote about that MCP needs\ncode. With Pi 1.0 we now added MCP support via Codemode\nwhich in some ways is a long time coming, but then also maybe somewhat\nsurprising to some. So I want to share some updated thoughts on this blog on\nwhat this all means.
\nWhen a harness like Pi provides tools for an LLM to call, it does so by\nsupplying some tool definitions which then translate into some token structure\non the server side. Whether a model is encouraged to call a tool is the result\nof the reinforcement learning process. Something I wrote about\nbefore if you want to learn more.
\nOne of the reasons we strongly lean towards CLI and bash is because it allows\neasy composition of calls, and because the model also learns how the file system\nworks when it’s trained. So when it invokes a tool like echo foo > /tmp/test.txt the model also learns that after that tool call, there is now a\nfile called test.txt in /tmp.
However bash has one fundamental limitation which is that it can only compose programs that run. And there are some things, which are not programs, but native tools to the LLM and they sort of have to be.
\nThe most obvious example here is read or view_image. If a multimodal model\nneeds to read an image, it cannot use cat for that because the harness needs\nto inject the actual image payload into the protocol of the LLM.
Another quite vivid example are sub agents. In order to spawn and orchestrate sub agents, it’s tricky to avoid tools that are provided by the harness. While in theory the agent could provide a CLI tool that talks to the outer harness via environment variables and Unix sockets, it’s a rather crude process. It however has another issue, and that is where the code runs.
\nTo better understand that, it’s important to think a bit more about where all the\nbits and pieces run. There really usually are two different systems involved.\nThe first is the brain, the harness: it runs on one machine. It’s trusted. The\nsecond is often the same machine, but it’s really where the tools are\nexecuting: the hands. In Pi we now call this the execution environment, but you\ncan think of it as the target of all the operations.
\nCrucially what is important for us, is that there is a dividing line between the harness brain and the target environment that runs bash and executes the tools.
\nAnd splitting this in half has some really important consequences. For a start\nit means that they are running on different file systems and they have different\nlevels of trust. If you for instance use a sandboxing solution like\nGondolin your bash stuff will be\nsandboxed just fine, but the harness itself will not be.
\nWhich brings us to what Codemode really does: it’s a way for the LLM to express and orchestrate complex operations on the harness side, but not the execution environment side. Codemode runs in the harness, in its own sandbox. In case of Pi it’s running in QuickJS within a WASM runtime with intentional limitations: no network, no file system, no timers, limited RAM. The only way is to call more tools. You could also imagine that Codemode could run Scheme or some other language as well.
\nIf you are not familiar with Codemode, it’s basically just a way to issue\ntool calls from within some language, in our case JavaScript. That allows you\nto compose those calls without necessarily going through the LLM’s context.\nCredit for naming goes to our friends at Cloudflare who coined\nit.
\nFor instance if you issue a bash call as a regular tool call in the LLM, then we only throw the trailing 2000 lines into the context and if the agent wants more, it needs to look at the overflow file itself. If however the agent issues that invocation via Codemode, then the Codemode side gets larger outputs sent structurally.
\nMost importantly, because Codemode is JavaScript the agent can express concurrent operations and basic workflows. A common way in which you see agents now use this, is to first probe at 5-10 items from some tool response to see what it looks like, and to then write a Codemode script that processes the next n items.
\nCodemode also allows you to throw state into the transcript! That means that one Codemode invocation can stash away data, that the next call in the session can load again. And remember: this is on the harness host, not the sandbox.
\nIn case of Pi, Codemode also allows you to issue calls that naturally do not make any sense in Pi’s traditional interface. For instance if you want to generate images with an image model or you want to classify some text with a one shot classifier model, those Pi APIs are exposed via Codemode, but not via regular tools where they would just waste context.
\nSo now that we talked a bunch about it, it’s probably worth being a bit more explicit about it. Let’s walk ourselves through some invocations of Codemode of recent Pi sessions of mine. Note that none of this code is human written. It’s from real sessions of Pi, just re-indented for your viewing pleasure. The agent starts using Codemode automatically either because it’s a task where the model already naturally picks up that tool, or because a user asked it to.
\nNote that Codemode is by default only enabled in Pi when MCP is enabled, but you\ncan turn it on with "defaultTools": ["+codemode"] in the settings. Just ask\nPi to enable it for you.
Let’s start simple with image generation. Image generation is a feature that Pi supports in the AI SDK core, but it’s not a tool that the agent can use. In the past the only way to use image models has been to write a bespoke extension or to have the agent run node itself and use the internal image APIs. However because we expose quite a few of the internal model APIs within Codemode, it means that the agent can use it:
\nconst [painter] = await models.getAvailableOfType("image");\nconst result = await models.generateImages(painter, {\n input: [{ type: "text", text: "A cute little puppy sitting on a grassy " +\n "lawn, soft natural light, photorealistic" }],\n});\nif (result.stopReason !== "stop") return result.errorMessage;\nfor (const block of result.output) {\n if (block.type === "image") image(block);\n else text(block.text);\n}Note that the call to image() sends the image back as image content to the\nLLM. On the harness side it feeds it directly into both the agent, as well as\nonto disk as a temporary artifact in case the agent wants to be able to pass\nthat image back to bash.
Similar things apply to classifier models such as Jev.\nThey also do not fit well into the workflows of an agent through the typical\ntools. But rather than making a bespoke tool available, Codemode just allows\nthe agent to reach into the AI SDK and invoke those directly. Here you can see\nhow Jev is used to mass process GitHub issues for a quick sentiment analysis:
\nconst jev = await models.getModelOfType("classifier", "typesafe", "jev-latest");\nconst r = await tools.bash({\n command: "gh issue list --state open --limit 100 " +\n "--json number,title,body,comments",\n});\nconst issues = JSON.parse(r.output);\nconst results = await Promise.all(issues.map(async (issue) => {\n const res = await models.classify(jev, {\n state: {\n title: issue.title,\n body: (issue.body || "").slice(0, 4000),\n comments: issue.comments.slice(-5).map(c => c.body.slice(0, 800)),\n },\n questions: {\n sentiment: {\n type: "choice",\n instructions: "What is the overall sentiment of the author towards pi?",\n criteria: {\n positive: "Appreciative, happy, constructive praise",\n neutral: "Matter-of-fact report or request without emotion",\n negative: "Frustrated, annoyed, upset, or angry",\n },\n },\n frustration: {\n type: "score",\n instructions: "How frustrated is the reporter?",\n criteria: ["not at all", "mildly", "clearly frustrated", "very angry"],\n },\n kind: {\n type: "choice",\n instructions: "What kind of issue is this?",\n criteria: {\n bug: "Bug report or regression",\n feature: "Feature request or enhancement",\n question: "Question or support request",\n other: "Docs, discussion, meta, spam",\n },\n },\n },\n });\n if (res.stopReason !== "stop") {\n return { n: issue.number, title: issue.title, error: res.errorMessage };\n }\n return { n: issue.number, title: issue.title, ...res.answers };\n}));\nstore("sentiment_results", results);\nreturn results\n .filter(r => !r.error)\n .sort((a, b) => b.frustration.score - a.frustration.score)\n .slice(0, 12)\n .map(r => `#${r.n} ${r.frustration.score.toFixed(2)} [${r.kind.choice}] ${r.title}`);Note how in that above example we also call store() which dumps the result of\nthat execution into the session transcript. A future invocation of Codemode can\nthus read back that result if it wants to.
The Promise.all here is fine, because Pi limits the total number of concurrent\ntool executions itself to four and maintains a queue for the rest.
A more adventurous example is to use Jev to drive a game engine for debugging purposes:
\nHere it knows about my tankctl command and it built itself quickly a minimal\nharness around it to drive a game loop to assist a user with debugging a\nproblem. Note how it built a 30 step loop in which each step goes back to both\nthe game engine to get a text dump of what’s going on, and then to Jev to\ndetermine what to do next:
const jev = await models.getModelOfType("classifier", "typesafe", "jev-latest");\nconst tank = async (cmd) =>\n (await tools.bash({ command: `tools/tankctl "${cmd}"` })).output;\nawait tank("start --map assets/maps/night_arena.map");\nconst questions = {\n action: {\n type: "choice",\n instructions: "You control the tank '@' in a top-down tank game. " +\n "Choose the best next action.",\n criteria: {\n attack: "an enemy has line of sight to you and you can fire at it",\n approach: "no enemy has line of sight; drive toward the nearest enemy",\n dodge: "an enemy shot is heading at you and will hit soon",\n powerup: "a powerup is close and no enemy threatens you",\n },\n },\n};\nfunction commandFor(choice, st) {\n const p = st.player;\n const enemy = st.enemies.filter(e => !e.dead)\n .sort((a, b) => (b.los - a.los) || (a.dist - b.dist))[0];\n if (choice === "attack" && enemy) {\n return `fire_at tank ${enemy.id}; frames 30 until clear,damage,kill`;\n }\n if (choice === "dodge") {\n // move perpendicular to the closest incoming shot\n const s = st.projectiles.filter(s => !s.yours)\n .sort((a, b) => a.eta - b.eta)[0];\n const dir = s && Math.abs(s.vel[0]) > Math.abs(s.vel[1])\n ? (p.pos[1] > s.pos[1] ? "+down" : "+up")\n : (p.pos[0] > (s ? s.pos[0] : 0) ? "+right" : "+left");\n return `input ${dir}; frames 20 until damage; input stop`;\n }\n const powerup = st.powerups.filter(u => u.available)\n .sort((a, b) => a.dist - b.dist)[0];\n if (choice === "powerup" && powerup) {\n return `goto ${powerup.pos[0]} ${powerup.pos[1]} 180`;\n }\n return enemy ? `goto ${enemy.pos[0]} ${enemy.pos[1]} 90` : null;\n}\nconst log = [];\nfor (let step = 0; step < 30; step++) {\n const st = JSON.parse(await tank("state"));\n if (st.state !== "playing") break;\n const threats = st.projectiles\n .filter(s => !s.yours && s.miss_dist < 1.5 && s.eta < 1.5)\n .map(s => `incoming shot dist ${s.dist} eta ${s.eta}s`)\n .join("\\n") || "no incoming shots";\n const r = await models.classify(jev, {\n state: { map: await tank("view 8"), threats, hp: st.player.hp },\n questions,\n });\n if (r.stopReason !== "stop") {\n log.push(`#${step} classifier error: ${r.errorMessage}`);\n break;\n }\n const choice = r.answers.action.choice;\n const cmd = commandFor(choice, st);\n if (!cmd) break;\n log.push(`#${step} hp=${st.player.hp} ${choice} -> ${await tank(cmd)}`);\n}\nreturn log.join("\\n");Lastly, Codemode obviously is great for calling MCP servers. And because we do not actually expose any of the MCP tools to the LLM, the agent first uses provided APIs to issue a tool search within Codemode to discover what it might be able to do with the connected servers. This form of progressive discovery makes the whole MCP business work well enough for a lot of use cases today.
\nHere for instance you can see the agent reach for the Sentry MCP straight away, even without discovering the tools, presumably because it has learned during the RL process already about what the Sentry MCP looks like. But it learns from what we inject into the system prompt, that the Sentry server is available to begin with. It’s not completely guessing here.
\nconst orgs = await tools.mcp__sentry__find_organizations({});\nconst { organizations } = orgs.structuredContent;\nconst results = await Promise.allSettled(organizations.map(org =>\n tools.mcp__sentry__find_projects({\n organizationSlug: org.slug,\n regionUrl: org.regionUrl,\n })\n));\nreturn organizations.map((org, i) => {\n const r = results[i];\n if (r.status !== "fulfilled") return { org: org.slug, error: String(r.reason) };\n if (r.value.isError) return { org: org.slug, error: r.value.content };\n return {\n org: org.slug,\n projects: r.value.structuredContent.projects.map(p => p.slug),\n };\n});I really don’t want to talk too much about MCP here, but MCP is in fact a protocol that greatly benefits from Codemode. The problem in parts is that MCP in practice often targets harnesses that do not (yet?) use Codemode. But the tide is shifting. In the meantime, a temporary crutch has been to do what Cloudflare did, and do Codemode within the MCP server. But now we have Codemode in Codemode which is pretty bad. It means double JSON escaping, easy for smaller models to get confused by and the inner code cannot call the outer tools. So if you for instance use the Cloudflare MCP servers in Pi, the agent needs to write JavaScript and funnel it through more JavaScript. This is really not optimal, but it’s also understandable that this is happening:
\nconst accRes = await tools.mcp__cloudflare__execute({\n code: `async () => {\n const r = await cloudflare.request({ method: "GET", path: "/accounts" });\n return r.result.map(a => ({ id: a.id, name: a.name }));\n }`,\n});\nconst accounts = JSON.parse(accRes.content.map(c => c.text).join(""));\nconst out = [];\nfor (const account of accounts) {\n const r = await tools.mcp__cloudflare__execute({\n account_id: account.id,\n code: `async () => {\n const r = await cloudflare.request({\n method: "GET",\n path: \\`/accounts/\\${accountId}/workers/scripts\\`,\n });\n return r.result.map(s => ({ id: s.id, modified: s.modified_on }));\n }`,\n });\n out.push({ account: account.name, workers: r.content.map(c => c.text).join("") });\n}\nreturn out;So to end things off: how well does Codemode work with MCP today? Well … not amazingly well. That’s because MCP servers are not really targeting harnesses that use Codemode yet (though at this point I think most harnesses support it).
\nFor this to work well some recommendations:
\nStructured content: Codemode wants calls to return some nicely
formatted JSON. So that needs to come back from the server, and many don’t\ndo that yet. TheoutputSchema system in MCP is great for that.
Consistent results: an interesting failure case is when an MCP server
does not return consistent data. For instance because it tries to token\noptimize things depending on how many items are in the result set. This can\ncause an initial probe with 5 items to succeed, but then fail when the server\nreturns the maximum batch size.
Large binary data: today MCP does not yet support large binary data
so quite a few use cases that are really interesting do not work well at all\nyet. You end up with all kinds of weird workarounds such as pre-signed URLs\nto allow file uploads then to happen through non MCP channels.
Composable tool search: the MCP server might know better than the MCP
client which tool is appropriate for a task. But there is no good mechanism\ntoday that allows a harness to fan out tool searches across multiple MCP\nservers. It’s all emergent behavior and it does not scale well to multiple\nactive servers.
So where does this leave us? Is this a reversal of what I wrote a year ago where I encouraged CLIs? I don’t think so. In fact, the MCP ecosystem from my perspective picked up on exactly what we pointed out a year ago works: code. But Codemode goes beyond MCP in that it can act as a capable mechanism within the harness to express more freedom for the agent.
\nThere are however also some things that we still need to figure out. For one, durability with Codemode is trickier. We might have to adopt some ideas from durable workflow engines here to snapshot invocations. Or maybe, something like Starlark is a better composition language than JavaScript given its deterministic nature.
\nImages, binary data and just the inability of this pattern to work with smaller models is also something that needs to be fleshed out. So it’s for sure not a perfect solution yet, but it’s quite a useful pattern that I expect us to leverage more.
","headings":[]}}