Between this and the Cloudflare post, this is a lot of words and no simple system level picture. Here's what I think is going on:

1. Homoiconicity: Harness mechanics are kludgy and we need proper homoiconicity to uniformly handle code (tool calls) and data ("natural language") as token streams.

2. Actor semantics: for isolation, encapsulation and concurrency.

3. Object capabilities: injected references and no ambient authority. Capabality-based reflection/introspection is a clean way to discover interfaces and affordances.

"Code mode" or whatever is basically rediscovering this by hacking outward from LLM token streams, instead of from system design principles based on decades of computer science. It is the beginning of treating an LLM as a programming-language runtime participant (any takers for eval/apply?) rather than as a text/token generator with the harness as an ad-hoc interpreter.

If existing implementations of code mode don't already support all this, I anticipate they will keep piling on hacks till they get to this point.

----

I think it was Dan Ingalls who said "An operating system is a collection of things that don't fit into a language. There shouldn't be one.". I see the same for harnesses -- they're awkward middle children which fit neither in an LLM nor in the programming environment.

Maybe the answer is to partner LLMs with Common Lisp or Scheme fibers / Spritely Goblins or Erlang BEAM and be done!

If you're like me and you're still wondering what "codemode" is after reading the article and comments:

It's giving the harness a small js sandbox to compose tool calls and manipulate the data they return before reading it into context.

I'm not sure why almost all codemode implementations choose Javascript. I prototyped an agent[1] to use bash as the language for codemode, which in my opinion worked equally well and requires no teaching (there is literally 0 prompt to teach the LLM about codemode. A tool named "bash" is enough to have them know the usage).

[1] https://github.com/ylxdzsw/mu

Sadly this seems like introducing a very complex apparatus for little gain. I don't need MCP or many tool calls that the agent can program around - in fact the promise of pi was that you basically just need bash and no other tools. The minimally-invasive approach would have been to just "inject" tool calls as virtual bash commands. No code mode required, no hands vs. brains dichotomy. LLM can use language of its own choosing to interact with tools.

The headline is "What is codemode". As someone who did not know what codemode is, I had to read until the section "Orchestrating The Harness", where it says "If you are not familiar with Codemode, it’s basically just a way to issue tool calls from within some language, in our case JavaScript."

I could then somehow get what is meant from the examples, but the contents of the article do not at all match the headline.

I've noticed that code mode seems to cause progressive lobotomisation in Sol 6.1 around subagents. The more it uses it, the worse it gets at giving prompts to subagents:

  URLs, datasourceproxy accesspathonlyallowed anddefault404. Do not set authbasic onprivate ports; perplanPodmannetwork trustedinfrastructure nottenant boundary. Publicroutes internal /tinyauth protected internal, proxyGETemptybody /api/auth/nginx toprivate tinyauth3000; proxy_pass_request_headersoff, CookieonlyTinyauthSession header extracted map name/value actual runtime pattern tinyauth-session-[0-9a-f]{8}, X-Original-URL constructed

Can someone please tell me how to disable it permanently in pi? I have already disabled it in settings.json, but, it just doesn't get disabled:

    {
      "source": "npm:pi-mcp-adapter",
      "extensions": [
        "-index.ts",
        "-builtin:codemode"
      ]
    }

    "autoEnableCodemode": false,

I’m still figuring out codemode. I was using it in a prototype, but ended up stripping it out again, after realizing my small local LLM was using more tokens than usual. It was combining tool calls elegantly in code exactly how I hoped it would. The problem was that when any of those embedded tool calls failed (e.g. on parameter validation) the parent code execution tool call also failed. In response, the LLM kept rewriting large parts of the original code block.

Btw, Monty by the pydantic team is a joy to work with if you need a way to securely run unverified code. It’s a simplified Python dialect. You can also use it from JS, iirc.

Why is this a personal blog, not a Pi post?

https://earendil.com/posts/you-said-no-mcp/ remains difficult to read without understanding what codemode is, with some quote like "Now we talked so much about Codemode, it might be worth explaining what that even is."

This seems to come down to object model and tooling differences between sandboxed JavaScript and sandboxed Unix. You can make Unix commands do whatever you like, including special commands to send things back to the coding agent. But the output of a Unix command is arbitrary text (by default) and the AI will have to pipe things into some other command when there’s a lot of output. In the coding harness I use, I see OpenAI’s LLMs writing a lot of pipelines, often processing the output with python. Also the whole thing needs to run in a VM.

A JavaScript sandbox works somewhat differently since the output is an object. Tools are functions that naturally return objects. Composing functions and async calls work differently. If a function returns a very large object, the coding harness could be smarter about presenting the result to the LLM. Maybe JacaScript works better than bash for calling mcp APIs?

But you can have both! The LLM can get direct access to a JavaScript sandbox, which in turn provides an API to access a Linux sandbox. This seems to be what pi is doing with code mode?

I've been using Codemode with the new Dot so that Dot can coordinate my agents with:

1. Launching workflows, so it avoids some large configuration

2. Reviewing work, with reviewers restricted to read-only tools or specific tools. Or some tools for reviewers to check hashes, correctness, etc.

3. I'm using the widely used pi-extensible-workflows. So say you want to stop a workflow, you gonna call workflow_stop. Or check the status with workflow_status. Without Codemode, Pi exposes an API, that the agent can use. So yes, you can call workflow_status. Or call workflow_stop. With Codemode, the agent can do something more complex like a for loop over all the list of workflow ids and get a status and stop them all (again, it's just an example).

So basically, Codemode allows to build a sort of framework for more correctness like using a typed language vs. JavaScript without a linter. It gives boundaries essentially. And also Codemode allows an agent to do things more easily like using internal Pi extensions.

I'm surprised I don't hear more people talking about code mode using existing SDKs for APIs like Google Workspace. That works so much better than converting the Google Workspace MCP JSON schemas to Types, then having the model write TypeScript to call those MCPs and then translate those back to JSON RPC calls. Just using that token from the MCP server and using the underlying fetch requests that the TypeScript Google Workspace SDK makes works infinitely better than teaching the model bespoke types. I'm assuming we're going to see a lot more of this as CodeMode gets more widely supported in harnesses

tbh but this article is pile of shit. Why would author expect ppl to push themselves through the whole thing to simply understand what it is all about?

I appreciated this post, had never heard of codemode and I think the name is bad but it makes perfect sense

I have wanted something like this ever since I hooked up my first database MCP

Originally I had thought to set up a python runtime with like a standard data science toolkit and the db mcps available as functions, and maybe I still will but JS has been working fine for now

So... What exactly is it in the end? I try to parse the long prose, and couldn't.

It doesn't help that the article is titled "What is Codemode" and then goes to say "If you are not familiar with Codemode, it’s basically just...". You article is supposed to say what it is without anyone being familiar with it.

Like what does this passage even mean:

--- start quote ---

For 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.

--- end quote ---

How is this different to Claude writing mini scripts to get jobs done which it does quite often?

We just need an LLM based Lisp so we can finally close the loop of code is data and data is code.

subagents differ: in my claude code logs every subagent cache write is 5-minute tier, main session 1-hour

Am I crazy for saying I like codemode? It reduces the amount of turns by about an order of magnitude.

emmmm~~ I feel increasingly confused the more I watch.

[flagged]

[flagged]

[dead]

[flagged]