[Bug]: Pi sessions on openai-completions gateways declare all ~83 T3 MCP tools on every turn (regression of #16651/#17220) #19190

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. Use a Pi provider instance on a custom OpenAI-compatible gateway (any provider whose Pi model api is openai-completions — e.g. a self-hosted LiteLLM/Bifrost/OpenRouter-style endpoint added to Pi's models.json).
2. Start a Pi thread (or delegate a task to Pi) and send any short prompt.
3. Capture the outgoing /chat/completions request body and count tools.

The tool catalog that #18643 activates is a pure function of the T3 MCP server, so this reproduces without a specific gateway: I measured it by pointing Pi at a logging proxy in front of the gateway, and independently by running Pi with T3's own bridge extension against T3's live /mcp endpoint.

Expected behavior

A Pi session on a completion gateway should declare the three orchestration tools that #17220 kept direct (orchestrator_capabilities, delegate_task, task_status) and leave the other ~80 T3 MCP tools discoverable through tool_search, as #17220 intended ("the initial request fell from about 88.7 KB to 16.4 KB").

Actual behavior

Every mcp__t3-code__* tool is activated on every turn, so all ~83 tool schemas are sent on every request, on every provider, regardless of whether the session ever uses them.

Measured on two builds of the same container (same gateway, same model, same prompt, one turn each):

Whole-request prompt tokens for the same one-line prompt went from 4,591 → 32,125. Breakdown of the 26k tokens of tool schema on the bad build:

This is the same prefix-bloat class #16651/#17220 fixed, now reintroduced on the openai-completions path.

Bisect: the activation is the block added in #18643 (4d768355, merged 2026-10-13T17:40Z):

...(ctx.model?.api === "openai-completions" ? catalog.map((tool) => "mcp__t3-code__" + tool.name) : [])

in reconcileDiscovery in packages/provider-pi/src/server/mcpExtensionSource.ts. Checking the compiled extension string in each published platform binary, the block is absent in ...3066 and present in ...3080; 3080 is the first affected nightly.

Impact

Major degradation or frequent failure

Version or commit

0.0.46-nightly.20261013.3080 (first bad; introduced by #18643 / 4d768355). Last good: 0.0.46-nightly.20261013.3066.

Environment

Ubuntu 26.04 container, T3 Code nightly server (t3 serve), Pi 1.2.0, Pi provider on a self-hosted OpenAI-compatible gateway (api: openai-completions), models opencode-go/*. Not desktop-specific — reproduced with the standalone server binary.

Logs or stack traces

Raw gateway request bodies, one short prompt each, same session config:


# 0.0.46-nightly.20261013.3066  (last good)
model=... api=openai-completions
token_usage: {"prompt_tokens":4591,"completion_tokens":60}
params.tools.length = 8
  read, bash, edit, write,
  mcp__t3-code__orchestrator_capabilities, mcp__t3-code__delegate_task,
  mcp__t3-code__task_status, tool_search

# 0.0.46-nightly.20261013.3080  (first bad)
model=... api=openai-completions
token_usage: {"prompt_tokens":32125,"completion_tokens":52}
params.tools.length = 93   (JSON.stringify(tools).length = 104769 chars)
  83 x mcp__t3-code__*   (preview_*, device_*, t3_thread_*, schedule_task, ...)
   3 x *_mcp_resource*    (Pi builtins, because the exa MCP server exposes resources)
   2 x mcp__exa__*
   5 x builtins


I also confirmed it is not caused by an `mcp.json` server: running the same config with and without an extra MCP server gives an identical `active=88` (83 T3 + 5 builtins) on the bad build.

Screenshots, recordings, or supporting files

No response

Workaround

--exclude-tools works but is per-tool and has to be kept in sync with T3's catalog:

--exclude-tools 'mcp__t3-code__preview_*'   # 93 -> 74 tools (26.2k -> 19.0k schema tokens)

Excluding the whole namespace (--exclude-tools 'mcp__t3-code__*') does drop it to ~5 tools, but that also removes delegate_task/task_status, so it is not a usable workaround for orchestrating threads.

One request about the tradeoff in #18643

#18643 deliberately traded request size for correctness, to stop completion gateways from silently swallowing calls to undeclared tools (#17500). That fix is clearly needed for gateways that drop undeclared tool calls — but it is applied to every openai-completions session, including gateways that route those calls correctly.

Concretely: on the gateway we use, a deferred T3 tool loaded through tool_search and then called works on the bad build — the call executes and returns a result, so the #17500 failure mode does not occur here, and we pay the full ~26k tokens for nothing.

Would you consider making this conditional? For example: keep the eager activation only when the gateway is known to need it (opt-in setting, or a per-provider-instance flag), or re-activate the schemas only for the specific tools named in the conversation rather than the whole catalog. Happy to help test a narrower version if that is useful — we can measure request size and the deferred-call path directly.