Pi Project Update

Here is today's Pi Project Update for Tuesday October 6th. Pi’s release and packaging pipeline received a substantial reliability upgrade today. A newly merged artifact-validation system now builds one content-addressed set of package tarballs, then installs each of Pi’s 13 public packages as the only direct dependency in isolated test consumers. It checks package contents, exports, binaries, imports, versions, and lockfile behavior before publication. Release CI will publish those exact validated tarballs rather than rebuilding through a separate path. For users and downstream integrators, that should mean fewer surprises where a package works inside Pi’s monorepo but fails after installation. [1]

Pi AI is also making it easier for applications built on its libraries to retain their own identity. Two changes let embedding developers override Codex request headers and set an optional application name for OpenAI logins. Previously, a third-party tool using Pi AI could appear as “Pi” in the Sign in with ChatGPT authorization screen and in Codex-originating requests. Apps can now supply their own agent name while Pi retains secure control over authorization headers and account identifiers. This is an important maturity step as Pi increasingly becomes infrastructure for other agents, rather than only a standalone terminal client.

On the local-model side, Pi’s coding agent now recognizes certain llama.cpp-hosted decision models as native classifiers instead of treating them as ordinary chat models. It probes loaded models once per session and identifies families including Julia-1, Laya, Kev, lev, and OpenJev. That should allow more appropriate routing and behavior for specialized local models, while preserving the existing fallback for normal llama.cpp chat deployments.

Finally, managed installations now automatically prune old release directories, retaining only the new version and the release that performed the update. That addresses a practical storage problem, especially on Termux and other space-constrained systems, where each historical Pi release could consume roughly 160 megabytes.

The pattern today is operational hardening: Pi is validating what it ships, giving embedders clearer branding, improving local-model awareness, and reducing maintenance overhead for everyday installations. Thank you for listening to Pi Project Update from The Daily FM. See you tomorrow!

Here is today's Pi Project Update for Monday October 5th. Pi has expanded Azure Foundry compatibility with support for Chat Completions deployments, merged today. Previously, Pi’s Azure integration centered on the Responses API, which left many Foundry-hosted models—including DeepSeek V4 Pro—unavailable or incompatible. The updated Azure provider can now route models declared with the OpenAI Completions API, while continuing to use the same Azure resource, credentials, and deployment-name mapping. In practical terms, this opens Pi to a wider range of Azure-hosted models, including families from Llama, Mistral, Grok, Kimi, and Phi, where their deployments support that endpoint. [1]

Also merged today is a terminal display repair for multiline syntax highlighting. Pi’s coding-agent interface previously colored only the first line of a multiline token, such as a Python docstring or a block comment, leaving subsequent lines unstyled. The fix processes highlighted spans one line at a time and also gives JavaScript string interpolations their own text color. It is a small visual change, but one that should make generated code considerably easier to scan in the terminal. [2]

The repository’s newest work also points to a larger infrastructure push: Pi is adding pi-env, a package for remote execution environments over SSH. Recent commits cover SSH bootstrapping, daemon support, and builds for supported remote systems, alongside Durable improvements such as filesystem watching, bounded file readers, and more controlled shell-output windows. This suggests Pi is laying groundwork for agents that can operate more reliably beyond the local machine, especially across remote or long-running development environments.

Finally, the team has corrected fullscreen keyboard behavior so Home and End return to their editor-navigation role rather than automatically jumping through the transcript. That responds directly to early 1.0 usability feedback.

The overall pattern is clear: Pi is broadening model and infrastructure reach while rapidly smoothing the practical rough edges exposed by its 1.0 release. Thank you for listening to Pi Project Update from The Daily FM. See you tomorrow!

Here is today's Pi Project Update for Sunday October 4th. Pi has released version 1.0.2, the latest rapid follow-up to this week’s 1.0 milestone. The release arrives amid a heavy round of feedback from extension authors, MCP users, and terminal users, and reinforces the project’s current priority: stabilizing real-world workflows quickly rather than slowing feature development after the major release.

Yesterday, Pi merged a meaningful model-configuration improvement for reasoning models. Instead of applying one set of sampling settings everywhere, model definitions can now specify sampling parameters by thinking level. That matters because many newer open models recommend very different temperature, top-p, and repetition settings when reasoning is enabled versus when the model is answering directly. Pi applies the configuration across its OpenAI-compatible Completions and Responses paths, including streaming. For users maintaining custom model catalogs, this should make it easier to get more consistent behavior from models such as Qwen without compromising either fast instruction mode or deeper reasoning mode. [1]

