Isn't context size one of the central motivations of the whole agent / orchestration business - fanning out increasingly detailed work to a tree of subagents.
Orchestrator vs worker, hierarchical multitier trees, etc.
I guess this smaller context but faster llm engine could be good to develop your harness on to get faster results and faster iteration.
128k isn't even big enough to give a sub-agent a specific task on some very 'small' projects I work on, based just on the size of the python to work with (including extensive comments in the code) and documentation files, it'll run out of context before it can even accomplish one thing and report back to the main orchestrator.
128k is pretty much only good for chat/conversational/question asking (including tool calls for searching things and spitting back/parsing a set of results) or human interactive agent purposes.
One of the most boring tasks to give to a subagent is to make it run cargo test and summarize the result so that the main agent doesn't get polluted by the irrelevant tests.
You have to have a pretty inefficient use case for a subagent to think that 128k is not enough.
128k tokens is about 12-20k lines of code/prompt right? Or more than an average novel. And you don't need all the source code or entire files in the context after all.
I wonder what the approximate context window of a human programmer is... less than 12k lines I'm sure.
It is common for the agent tools, MCP tool, skills, project context and system prompt to take between 5k and 25k tokens. This depends heavily on your agent and tool setup.
But that's before the prompt.
Then after the prompt, every tool call the agent makes adds to the context. Longer turns can easily consume 50k-100k tokens between the agent and various tool calls (reading the filesystem, reading files, reading compiler output, reading memories).
Then each "turn" with the agent stays in context and is fed into the next turn. Two or three turns and you're up near 250k.
I actually decided to run YOLO mode once on GPT 5.6 Luna setting it to the fastest speed and I struggled to fill up the context while I kept sending several dozen feature prompts in the same session.
Tokens are also occupied by the internal reuslts of 'thinking', for instance, using the latest opencode, give qwen 3.8-flash-next with 'high' thinking mode 50KB total of python to read in six different files, count the expected tokens you'd expect it to occupy in just the size of the python. Then count the actual token count taken up after it's finished thinking about the contents of the python and analyzing it before you give it a single directive.
I guess this smaller context but faster llm engine could be good to develop your harness on to get faster results and faster iteration.