Pi Coding Agent: Thin Harness, Fast Provider Churn, and Extension Contracts

What Changed

Pi shipped multiple releases inside the sprint window. Highlights include:

• TypeBox 1.x migration and TypeBox-native validation for extensions and SDKs
• stacked extension autocomplete providers
• terminating tool results
• searchable auth-provider login
• GPT-5.5 Codex support
• provider retry and timeout controls
• DeepSeek, Cloudflare Workers AI, Cloudflare AI Gateway, Moonshot, Mistral, Azure Cognitive Services, and Xiaomi MiMo providers
• removal of built-in Google Gemini CLI and Google Antigravity support
• cached Codex websocket transport for ChatGPT subscription auth
• custom provider base URLs
• model thinking-level metadata
• incremental bash output streaming and compact read rendering

Operator Consequence

Pi is acting like a deliberately minimal but very active terminal harness. The provider layer is fluid: new providers appear, built-in integrations disappear, transports change, and extension contracts carry much of the product's durability.

That is a useful lesson for Bitter. Worker adapters should be thin, versioned, and disposable. The durable layer should not be a worker's provider list.

Bitter Implication

Bitter should learn from Pi's extension discipline and terminal UX, especially incremental bash streaming and compact read rendering, but keep governance outside the worker harness.

Adapter work should record:

• exact Pi version
• provider selected
• transport selected
• session directory
• extension set and schema version
• thinking-level or reasoning metadata
• whether a provider integration is native, external, or removed

Signal

The harness frontier rewards extensibility and provider churn. Bitter should wrap harnesses through normalized run receipts instead of relying on any worker's integrations as stable doctrine.