One of the features I have been wanting in Kepler for a long time was the ability to use Pi as my agent when spinning up tasks. Pi is such a minimal harness that it doesn’t prompt for approval for every little thing and it’s system prompt let’s the model just be itself. That minimalism comes at a cost, though. Pi doesn’t have ACP support out of the box, so that means we haven’t been able to officially support it in Kepler, yet.

ACP? What?

If you are randomly catching this post and unclear on what ACP is, I recommend you check out my previous post about the Agent Client Protocol that goes into a bit more depth about it. To save you some time, the ACP is basically the way that Kepler and other ADEs communicate with your underlying CLI harnesses like Codex, Claude Code, OpenCode, and more. By using the ACP, you don’t have to worry about your Anthropic account getting banned for using your Claude subscription outside of Claude Code, since Kepler just uses Claude Code itself.

Using ACP with Pi

Like I mentioned, Pi doesn’t support ACP out of the box, but there is a third party tool to get it working called pi-acp. pi-acp is a third-party proxy that’s maintained by someone outside the core team. To use it, you need pi installed, but to actually get an ADE to consume it, you have to run the pi-acp command. After installing it, the config in Kepler is pretty straight forward.

If you installed it globally, the config will look something like this:

Then spinning up a task is fairly simple:

One caveat for now is that Kepler’s permission modes and thinking levels are not accurate.

Why Are Permission and Thinking Levels Currently Broken?

These permission levels and thinking levels being broken can be narrowed down to 2 separate issues.

The first issue is in how pi-acp exposes thinking levels. Even for the OpenAI models, we see that max isn’t available because pi-acp is hardcoding its effort levels. The main reason is that pi-mcp doesn’t currently use a somewhat new feature of pi. Pi recently added a function called get_available_thinking_levels that will surface your model’s configured thinkingLevelMap. That map is especially useful to configure for models like GLM 5.3 Flash and Deepseek 4.1 Flash which only support low, high, and max. As of pi 0.81.0, that function exposes that config just fine, and since pi is pretty aggressive about notifying you that there are updates, you should probably be up to date by now.

The second issue is that pi doesn’t have permission levels in the same way you might expect them in Codex, Claude Code, or OpenCode. That’s part of why I like pi because it requires less handholding, but to be fair, it’s basically in yolo mode by default which can be an issue if you aren’t using any sandboxing. Kepler, however, expects the permission levels. I believe due to legacy issues, pi-acp advertises the thinking levels as the permission levels. When doing the discovery, my agent said that this was due to a workaround for the editor, Zed. But, I don’t have confirmation on that part, yet. However, I believe Kepler would still have an issue with a null or empty permission mode list. So, we probably need to get that part working as well.

I’m planning on submitting a PR to the pi-acp project to fix the its issues and the Kepler team is already aware of what we need to do to handle a lack of permission modes. I’ll update this post with a notification when things are fixed.

Pi Should Internalize ACP Support

I love pi and its strict adherence to minimalism in the core application. Their plugin architecture and ecosystem is very strong because of it. pi may lack subagents and a whole bunch of other things that you might find useful, but at the end of the day the plugin system is strong enough that you can find or build basically anything you might want like subagents or autoresearch support. If you want to customize pi, they have an awesome catalog of plugins and extensions. You might even consider using something like oh-my-pi. But, some people consider oh-my-pi too bloated.

However, I think ACP support is a lot harder to squeeze into a plugin. Maybe the pi team could extend the plugin architecture to make it easier, but at this point, they should just internalize ACP support. Expanding the plugin hooks and functionality just to support ACP is likely as much effort as maintaining ACP support themselves and I’m not sure many other plugins would benefit from the functionality added just for the sake of ACP.