Expose the current provider usage via mcp

[St4NNi]

Now that Orchestrator V2 is available, would it be possible for the MCP server to expose each configured provider account’s remaining quota for the 5-hour and weekly usage windows, alongside the provider list?

I use multiple Codex and Claude accounts, and it would be helpful if the orchestrator could use this information when delegating tasks to sub-threads. For example, could it automatically select the account with the most quota remaining?

I searched for similar discussions but couldn’t find one. Is this something the current provider integrations could support?

[alexcamlo]

I was just looking for this functionality today.
It would greatly improve how the orchestrator thread give weight to what model to use when creating sub-threads

[shrreku]

Adding a concrete multi-account orchestration use case, after checking the current implementation proposals on 16 October.

A coordinator should be able to read each configured instance's cached session and weekly observations without inspecting provider cache files or starting a model call. It can then apply the user's reserves and active-work cap locally, and pass an exact instance to delegate_task. Policy and dispatch authorization can remain outside this read-only tool.

The useful minimum contract is:

• Stable instance identity matching orchestrator_capabilities and dispatch targets, with both accounts kept distinct.
• Reported window kind, utilization, reset and observation time; explicit missing, stale or unavailable values.
• Clear separation between account-wide quota, per-thread token counters and active-task counts. Do not treat multiple views of one account as independent capacity.
• No automatic refresh, model invocation, account fallback or credential/path exposure.

A passed reset is not a fresh usage reading, and fresh session capacity does not remove a weekly constraint. Fixtures should cover all of those cases, including denied access and verifying zero provider invocations.

I saw that #17219 implemented much of this but was closed because explicit maintainer approval was missing; #15465 is also closed and unmerged. I am supporting this existing discussion rather than filing a duplicate feature issue or claiming the proposed tool shipped. Could maintainers confirm a small read-only scope before anyone restarts implementation?

Prepared with GPT-6.1 Sol through the Codex harness in T3 Code at the user's request.

[HugoVizcainoSantana]

Dev from #17219 here. Would love to keep iterating further on it as needed, as I am testing the integration of T3 with ChatGPT Voice to control it from there, and sometimes it would be useful knowing the remaining usage on the go so that I can redirect some request to a different provider.