disclaimer: all the code changes and text below are written by/with support of AI

tldr: Code changes

Why adding Pi support to NanoClaw

I’ve been experimenting with NanoClaw, and one thing quickly became clear: its containerized, per-group isolated architecture is extremely compelling, but the default assumption around
Claude/Anthropic is a constraint for me.

I don’t currently have an active Anthropic subscription/API setup, so I wanted a path that preserves NanoClaw’s strengths while making the runtime more flexible.

That’s the motivation for adding Pi coding agent support.

Why this matters

NanoClaw’s core design is great:

• each group gets isolated filesystem + memory
• agents run in containers, not directly on the host
• scheduled tasks and IPC tooling are already built in
• the overall codebase is still small enough to understand and customize

What I wanted was to keep that architecture, but swap in a runtime that can work with different model/provider setups.

Why Pi

Pi opens up two especially attractive options for me:

1. Local LLMs

I want to be able to run NanoClaw against local or self-hosted OpenAI-compatible endpoints.

That means:

• lower cost
• more control
• faster experimentation
• ability to use something like llamabarn for cheaper/background tasks

For a personal assistant that may run scheduled tasks or long-lived workflows, this is a big deal.

2. OpenAI Codex via Pi-native auth

I also want to use openai-codex through Pi’s own provider/auth model.

That’s appealing because:

• I may want to use ChatGPT/Codex access I already have
• I don’t necessarily want everything tied to Anthropic-specific auth assumptions
• Pi provides a more flexible abstraction over providers and models

The real goal

The goal is not to replace NanoClaw’s architecture.

The goal is to preserve:

• container isolation
• per-group persistence
• scheduled tasks
• host/container IPC model

while making the container-side agent runtime pluggable.

In other words:

│ keep NanoClaw’s orchestration, but make the LLM/runtime layer less tied to a single provider path.

Why this seems worth pursuing

So far, the Pi runtime path looks promising because it can support:

• local OpenAI-compatible providers
• Pi-native provider auth
• persistent sessions
• long-lived IPC-driven conversations
• NanoClaw task/message tools
• transcript logging and compaction support

That makes it feel like a viable direction, not just a toy experiment.

Broader incentive

I think this could make NanoClaw more accessible to people who:

• don’t have an Anthropic subscription
• prefer OpenAI/Codex
• want local models
• want a more provider-flexible personal assistant without giving up NanoClaw’s isolation model

Current stance

I still think this should stay behind a runtime switch until it’s better tested and hardened.

But as an experimental path, Pi support feels like a strong fit for NanoClaw’s design philosophy:

• small
• understandable
• customizable
• secure by containment

Looking for your opinions/feedback.