Orchestration MCP: typed provider signals (quota/reset, throttle/retry-after, context) and effective modelSelection confirmation

[jltps]

Context. I run a local orchestrator that launches agent-phase threads through the T3 orchestration MCP (t3_thread_launch with modelSelection, t3_thread_read, t3_thread_interrupt, t3_thread_send). It has to fall back from a primary model to a reservation on a different provider when the primary is unavailable (long quota), without creating a second writer or repeating side effects. I would rather wait safely than infer signals from error text, and today that is the only option.

What the MCP exposes today (T3 0.1.3, Pi 1.4.0). modelSelection.options is accepted on launch, but nothing publicly confirms the options/provider that a run is actually using. Errors arrive as flattened text. t3_thread_read distinguishes live and terminal runs, but interrupt_requested is not a terminal state, and nothing states whether a thread still has writer children/tools. Same-thread continuation via t3_thread_send works, but it carries no provider/options selection.

Requests, in order of what unblocks the most:

1. Typed quota signal with reset. A structured failure descriptor for "provider quota exhausted", including a reset instant (absolute) and a discriminator from generic errors, instead of only text.
2. Typed throttle with retryAfterMs. So a caller can wait on the service clock and continue the same attempt, without launching another thread or running its own poller.
3. Public context/compaction state. Whether an attempt is near the context limit and whether compaction/continuation is supported for it, so a caller can continue the same attempt rather than open a new one.
4. Terminal proof for writers. A run read that states the run is terminal and that no child agents/tools/background commands can still write. A documented "interrupt requested" is not enough, and file mtime/margins are heuristics a caller cannot certify.
5. Effective selection confirmation. The model/provider/options a thread is effectively running with, comparable field-by-field to what was requested, plus an explicit "not verifiable" answer when the harness cannot report it.
6. Continuation across providers. Either a supported resume that transports provider/model/options, or a documented statement that a cross-provider continuation must be a new thread with a checkpoint.

Why the shapes matter. With 1–3 plus 4 a caller can do exactly one switch: mark the primary ineligible until reset, prove the predecessor stopped, checkpoint the worktree, and launch one reservation on another provider. Without 4 and 5 the switch cannot be certified, so the safe behaviour is to wait with a visible cause — which is what I do now.

Happy to share the exact MCP request/response pairs (redacted) or a minimal reproduction against a disposable instance. No credentials or account data are included here.