[Bug]: Pi turns fail when the provider ID contains a "/" #32575

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Register a Pi provider whose ID contains a /. pi-llama-cpp does this by default: each server gets the provider ID llama-server=<url>, for example llama-server=http://192.168.0.2:8080.

2. In T3 Code, start a Pi thread and pick the model from the picker, for example llama-server=http://192.168.0.2:8080/gemma-4-12b-it-qat-q4_0. The picker lists it because model discovery loads extensions.

3. Send a message.

You can reproduce the Pi step without T3. The first command sends the values T3 sends today. The second sends the provider and ID that get_available_models reports:

cd "$(mktemp -d)"   # with slash-provider.ts from step 1 in this directory

echo '{"id":"1","type":"set_model","provider":"demo=http:","modelId":"/127.0.0.1:9/demo-model"}' \
  | pi --mode rpc --no-session --extension ./slash-provider.ts
# success: false, "Model not found: demo=http://127.0.0.1:9/demo-model"

echo '{"id":"1","type":"set_model","provider":"demo=http://127.0.0.1:9","modelId":"demo-model"}' \
  | pi --mode rpc --no-session --extension ./slash-provider.ts
# success: true

Expected behavior

Every model the Pi picker lists can be selected and used. T3 should send set_model with the same provider and id that get_available_models returned for that entry.

Actual behavior

The turn fails to start:

Pi RPC set_model failed: Model not found: llama-server=http://192.168.0.2:8080/gemma-4-12b-it-qat-q4_0

The error is misleading. Pi joins provider and modelId back together with a / when it prints them, so the message shows the exact slug the user picked. It looks like the model doesn't exist, but the provider and model ID were split at the wrong place.

Cause, on main @ e455200:

• packages/provider-pi/src/server/status.ts:122: discovery builds the slug as `${provider}/${id}`.
• packages/provider-pi/src/server/rpc.ts:61: parsePiModelSlug splits that slug at the first /. For the slug above it returns:
  • provider: llama-server=http:
  • modelId: /192.168.0.2:8080/gemma-4-12b-it-qat-q4_0
• packages/provider-pi/src/server/adapter.ts:2570 (starting a turn) and textGeneration.ts:64 send those values to set_model.
• Pi's RPC set_model handler looks for a model whose provider and id both match exactly, so it finds nothing.

Splitting at the last / would not fix it. Model IDs can contain slashes too, for example provider openrouter with model openrouter/auto. When both parts can contain /, the slug alone is ambiguous.

Possible fix: discovery already stores each model's provider as subProvider. Look up the discovered entry whose slug matches and send its provider and id. Use the first-/ split only for slugs that aren't in the discovered list. Another option is to carry provider and model ID as separate fields in the model selection.

Impact

Blocks work completely

Version or commit

main @ e455200

Environment

Debian 13 (trixie), Linux 7.0.14 x86_64, Node v26.13.0. Pi 1.5.0

Logs or stack traces

PiRpcError: Pi RPC set_model failed: Model not found: llama-server=http://192.168.0.2:8080/gemma-4-12b-it-qat-q4_0.
    at PiRpc.request
    at PiAdapter.startTurn
    at RunExecutionService.startRootRun
    at ProviderTurnStartService.start
    at OrchestrationEffectExecutorV2.execute

Screenshots, recordings, or supporting files

No response

Workaround

Give the provider an ID without a /. In pi-llama-cpp, its by setting a custom id for the server in ~/.pi/agent/settings.json so it replaces the default llama-server=http://192.168.0.2:8080 with something like local