nicobailon/pi-web-access v0.38.0

on GitHub

This release adds Ceramic as a new search option and makes OpenAI search much cheaper by default. Answer mode and query rewriting now work with models whose provider signs in without an API key. Requests made through a proxy now keep their method, headers, body and Content-Length, and HEAD requests stay HEAD requests. Apps that run several Pi sessions in one process no longer lose search results between conversations.

Highlights

• Search with Ceramic, a new paid keyword search provider you can select.
• OpenAI search now defaults to the newest Luna model, which costs about 20 times less per token than Terra.
• Answer mode and query rewriting work with models whose provider signs in without an API key, such as pi-multiprovider models.
• Requests through a proxy keep their method, headers, body and Content-Length, and HEAD requests stay HEAD requests.

Need to know

OpenAI web_search now uses the newest Luna model (gpt-6-luna) instead of gpt-5.6-terra. Set openaiSearchModel if you want a different model.

Search summaries and fetch_content answer mode no longer send x-opencode-client, and custom providers pointed at opencode.ai no longer get OpenCode's session header from pi-web-access. Pi's built-in opencode and opencode-go providers still send the session header.

Changelog

Added

• New Ceramic search provider for Ceramic's keyword web search API, used only when you select it. Set ceramicApiKey or CERAMIC_API_KEY to your Ceramic key. Ceramic is a paid API with free starter credits, so it is never picked by auto or all. Allowed domains are added to the query as site: filters, and excluded domains are removed from the results. Ceramic has no date filter, so recencyFilter is ignored. Thanks to @sweepies for issue #523.

Changed

• The web_search tool description is now four sentences on how to use the tool, instead of a paragraph listing every provider, the all policy and each workflow mode. The model still sees the providers and the all policy in the provider parameter and the modes in the workflow parameter. Thanks to @mcwalrus for issue #528.
• OpenAI web_search now runs on the newest Luna model by default, such as gpt-6-luna on a ChatGPT subscription, instead of gpt-5.6-terra. Terra costs about 20 times as much per token as gpt-6-luna and is a generation older, so searches were using a large share of subscription usage. With only an API key, the default is gpt-6-luna. Set openaiSearchModel to pick a different model. Thanks to @sslotin for issue #520.
• Search summaries and fetch_content answer mode now give Pi the session ID and let its opencode and opencode-go providers add OpenCode's x-opencode-session header, instead of building OpenCode's headers themselves. They no longer send x-opencode-client, and custom providers pointed at opencode.ai no longer get the session header from pi-web-access. See issue #537.

Fixed

• With a proxy set, fetch(new Request(...)) now sends the Request's own method, headers, body, redirect setting and abort signal. It used to arrive as a bare GET without them. HEAD requests through the proxy are now real HEAD requests with an empty response body instead of GETs. Thanks to @xiaozhu1337 for issue #535 and PR #536.
• With a proxy set, HEAD responses keep the server's Content-Length, and a POST or PUT with no body sends Content-Length: 0 as native fetch does, instead of omitting it (which some servers answer with 411). See issue #539.
• Keyless Parallel MCP searches no longer fail with Parallel's "free-tier rate limit" error. Requests went out with Node's default undici User-Agent, which Parallel rate-limits as one shared bucket, so they now send User-Agent: pi-web-access. Thanks to @kestermcullough for PR #531.
• fetch_content answer mode and search query rewriting now work with models whose provider signs in without giving Pi an API key, such as models added by pi-multiprovider. Answer mode used to fail with "No API key available for answer model" even though Pi could call the model. Thanks to @eikopf for issue #530.
• A host that serves several conversations at once from one process, with one extension instance per session (an app or chat server built on the Pi SDK), no longer loses results across conversations. Each instance now keeps its own session's results, background fetches and active flag: one conversation starting or ending used to clear every stored result, so a get_search_content in another conversation answered "No stored results for responseId …", and its background includeContent fetches were aborted. Sessions forked from one history hold the results they share until the last of them ends, and deleting a shared result from /search removes it only from that session. Pi itself, which runs one instance and switches its session, behaves as before. GitHub clones are removed when the last live session ends, and while sessions keep overlapping, a session's end removes the clones no fetch has returned since the oldest live session started. A session that restores results from history marks the clones they point at as used, so a session forked from another keeps its clone paths after the original ends. Thanks to @kid7st for PR #521.
• @modelcontextprotocol/sdk is updated from 1.27.1 to 1.32.1, which fixes GHSA-6qxp-vccf-f47h, so npm audit no longer reports it. That advisory covers the SDK's OAuth client, which pi-web-access doesn't use: its HTTP providers send API keys in headers and its MCP server runs over stdio. Thanks to @M1racleShih for PR #522 and @SidShaytay for issue #519.