A second fresh change improves Pi Durable’s provider-session handling. Durable conversations now persist a distinct UUIDv7 provider session identity and pass it through to Pi AI. The practical benefit is better continuity for providers that use session identifiers for prompt-cache keys, stable headers, or connection reuse. Importantly, child conversations and history forks receive their own identities rather than inheriting the parent’s, avoiding accidental mixing between subagents. It is invisible infrastructure, but it could reduce repeated-context cost and improve reliability in long-running, multi-agent workflows.

There is also a model-catalog adjustment: NVIDIA now defaults to Nemotron 3 Ultra. Alongside that, Pi continues refining the terminal experience around MCP tools, including rendering MCP tool calls before their server connection finishes, which should make an agent’s activity less opaque during startup.

The broader trend is that Pi is becoming more deliberate about execution quality: model settings increasingly reflect how modern reasoning models actually operate, durable sessions carry provider-aware state, and the interface is exposing more of what an agent is doing while connected tools come online. Thank you for listening to Pi Project Update from The Daily FM. See you tomorrow!

Here is today's Pi Project Update for Saturday October 3rd. Pi’s post-1.0 stabilization work is moving quickly, with several fixes landing around reliability, security, and terminal behavior. A key packaging change removes the coding agent’s bundled npm shrinkwrap and steers users toward Pi’s managed installer. That follows reports that the shrinkwrap kept an older brace-expansion dependency installed even when downstream projects attempted security overrides. The change should make patched dependency resolution less fragile for teams with strict audit requirements.

Terminal image support also received a useful set of repairs. Pi now converts non-PNG images before sending them through the Kitty graphics protocol, addressing cases where JPEG, WebP, GIF, and BMP images were silently discarded because they were labeled as PNG. A separate fix preserves inline images in WezTerm while scrolling, resolving a fullscreen display bug where images could collapse into a thin strip. Together, these are practical quality-of-life improvements for users who inspect visual assets from the CLI.

For agent execution, Pi has capped codemode script output so accidental or runaway print loops cannot exhaust the host machine’s memory. That responds to concerns that long-running scientific or automated scripts could accumulate huge output streams before an embedding application had a chance to limit them. The project is also working through broader codemode safeguards, including requests for backpressured output handling and payload-size checks before large JSON transfers.

MCP configuration has become more flexible as well. A new change lets a project-level mcp.json override the enabled state and exposure of global servers. In practice, that means projects can disable or hide a user-wide tool server without duplicating its full connection configuration. It is a small configuration change with meaningful safety implications for developers who keep privileged or environment-specific MCP tools globally configured.

Yesterday, Pi also merged two forward-looking additions: an initial, work-in-progress Nix flake for reproducible installation and development, plus Cloudflare’s Clef and Clef Flash classifiers in the Workers AI catalog. The broader trend is clear: Pi is pairing new provider and packaging options with rapid hardening of the operational details that matter after a major release. Thank you for listening to Pi Project Update from The Daily FM. See you tomorrow! [1]

Here is today's Pi Project Update for Friday October 2nd. Yesterday, Pi released version 1.0.0, marking a significant milestone for the terminal coding-agent project. The release lands alongside a new default fullscreen TUI mode, revised startup options, and continuing work to move experimental client-server capabilities onto Pi Durable. For users, version 1.0 signals that Pi’s core agent, provider, tool, and extension foundations are becoming more stable, even as advanced capabilities remain under active development.

Today’s follow-up work is already addressing operational issues discovered around the release. Pi has pinned its bundled brace-expansion dependency to version 5.0.12, resolving three published security advisories involving denial-of-service risks from pathological brace patterns. Because Pi’s published shrinkwrap had prevented downstream users from overriding the affected version themselves, this is an important supply-chain maintenance fix for organizations whose CI checks dependency vulnerabilities.

Reliability for busy model providers also improved. Pi now recognizes “Selected model is at capacity” as a retryable provider error. Previously, a temporary capacity rejection could end a turn after one failed request, forcing users to manually continue. The updated handling brings that wording in line with existing retries for overload and high-demand messages, making transient provider failures less disruptive.

There is also fresh provider compatibility work. Pi has added support for defining Anthropic tools inline during a conversation, a capability that should help with more dynamic tool workflows. And a small but practical catalog repair updates Together AI’s DeepSeek V4 Pro model identifier after the upstream name changed, preventing CI and model-selection failures.

On the interface side, yesterday’s Radius login work adds an animated sign-in option and a short explanation that Radius is a service built for Pi by Earendil Works. That makes the growing authentication surface feel more intentional as Pi supports API keys, OAuth, device flows, and external services. [1]

The larger trend is clear: Pi 1.0 is not a pause in development. The project is pairing a major stability milestone with rapid fixes for security, upstream model churn, provider resilience, and smoother onboarding. Thank you for listening to Pi Project Update from The Daily FM. See you tomorrow!

