Summary

• What broke: Archon's Pi integration does not respect Pi's normal settings.json configuration. The Pi provider embeds Pi's SDK in-process and creates the session with an in-memory settings manager, so critical Pi settings (e.g. provider timeout/retry configuration) may be bypassed even though Pi CLI/TUI honors them. This missing configuration results in failures (e.g. timeouts) that otherwise would not have occurred (i.e. the work would have completed eventually)

• When it started (if known): Unknown; observed in the current Archon Pi provider implementation.

• Severity: major

Steps to Reproduce

1. Configure Pi to use a local model provider.

• Note: I use Lemonade server, and found this issue when using a model that requires long prompt prefill times.

2. Configure Pi provider settings in Pi's normal settings file critical for correct behavior.

• e.g. increase retry.provider.timeoutMs and/or change provider retry behavior.

3. Configure Archon to use the Pi assistant/provider with the same local model.

4. Trigger an interaction that requires Pi to be correctly configured.

• Any Archon execution path that invokes PiProvider.sendQuery(...) is affected.
• In my case, I use the Archon Web UI chat to send a request that produces a long-running local model call (e.g. a large codebase/file-analysis prompt)

6. Observe that Archon Web UI chat will time out or fail

• Pi is not using the provider's timeout/retry settings in its configuration
• Note: The same model/interaction works correctly through Pi CLI/TUI when it uses the correct configuration

Expected vs Actual

• Expected: Archon's Pi provider should use Pi's normal file-backed settings for any settings not exposed/overridden/specified by Archon (or explicitely expose all equivalent configuration). Critical provider settings such as retry.provider.timeoutMs and provider retry behavior should apply consistently between Pi CLI/TUI and Archon.
• Actual: Pi's configured settings are ignored (e.g. in Archon Web UI chat), resulting in different behavior between the Pi CLI/TUI and Archon.

User Flow

User Archon Web UI Archon Pi Provider Pi SDK Local Model Server
──── ───────────── ───────────────── ────── ─────────────────
sends chat ──────────▶ routes to Pi assistant
creates provider/session
creates Pi session
with in-memory
settings manager ───────▶ skips file-backed
settings.json
sends model request ───▶ processes large prompt
long prefill / slow stream

                 [X] timeout/error ◀────── provider timeout/retry
                                          behavior does not reflect
                                          Pi settings.json

sees vague failure ◀── chat stops or reports error

Environment

• Platform: Web
• Database: SQLite / PostgreSQL
• Running in worktree? (Yes/No)
• OS: Linux / macOS / Windows

Logs

Example symptoms from my Lemonade model server (OpenAI-compatible):

POST /api/v1/chat/completions
Model already loaded:
POST /api/v1/chat/completions - Streaming
prompt processing progress, n_tokens = , progress =
...
CURL error: Timeout was reached
Streaming request failed: CURL error: Timeout was reached
stop: cancel task, id_task =

Additional possible client-side symptom:

CURL error: Failed writing received data to disk/application
Streaming request failed: CURL error: Failed writing received data to disk/application

Impact

• Affected workflows/commands: Archon Web UI chat using the Pi assistant/provider with local OpenAI-compatible models, especially large local models or long-context prompts that require slow prefill before the first streamed token.
• Reproduction rate: Intermittent / workload-dependent. More likely with large prompts, slow local inference, or local servers with long time-to-first-token.
• Workaround available? Partially. Users can increase local model-server timeouts and may be able to patch Archon's Pi provider to use Pi's file-backed settings manager instead of an in-memory settings manager. However, configuring Pi's normal settings.json alone may not affect Archon Web UI chat.
• Data loss risk? (Yes/No): No

Scope

• Package(s) likely involved: server|web|core
• Module (if known): packages/providers/src/community/pi/provider.ts; specifically the Pi provider session construction and settings manager wiring.