Working toward greater efficiency in orchestration context

[jwinpbe]

I'd like to help make T3 easier to adopt across providers, including open weight models, by tightening the context its orchestration adds. I've had good results using deepseek-harness through ACP for delegated research and verification. I want that workflow to work well across a wider range of models without requiring the most capable frontier model. Models running on local hardware are another use case for keeping that overhead modest, and reducing context overhead will also help adoption by allowing users like me running on $20-tier subscriptions to run more sessions for longer while bringing in cheap open weight models to do less vital / mechanical tasks.

Orchestration v2 is still early, and I've found it robust in use. My goal is to refine its context management to improve model performance and leave more room for the user's work. I know maintaining all those providers and clients gives you a lot to cover. I'd like to make that work easier by bringing focused fixes, measurements, and clear reproductions.

The catalog mismatch is already reported in #17202, where I'm proposing a fix that filters browser and device tools by the authenticated credential's capabilities. Its discovery tests provide a baseline for checking that further context reductions preserve tool access and session isolation. That fix has its own scope; this discussion asks for direction on the next improvements.

A separate concise-guidance prototype reduced orchestration instruction text from 1,513 to 1,197 tokens using the o200k_base reference encoding: 316 tokens saved, about 21% of that block. It makes scheduling/workspace detail configurable and keeps the existing detailed guidance as the default. The prototype is based on an older main revision and needs adaptation. The measurement covers instruction text only; tool schemas, provider prompts and conversation history are excluded. Actual provider-token savings and model-performance effects remain to be measured.

I propose starting with two steps:

1. Measure the tool definitions and orchestration guidance T3 contributes to real provider turns, including the ACP/deepseek-harness pipeline. Account for deferred tool discovery so we can identify overhead the model actually receives.
2. Use those results to choose the next reduction: refine the concise scheduling/workspace option or remove confirmed duplication between shared and provider instructions. Preserve existing defaults, check overlapping upstream work, and submit independent fixes separately.

Would you support this direction, and which part would you prefer I tackle first? I'd agree on the behavior and scope before expanding the implementation and link that approval in any resulting PR. The aim is to make T3's existing orchestration more efficient and easier to adopt, with changes you can assess one at a time.

Note

Written with GPT-6.1 Sol (Codex) at my request, and reviewed, edited, and approved by me.

[adam-ce]

not sure it's the right place, but there should be options to disable at least some of this orchestration.

codex is telling me, that it's impossible to disable. the scheduling messages are huge and are cluttering my chat window. codex used to do it and it did it just fine. now i think, these messages ate my 20 dollar quota (not a power user, only 1.6k per month).