Here is today's Pi Project Update for Thursday October 1st. Pi’s newest development focus is an experimental durable terminal coding agent. Today’s commits make the durable TUI’s task panel visible by default and add a task-graph view, alongside lifecycle conformance work. This is early infrastructure, but it points toward a more structured experience for long-running or multi-step agent work: users could eventually see not just a scrolling conversation, but the tasks, dependencies, and state transitions behind it.

MCP integration also received a meaningful round of practical fixes today. Pi now stores OAuth credentials using both a server’s name and URL, rather than URL alone. That should let users maintain separate sign-ins for services such as multiple Slack workspaces sharing one endpoint. The project has also added the official MCP client conformance suite to continuous integration, preserved granted permissions during step-up authorization, and made empty optional OAuth fields behave as absent. Together, those changes suggest Pi is tightening interoperability and reducing fragile edge cases around external tools.

For command-line users, a fix now requires an explicit model when the `--provider` option is supplied. This addresses a misleading situation in which selecting a provider without a model could silently run the configured default model from another provider. It is a small validation change, but an important one: authentication checks, debugging, and automation should no longer appear to succeed against the wrong backend. [1]

Yesterday’s merged changes broadened Anthropic access. Pi can now use Anthropic’s workload identity federation environment variables, enabling CI and other managed environments to exchange an identity token for short-lived credentials without keeping a static API key. Separately, Anthropic OAuth gained a copy-code login method for remote machines, where a local browser redirect is inconvenient or unavailable. [2]

The broader trend is that Pi is becoming more serious about deployment environments beyond a local laptop: cloud agents, CI jobs, remote terminals, and multiple connected tool accounts. At the same time, the durable-agent work indicates a longer-term shift from a simple chat interface toward a more observable, stateful agent workspace. Thank you for listening to Pi Project Update from The Daily FM. See you tomorrow!

Here is today's Pi Project Update for Wednesday September 30th. Pi has expanded its OpenAI sign-in options, with an alternative ChatGPT-based authentication flow now merged for the OpenAI provider. The implementation adds OAuth handling, device and credential support, retry behavior, and extensive test coverage across the Responses API. For users, the practical goal is simpler access to OpenAI-backed models without relying solely on a conventional API-key setup. This follows closely behind Pi’s update making GPT-6.1 Sol the default Codex model, signaling continued attention to current OpenAI model offerings and account-based access.

Yesterday’s development also delivered several concrete reliability fixes. Pi now validates Base64 passed into codemode’s image helper and detects image types, preventing malformed image data from being accepted into session history only to make later model requests fail with HTTP 400 errors. A separate fix recognizes the Z.AI China endpoint’s “Prompt exceeds max length” response as a context overflow, allowing the normal recovery behavior to activate rather than surfacing an opaque provider error.

MCP, or Model Context Protocol, received both usability and documentation attention. Authentication links shown through Pi’s MCP interface are now clickable in terminals supporting OSC-8 links, matching the existing provider-login experience. And the MCP server guide was reorganized around a working quick setup, configuration, troubleshooting, migration, tool exposure, OAuth, and SDK usage. That should reduce friction for users connecting external tools and services to Pi. [1]

There are also incremental improvements for extension authors and the terminal interface. Renderer examples now retain the complete built-in tool definitions, including prompt guidance that had been lost in customized examples. Pi will additionally warn users when their extension replaces a built-in command such as slash-MCP, making configuration conflicts much easier to diagnose. [2]

The broader trend is that Pi is maturing at the seams: authentication, provider-specific error handling, external-tool setup, and extension customization. The headline features matter, but this week’s work emphasizes preventing subtle failures and making advanced integrations easier to understand and trust. Thank you for listening to Pi Project Update from The Daily FM. See you tomorrow!

Here is today's Pi Project Update for Tuesday September 29th. Pi has added a more unified way to manage its built-in coding-agent extensions. As of today’s merge, components such as MCP, llama.cpp, codemode, and tool search are represented as named built-in resources, using paths like “builtin:mcp.” The practical payoff is control: users can disable a built-in extension globally or per project through Pi’s configuration interface, disable all extensions with the existing no-extensions option, or explicitly load a chosen built-in extension. It brings bundled capabilities closer to the same configuration model used for file and package extensions, without treating them as opaque special cases. [1]

A second major development, merged yesterday, introduces experimental virtual models. An extension can now register a model entry that acts as a routing policy instead of directly calling a provider. For example, Pi could plan with a stronger model, switch to a lower-cost model for implementation, or select a larger context window as a task grows. Pi preserves the virtual model choice in session history while recording which physical model actually generated each response. That makes sophisticated routing extensible, traceable, and compatible with session branches and compaction.

