Expose Pi extension Fast/Priority mode in the model controls with synchronized session state

[jlrochin]

Summary

Could T3 Code expose a Fast/Priority control for Pi sessions when an installed Pi extension supports it, and keep that control synchronized with the actual extension state?

This is a request for maintainer guidance and approval of the direction before implementing anything. It is not a report that Pi's RPC integration is broken, and it does not assume Fast is a built-in Pi RPC capability.

The existing slash-command workflow works in my installation. The missing capability is a discoverable UI control and a reliable indication of the state that is actually applied to requests.

Environment

• T3 Code: 0.0.46-nightly.20261003.2610 (including the running background service).
• Pi: 1.0.0.
• Pi extension: @pi-plugins/fast-mode, loaded through a local wrapper extension (fast-footer.ts).
• Example model: GPT-6.1 Sol.

The local wrapper preserves the package's command handlers, eligibility checks, and request handling. It also records /fast choices in Pi session entries and replays them on session startup. This persistence is local customization, not something I am claiming T3 or the upstream package already guarantees.

Current behavior and evidence

1. Select Pi as the provider in T3 and select a supported model.
2. The model controls expose Thinking/Effort, but do not expose a usable Fast setting for this Pi integration.
3. Send /fast on through the T3 chat.
4. Pi executes the extension command and reports:

{
  "message": "Fast mode is on for GPT-6.1 Sol.",
  "notifyType": "info"
}

The installed extension supports explicit commands:

/fast on
/fast off
/fast status

It also registers a boolean --fast startup flag. That can set the initial preference, but does not by itself provide live UI control or synchronization.

What the extension actually does

Inspection of the installed package shows that its before_provider_request hook adds:

{ "service_tier": "priority" }

when Fast is enabled, the selected provider/model is in its configured allowlist, the API is supported, and the outgoing payload's model matches the selected model. The installed implementation supports openai-responses and openai-codex-responses and does not overwrite an existing service_tier field.

This means the extension has a real request-level mechanism, not just a cosmetic status message. However, the notification and source inspection are not proof that a remote server honored Priority on a particular request. I have not captured live request/response tier evidence or benchmarked latency.

Why the T3 control is currently missing

Inspection of the installed T3 runtime shows that Pi model capability discovery exposes the thinking option, and the selection application path sends set_model and set_thinking_level RPC requests. I did not find equivalent Fast extension discovery or state application in that path.

This observation is about the installed nightly, not a claim that every current branch or future release has the same limitation.

Desired user experience

For a Pi session with a compatible extension:

• Show a Fast/Priority control alongside the existing model options.
• Enable or disable Fast in the existing Pi process for that thread, rather than in a separate probe process.
• Reflect the confirmed extension state instead of merely storing a frontend preference.
• Update the UI when the user runs /fast on, /fast off, or /fast manually.
• Refresh eligibility when the model changes.
• Restore or re-query state on reconnect, session resume, or process restart.
• Clearly distinguish requested/enabled, eligible, and actually applicable states. If server-confirmed tier information is unavailable, do not imply that the server has confirmed Priority.
• Keep ordinary Pi installations without this extension working exactly as before.

The control should not imply that Fast means lower thinking effort. Nor should it promise a particular response time. The package describes this as faster, costlier inference, so any UI wording should acknowledge provider-dependent cost/usage implications.

Possible implementation direction (for discussion, not a prescribed design)

1. Discover support instead of assuming it

Pi RPC command discovery can reveal that a fast command exists, but a command name alone is not enough to guarantee compatible semantics or determine model eligibility. Another extension could register a command with that name.

A reliable solution would likely need an explicit, versioned capability/state contract with a supporting extension or bridge. The exact transport should follow maintainer guidance; I am not proposing that Pi already has a standard set_fast_mode RPC command.

2. Reuse the existing extension logic

Avoid duplicating its model allowlist and request transformation in T3. For a first implementation, explicit actions equivalent to /fast on and /fast off could reuse the extension's handler, subject to the chosen bridge contract.

Use idempotent on/off actions rather than a bare toggle, so retries and reconnects cannot accidentally invert the state.

3. Synchronize using structured state

A supporting bridge could expose versioned state such as enabled preference, model eligibility, and an inactive reason. These are proposed fields, not existing Pi RPC fields.

Do not parse human-readable notifications such as “Fast mode is on” as the long-term state protocol. UI changes should wait for confirmation and handle unsupported extensions, failures, and timeouts without displaying false success.

4. Keep session behavior explicit

Apply commands to the correct live session and serialize them safely with session/model changes. Either disallow changes during an active request or document precisely that they apply to subsequent requests.

Persistence should have one clear owner and should not cause T3's saved preference to silently override a command issued directly in Pi.

Focused acceptance tests

• Compatible model + Fast on: verify that a mocked outgoing request receives service_tier: "priority".
• Fast off: verify that this extension no longer injects the tier, without removing or overwriting a tier supplied elsewhere.
• Unsupported model/API or absent extension: no falsely active control and no unintended request mutation.
• Manual slash command: UI state updates to match the extension.
• Model switch, reconnect, and resume: correct state and eligibility, with no accidental double toggle.
• Command failure/timeout: show an error or unknown state rather than optimistic success.
• Multiple threads: changing one session does not change another.
• Existing Thinking/Effort controls continue to work independently.

A PR would also include before/after UI evidence and a clear statement of what was verified against a real provider versus mocks.

Questions for maintainers

1. Would you prefer a focused integration with a supporting Fast extension, or a generic mechanism for exposing Pi extension settings in model controls?
2. Is an extension-specific capability bridge acceptable, or should a reusable options/state protocol be established upstream in Pi first?
3. Should T3's existing Fast/service-tier option be reused, or should extension-owned controls be presented separately to avoid conflating semantics?
4. Where should session persistence and state ownership live?
5. Is this direction in scope for an external contribution? If so, what is the smallest acceptable first step?

Related work and search

• #14688: Pi 1.0 compatibility, already merged; not Fast UI integration.
• #11664: Fast bolt presentation; not support for Pi extension state.
• #13777: older Pi integration proposal, closed after the V2 transition. The maintainer's closing comment requests focused proposals against current main for remaining gaps.

I searched issues/PRs for Pi with fast, fast-mode, fastMode, priority, and service_tier, and searched Discussions for Pi + fast. I did not find a dedicated proposal for this specific integration.

No T3 implementation or PR has been made yet. The current workaround is to continue using /fast on, /fast off, and /fast status in the Pi-backed chat.