JournalEngineering

Field guide / 7

Subagents lowered peak context on 95.3% of GPT-5.3 Codex tasks, but used more tokens

A 64-task study found fresh subagent contexts helped when skills had explicit input/output contracts, trading lower peak context for higher total token use.

Sep 11, 20267By ISH Team
Subagents lowered peak context on 95.3% of GPT-5.3 Codex tasks, but used more tokens
Advertisement

Subagents lowered peak context on 95.3% of GPT-5.3 Codex tasks, but used more tokens

Delegating work to a subagent can look like an elaborate way to load an instruction file. A new study finds that the two mechanisms solve different problems. A skill gives the main agent more knowledge inside its existing context. A subagent moves a procedure into a fresh context and returns only the result.

That separation helped on long tasks, but only when the procedure had a clear interface. In the strongest reported context result, subagent execution gave GPT-5.3 Codex a lower peak context length than direct skill execution on 95.3% of tasks. The subagent runs also consumed substantially more tokens overall.

The September 7 preprint Subagents vs Agent Skills suggests a practical rule: delegate procedures that can be described as a contract. Keep loosely structured reference knowledge in the main context.

A skill and a subagent expose the same knowledge differently

An agent skill is usually a folder containing a description, an instruction file such as SKILL.md, and supporting resources. The public Agent Skills specification defines the package format and its progressive loading model. An agent first sees the skill's name and description, then loads the full instructions when the skill is relevant.

In the paper's direct-skill condition, those instructions enter the main agent's context. Tool results and intermediate reasoning continue to accumulate in the same window. The main agent can mix the skill with everything else it knows, but every later decision must process a longer record.

The subagent condition starts another instance of the same base model. That new context receives the skill instructions and a task input. Its internal trajectory stays outside the parent context, and only its final response returns. The parent sees less material, while the system pays for a second conversation and repeats whatever background the subagent needs.

This setup is closer to a function call than an extra pair of hands. It does not require parallel execution. Its purpose is to control which information crosses the boundary.

The comparison used 64 SkillsBench tasks

The researchers built on SkillsBench, which contains 87 long-horizon tasks across eight domains, paired with human-authored skills and deterministic verifiers. They ran the experiments through a modified OpenHands harness.

Most curated SkillsBench packages described useful knowledge but did not clearly state what input a skill expected or what output it would return. To test subagents under a stronger interface, the researchers generated a second skill set from successful task trajectories. They produced procedural packages for 64 of the 87 tasks, and the paper's main results use that subset.

Each package description contained an input contract, a short purpose, and an output contract. Instructions inside the package described how to transform a valid input into the promised result. A PDF-editing skill, for example, should say which file and requested change it needs, then define the artifact or report it returns. "Use this when working with PDFs" is discovery metadata rather than a delegation contract.

Seven base models were tested, spanning Ministral-8B, Gemma-4-12B, Qwen3.5-9B, Mistral-Large-3.1, GPT-5.4-mini, Kimi-K2.6, and GPT-5.3 Codex.

Contracts changed which execution mode won

With the original curated skills, direct skill execution matched or beat subagents across every tested model. Moving vague reference material into a fresh context did not make it easier to use. The subagent had to infer the task boundary and return shape while missing information held by the parent.

The result reversed with the procedural packages. When descriptions specified inputs and outputs and the instructions implemented that contract, subagents outperformed direct skill execution across the models in the paper's main figure. The gain was largest for smaller models, which the authors describe as more constrained by context bandwidth.

"Use subagents for long tasks" is too broad. A subagent works well when the parent can hand it a self-contained request and recognize a complete response. A style guide, project history, or collection of exceptions may belong in the parent context because its value comes from combining it with other information.

The paper also added up to 263 distracting skill descriptions that were unrelated to the task. Direct skill execution degraded more sharply as the menu grew. Subagent execution was more stable because selected instructions and their internal traces stayed outside the parent window.

That finding connects to BLOGish's look at Seahelm's interrupt queue. More workers do not automatically improve a system. The handoff protocol, visible state, and return path determine whether delegation reduces confusion or adds another source of it.

Peak context fell while total token use rose

For GPT-5.3 Codex, the subagent path had lower peak context on 95.3% of tasks. The chart reports 79.7% for Kimi-K2.6 and 70.3% for GPT-5.4-mini. Results were weaker for the smaller models, ranging from 28.1% to 59.4%, with Mistral-Large-3.1 at 32.8%.

The weaker-model comparison needs care. The paper says direct-skill runs sometimes terminated early after reasoning degraded. A failed run can have a short context because it stopped working, not because it managed information well. Peak context is most meaningful when success rates are similar.

Subagents used more total tokens for every model shown. The parent has to package a request, each worker starts with its own instructions and background, and the result travels back. Context isolation reduces the largest window any one model call must process. It does not minimize aggregate inference.

Teams watching cost, latency, or energy should include this tradeoff in the evaluation. Completed tasks per dollar or per minute tell them more than the smallest context screenshot.

Write delegation interfaces like APIs

A reusable procedure is a good subagent candidate when four questions have crisp answers:

  1. When may the parent invoke it?
  2. Which files, facts, permissions, and constraints must the parent supply?
  3. What work happens inside the delegated context?
  4. What exact artifact, status, or evidence must come back?

The output contract should be small enough that the parent does not need the worker's whole transcript. Return a patch and test result, not every search query. Return extracted table data with page references, not a diary of the PDF inspection.

Failure behavior belongs in the contract too. A worker should distinguish "completed," "invalid input," and "blocked" in a form the parent can route. Without that distinction, a concise return can hide an unfinished task.

Teams can use ish.chat to review these interfaces and api.ish.chat to compare direct-skill and delegated runs across models. Log parent tokens, worker tokens, peak context, latency, skill calls, verifier outcome, and failure category. The paper shows why a pass rate without token accounting is incomplete, and why token totals without task completion are equally weak.

Generated skills need the same discipline. BLOGish previously covered TRUSS shadow runs, which test learned procedures before they touch a live system. A contract gives those tests something concrete to verify.

The study does not settle every orchestration choice

The comparison used a modified OpenHands setup and a synthesized skill set available for 64 tasks. The authors extended the subagent tool timeout from five minutes to two hours, removed native OpenHands skills, disabled automatic skill retrieval, and replaced the default system prompt. Results may change under other harnesses and time budgets.

The synthesized packages also differ in content from the curated packages, so their quality cannot be compared as if interface design were the only variable. The paper says this explicitly. Its subagent-versus-direct comparisons are cleaner within each package set.

The experiment does not show that every skill should become a subagent. Its supported case is narrower: procedural knowledge with explicit inputs, a checkable output, and enough context pressure to justify extra tokens. A task without that interface is not ready for this form of delegation.

#subagents#agent skills#context windows#SkillsBench#agent architecture
Advertisement

Keep reading

Related stories

Browse the archive