Today also brings a targeted llama.cpp reliability fix. Pi was sometimes rebuilding its model catalog without retaining a model’s live context-window setting. When a locally hosted model was unloaded, an autoload preset could overwrite the cached runtime value. The repair preserves the previously known per-model context window during refresh, while still prioritizing a live server value or an explicit context-size argument. That directly addresses a report that local models configured for 65,536 tokens could revert to a default-looking 128,000-token window.

Finally, a macOS usability fix merged yesterday changes how Pi handles files copied in Finder. Pasting a copied image file previously could insert Finder’s generated file icon rather than the actual file path. Pi now reads copied file URLs first, inserts usable paths, quotes them appropriately in Bash mode, and retains image and text fallbacks.

The larger pattern is Pi making its increasingly flexible stack more controllable: extensions can be selectively governed, models can be routed by policy, local-server settings survive refreshes, and terminal interactions better reflect user intent. Thank you for listening to Pi Project Update from The Daily FM. See you tomorrow! [2]

Here is today's Pi Project Update for Monday September 28th. Pi’s latest commits focus on model-catalog maintenance after upstream providers removed older Kimi offerings. The coding agent now moves its OpenCode Go default from Kimi K2.6 to Kimi K3, while related AI tests have been updated for the retired model. A separate catalog adjustment keeps Pi’s Fireworks default available even when the external models.dev data omits it, and refreshes Fireworks test expectations. For users, this is quiet but important maintenance: default model choices and generated catalogs need to remain usable as provider inventories change.

Yesterday’s issue activity also surfaced a potentially serious long-session failure mode. One report describes an output-length cutoff producing more than 21,000 persisted tool calls, most of them empty duplicates. On replay, Pi can resend that malformed history unchanged; if a provider rejects it deterministically, the agent reportedly retries the same invalid request rather than identifying the session as damaged. The report also flags that a missing explicitly named session can silently become a new empty session. These are reports, not confirmed fixes, but they underline how token-limit handling and recovery paths deserve special care.

Performance is another recurring theme. Reports from extension-heavy setups say every newly created session reloads extensions, turning a roughly four-second minimal startup into waits exceeding 280 seconds in one command-line case. Related web-interface tests describe new-chat operations degrading beyond 140 seconds and spiking CPU after repeated session creation. Proposed remedies center on caching extension-load and model-runtime work per process, rather than repeating it for every conversation.

Finally, several terminal resilience issues were raised yesterday: closing a terminal or multiplexer pane can reportedly log an avoidable stdin EIO crash; a Windows transcript may jump back to the top during responses; and a model-issued PowerShell cleanup command can kill Pi’s own Node host, leaving a frozen-looking interface.

The trend is clear: Pi’s model defaults are adapting quickly, while community testing is increasingly focused on dependable operation at scale—long histories, many extensions, remote terminals, and sessions that must recover safely when something goes wrong. Thank you for listening to Pi Project Update from The Daily FM. See you tomorrow!

Here is today's Pi Project Update for Sunday September 27th. Yesterday, Pi merged a major refresh of its terminal theming system. The new default “system” theme derives colors from the terminal itself rather than simply trusting a light-or-dark signal, and it adds OKHSL color support for more perceptually consistent palette calculations. The change touches first-time setup, settings selection, syntax highlighting, and the interactive interface, so it is a broad visual foundation rather than just a new color scheme. For users moving between terminals, operating systems, and custom color profiles, Pi should make more reliable choices about contrast and appearance. [1]

A second development is a growing concentration of reports around local and OpenAI-compatible model servers. New issue reports describe print mode sending a one-token maximum to models marked as non-reasoning, failing to forward configured maximum-token values, and ending an agent run prematurely when no tool call arrives. Separately, users running llama.cpp report incorrect context-window values being restored or displayed after a session resumes. These are reports, not confirmed merged fixes, but together they highlight where Pi’s increasingly flexible provider support still needs careful configuration and request-handling work.

Long-session reliability is another clear concern. One report filed yesterday says a large live provider context can lose nearly 100,000 tokens at a user-turn boundary without an apparent compaction event, even though the session tree remains intact. Another identifies a crash-on-resume path when compaction usage data lacks a cost field. These cases matter because the transcript may appear healthy while the context actually sent to the model, or the interface rendered on resume, behaves differently.

Finally, Pi’s extension ecosystem is asking for stronger observability. A newly closed proposal notes that extension-internal model calls can bypass normal provider lifecycle events, leaving tracing tools unable to record token usage, latency, model choice, or errors. Related telemetry proposals seek request spans on Pi’s classic agent path.

The trend is clear: Pi’s surface experience is becoming more adaptive, while the next operational priority is making providers, long-running sessions, and extension-driven model calls equally inspectable and dependable. Thank you for listening to Pi Project Update from The Daily FM. See you tomorrow!