Alibaba's Qwen Code showed a striking direction in its mid-September releases. Three releases — v0.23.3, v0.23.4, and v0.24.0 — bundled 267 PRs, but the headline was not a single feature. It was a structural change:

Qwen Code hands subtasks to Claude Code and Codex.

Coding agents have started calling other coding agents. This post covers what changed and how to take it into real work.

What exactly is subagent delegation?

You just say this in the chat window:

use the claude-code subagent to review this module

The subtask then runs on the Claude Code side, using your logged-in account and model. Qwen Code keeps the session's permission management and result collection, and you still see a single conversation stream. Qwen Code assigns the work, manages permissions, and collects results. Both subagents run in the foreground by default.

The difference is in default permissions:

Codex — read-only by default
Reads code and gives opinions.
To touch files, turn on the session's auto-edit/YOLO
or grant write access explicitly in the subagent definition.

Claude Code — supports several rounds of back-and-forth
You can go back and forth mid-task.
Codex takes one task and returns one answer.

It works out of the box on macOS and Linux, with guidance to use WSL on Windows.

There is also a path for attaching other agents. You write an executor block in a subagent definition file under .qwen/agents/ with the command to run. The plan is to connect external agents that speak ACP through this path. Frontmatter field compatibility with Claude Code 2.1.168 is also being aligned, so fields like permissionMode, maxTurns, color, mcpServers, and hooks are interpreted with the same meaning.

The clearest usage examples are the ones straight from the docs:

- Hand code reviews or revised plans to Claude Code or Codex
- Let Codex read the repo and comment read-only
- Decide file-change permissions case by case

Budget controls shipped together — and that is the point

This release is more than one integration because budget controls shipped in the same bundle:

- Call workflows by name
- Set token, round, and time limits on agent work
- Goal turn limits, model and group choice for scheduled tasks
- Web search call caps, cross-session messaging

Write a token cap like +500k after a message and the running flow plans its work against that cap, tightening up on its own as it gets close. The approval dialog now shows a structure preview before running: where subagents spawn, where work fans out in parallel, where round-trips happen. If the actual run comes in bigger than expected, an oversized-workflow notice appears.

In a structure where agents order agents around, you cannot guess how far costs will balloon without these caps. That is why delegation and budget features shipped in the same release.

Drawn as a diagram, the structure looks like this

Developer → one AI (before)

Developer → orchestrator (Qwen Code)
              ├→ Implementer (Claude Code, multiple rounds)
              ├→ Reviewer (Codex, read-only by default)
              └→ Test agent (runs builds and tests)
              ↓ result collection + permission management
          Verified change (now)

This is why the coding environment reads as moving from developer to orchestrator to specialist agents. Task decomposition, agent delegation, budget control, and verification become the engineering problems that matter — more than prompting a single model well.

One caution here. When you use the external subagent path, make it a habit to verify which agent actually ran. Changed files are not proof that the agent you wanted ran. Check independent traces together: the subagent metadata's model display, tool-call records in the transcript, and adapter processes.

CodeBridge Mini Lab: split the roles and compare

If you have a complex task, do not hand it all to one agent. Split it like this:

Implementer — the role that changes code
Reviewer — read-only, only points out problems
Test agent — runs builds and tests, only reports pass or fail

Compare more than quality:

Result quality + total cost + completion time + retry count

Start by handing reviews or plan revisions to an external agent, and you will get a feel for orchestration cost. As that feel accumulates, the claim that task decomposition, delegation, budget control, and verification matter more than good prompting starts to feel real.

Further reading

References

Go deeper with a course

If you want to move beyond prompts and practice designing agent systems as harness, loop, and graph structures, a five-step guided course connects directly to this orchestrator story.