pi-ai-sdk

Implements version-correct Pi AI model, provider, streaming, and authentication integrations in Workbench.

2|Updated Aug 17, 2026
One-click install
npx skills add https://github.com/yyy0107/pi-workbench --skill pi-ai-sdk-yyy0107
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: pi-ai-sdk
Source: https://github.com/yyy0107/pi-workbench/tree/main/.agents/skills/pi-ai-sdk
Command: npx skills add https://github.com/yyy0107/pi-workbench --skill pi-ai-sdk-yyy0107

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires @earendil-works/pi-ai, and includes references (resource) components.

What problem does it solve? Integrating the Pi AI SDK into Workbench requires choosing the correct runtime ownership, import paths, and stream semantics; mistakes cause auth bypasses, broken message streams, or leaked credentials. This Skill guides changes to model, provider, authentication, message stream, and image-generation code so they match the installed SDK version and Workbench's existing architecture. ## Core Features & Use Cases - Source-of-truth routing: Resolves the installed @earendil-works/pi-ai version, export map, and declaration files before writing any import, avoiding drift against the local Pi source checkout. - Runtime ownership guidance: Directs reuse of the coding-agent ModelRuntime for configured providers and credentials, reserving standalone createModels() collections for isolated consumers or tests. - Stream and protocol correctness: Preserves AssistantMessageEvent versus PiMessagesEvent semantics, contentIndex routing, partial tool-call buffering, and Workbench's durable compact delta protocol. - Use Case: When adding a custom OpenAI-compatible provider to Workbench, follow the Skill to build a createProvider() definition with declared auth, wire it through the existing ModelRuntime, and test abort, auth-failure, and refresh paths with fauxProvider() instead of real paid API calls. ## Quick Start Use the pi-ai-sdk skill to add a custom provider and update the model streaming reducer in Workbench without making real provider requests.

Frequently Asked Questions about pi-ai-sdk

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a custom provider to the Pi AI SDK?▼

Create a provider with createProvider() declaring its auth semantics, model definitions, and a lazy API wrapper such as openAICompletionsApi(), then register it on a Models collection with setProvider(). In Workbench, prefer wiring it through the existing ModelRuntime rather than a second collection.

How do I consume AssistantMessageEvent streams in Pi AI?▼

Call models.stream() or streamSimple() and iterate the returned stream as an AsyncIterable, routing text, thinking, and tool-call events by contentIndex. Obtain the final message via stream.result() and inspect terminal events plus stopReason for failures.

What is the difference between AssistantMessageEvent and PiMessagesEvent?▼

AssistantMessageEvent is the live SDK stream event carrying a shared partial accumulator, while PiMessagesEvent is the serialized wire protocol used by Pi Messages backends. Workbench reuses the Pi Messages content-event subset for its durable compact delta channel and never substitutes raw stream events into it.

Can I import from @earendil-works/pi-ai/dist directly?▼

No. Import only from documented export subpaths: the package root, providers/*, api/*, utils/*, oauth, bedrock-provider, or bun-oauth. Direct dist imports bypass the export map and break when the installed version changes.

How do I test Pi AI integrations without real API keys?▼

Use the SDK's fauxProvider() scripted provider with createModels() to exercise collection and stream behavior, or structural fakes for Workbench's ModelRuntime adapter. Tests should cover interleaved content blocks, partial tool JSON, terminal events, and reconnect snapshots without network access or paid calls.

When should I use createModels() instead of the Workbench ModelRuntime?▼

Use createModels() only for an isolated SDK consumer, a custom host component with independent ownership, or a focused test. Product code should reuse the coding-agent ModelRuntime, which already owns configured providers, credentials, availability, and session request behavior.