Codex Sub-Agent Debugging Log: Task Division and Acceptance Between Main Agent, Luna, and DeepSeek

When setting up multi-agent collaboration in Codex, the core goals are often more than one: save tokens, and let independent tasks run in parallel to shorten the overall delivery cycle. This article documents a real sub-agent debugging session, covering role division, call chain verification, task splitting principles, and several typical pitfalls encountered along the way.

Why Use Sub-Agents

The motivation for debugging sub-agents was straightforward — save tokens while letting independent tasks run in parallel. A single main agent can handle a full workflow, but its output speed tends to be slower, and once tasks pile up in series, the waiting cost multiplies.

The value of a multi-agent setup lies in separating "decision-making" from "execution": let the main agent focus on planning and quality control, while delegating specific implementation and investigation work to lower-cost, more focused sub-agents. This controls how often the expensive model gets called, while allowing mutually independent tasks to proceed simultaneously.

From a cost structure perspective, the economics of multi-agent setups come from "tiered model invocation." The main agent uses a high-capability, high-cost model (such as GPT-4o or Claude Opus), but its invocations are compressed to planning and acceptance stages. Sub-agents use lower-cost models for large volumes of repetitive execution tasks. Take DeepSeek^Ad Flash as an example — its API pricing is typically 1/10 to 1/20 of top-tier models, and when used for code review and investigative tasks, it can significantly reduce overall costs while keeping quality loss acceptable. The time savings from parallel execution are equally significant: if two independent subtasks each take 5 minutes, serial execution takes 10 minutes, while parallel execution takes only 5. However, this benefit requires tasks to be truly independent — any hidden dependency will degrade parallel execution back to serial, and may even be slower due to coordination overhead.

Clear Division Among Three Roles

This debugging session used a three-tier role structure with clearly defined responsibilities:

• Main Agent: Handled by the primary model, responsible for planning, task decomposition, and final acceptance. It's the brain of the entire workflow — it doesn't write large amounts of code directly, but decides "what to do" and "whether it's done correctly."
• Luna (Implementation & Fixes): Takes on well-defined implementation and bug-fixing tasks at the execution layer. The clearer the task definition, the more stable its output quality.
• DeepSeek Flash High (Investigation & Review): Engages via API for investigation and independent review. Handing review work to an independent model avoids the blind spots of "reviewing your own work."

The logic behind this division: the main agent controls the big picture and quality thresholds, execution tasks go to Luna, and investigation and cross-validation go to DeepSeek — each playing its own role.

How to Verify the Call Chain

The most common failure point in multi-agent setups isn't "can it run" but "is it actually running on the model and channel you think it is." This debugging session focused heavily on chain verification, specifically confirming three things:

1. Can the main agent actually create sub-agents?
2. Is the sub-agent actually using the correct model and inference intensity?
3. Can the sub-agent actually invoke tools?

The verification method was pragmatic: have the sub-agent read a specified file, return the result, then close — then cross-check the model identifier and actual request channel in the run logs. Only when this chain completes end-to-end is the sub-agent marked as "available." In other words, don't rely on intuition — use auditable run logs to confirm.

"Model identifier is correct" and "request actually reaches the target model" are two different things, and this is especially easy to confuse in multi-agent frameworks. The model name written in code (e.g., deepseek-chat) is an application-layer configuration, but which Base URL the underlying HTTP request actually goes to and which API Key it carries depends on Provider routing rules. Tools like OpenCodex support traffic splitting by model name prefix or provider identifier, but even a slight misconfiguration can produce a silent error where "the name says DeepSeek, but the request goes to an OpenAI endpoint" — no error thrown, but the bill and response quality are both wrong. When verifying the chain, the most reliable method is to directly inspect network logs or the framework's request records to confirm that the endpoint and model fields exactly match expectations, rather than inferring from the surface appearance of returned results.

Three Principles for Task Splitting

Whether parallel execution actually speeds things up depends on how cleanly tasks are split. Several highly practical principles emerged from this session:

• Each delivery should be an independently verifiable result: Clear task boundaries mean outputs can be individually checked.
• Tasks must not depend on each other: Avoid serial deadlocks where A waits for B and B waits for A — true parallelism requires this.
• Modified files must not overlap: This is a hard constraint for parallel execution — file conflicts directly destroy the parallel benefit.

Two more "don't delegate" lessons emerged: small things should be handled by the main agent itself, since spawning a sub-agent has its own overhead; purely read-only tasks also don't all need to be outsourced. More agents isn't always better — the cost of delegation and the benefit need to be carefully weighed.

Pitfalls We Hit

In practice, environment and configuration issues were far more draining than logical ones.

DeepSeek requests routed to the wrong channel: DeepSeek requests were at one point being routed to the OpenAI channel, which was eventually resolved by using OpenCodex for traffic splitting. This perfectly illustrates why "checking the actual request channel" is necessary — the model name being correct doesn't mean the request actually took the right path.

Provider misconfiguration preventing startup: A Provider configuration error once caused Codex to fail to start entirely, requiring a fallback to the web interface using a chat model to debug the Config. The configuration file is the foundation of the entire chain — when it's wrong, the blast radius is far larger than a single task failure.

Provider configuration errors have such a large blast radius because they typically take effect during global initialization rather than per-request. In Codex and similar frameworks, the Provider configuration file (such as ~/.codex/config.yaml or a combination of environment variables) is parsed once at process startup. Any YAML syntax error, field name typo, or API Key format issue can cause the entire runtime initialization to fail — not just affect a single sub-agent. The debugging challenge here is that the Codex CLI itself won't come up, so you can't troubleshoot through normal interactive flows. You're forced to fall back to more primitive methods — directly editing the config file, checking startup logs, or as described here, switching to web-based chat mode and using an external model to locate the issue. Therefore, when configuring a multi-Provider environment for the first time, it's advisable to validate incrementally item by item rather than writing everything at once before starting.

Summary

The core lesson from this debugging session can be distilled into one sentence: the value of multi-agent systems lies in clear division of responsibilities, verifiable call chains, and independently acceptable task outputs. The main agent handles planning and gatekeeping, Luna handles execution, and DeepSeek handles independent review — three-way collaboration that saves tokens and enables parallelism. What truly separates success from failure is usually the low-level details of channel routing and Provider configuration — before declaring it working, use run logs to verify every link in the chain.