The first LLM-based systems were designed around a simple premise: use the most capable model available and give it as much context as possible.
That works until tasks start to look like real work and grow to a certain size: whole repositories, migrations, research across many sources, or processes that run for hours. That is the point where you start thinking about several models, each with a job.
And that is where a different problem shows up. The question stops being which model to use and becomes which responsibility each model holds.
I have spent this whole week working with GLM 5.2 and DeepSeek V4 Flash 0731, and the combo is working pretty well for me. I used to do something similar with DeepSeek V4 Flash and Qwen 3.6, but the level has gone up quite a bit.
Here is what matters: a multi-model system takes more than chaining calls together. It needs responsibilities, interfaces and validation mechanisms between components. A model that understands the goal, designs a plan and makes high-level decisions. Specialised models that execute concrete subtasks fast and cheap. And a clear way to hand context and results between them.
In this article I use GLM 5.2 as the orchestrator and DeepSeek V4 Flash 0731 as the executor to explore this architecture. The pairing is not random, they have different profiles. GLM 5.2 is optimised for long tasks where holding a global view matters. DeepSeek V4 Flash is particularly interesting for running many tasks at high speed and low cost.
The real difficulty sits in the middle: the handoff. What was happening to me is that GLM 5.2 gave DeepSeek too much context, which sometimes got it confused, and when the task finished DeepSeek handed too much context back to GLM 5.2, which then processed a lot of input tokens and took longer.
When one model delegates work to another it cannot copy its whole conversation across and expect that to work. You have to decide which information is relevant, how the task is expressed and how the result comes back. Especially with these two models, where a context that is too large or too small is the difference between executing the task well and blowing up the bill.
The architecture rests on a simple idea: the orchestrator does not pass all of its context, it creates and passes work contracts.
From there come three basic implementation patterns, how to design those contracts, how to control costs, and when this architecture is worth it over a single model.
GLM 5.2 vs DeepSeek V4 Flash 0731: two profiles for two different jobs
A multi-model architecture starts by defining what work each one does.
Here the split is simple. GLM 5.2 acts as the orchestrator: it understands ambiguous goals, designs plans, decides which tasks to delegate and reviews results. DeepSeek V4 Flash 0731 acts as the executor: it receives well-defined tasks and resolves them fast and cheap.
Both models can solve complex problems, but they are optimised (or I use them that way) for different points in the process.
GLM 5.2: the one that holds the global view
Agentic systems have to hold a steady direction across many steps. These are long processes. That is why a model with plenty of context, specialised in long-horizon tasks, fits the role.
An orchestrator needs to hold the final goal through the whole run, break big problems into subtasks, decide which information is worth keeping, spot errors when they appear and adapt the plan as the context changes.
None of that implies the model executes each individual task better. It means it can keep coherence across many consecutive decisions.
It costs more, so using it for every small operation makes no sense. Its value is that the decisions are right and the goal does not drift.
DeepSeek V4 Flash 0731: the one that executes many times
The executor has a different problem.
It does not need to understand the whole mission. It needs to receive a well-specified task and complete it: modify a file, generate a test, analyse a document, transform data or implement a concrete function. In that scenario other properties matter: generation speed, cost per operation and the ability to run many tasks in parallel.
DeepSeek V4 Flash is aimed at exactly this: many calls, concrete tasks, high execution volume.
What this looks like in practice
The idea is to reserve the expensive reasoning capacity for the decisions that genuinely need it. One thinks and directs very well, the other executes very well. Any other way round, we overuse the most powerful models.
Bringing it down to something everyone knows: on an engineering team, a software architect does not come down to write every line of code, and you do not ask a junior developer to decide the whole architecture. Both roles are needed because they optimise different problems.
Something similar happens with LLMs, and that is why the useful question stops being which of the two models is better and becomes which part of the process belongs to each one.
Architecture patterns for orchestrating several models
Most useful systems start from a fairly simple architecture. Orchestrating models means introducing a coordination layer between the user's goal and the models that do the work. Before adding frameworks, execution graphs or complex memory mechanisms, what matters is understanding which information should travel between the models and where the state of the system should live.
Three simple, common patterns.
Pattern 1: planning and execution separated
This is the simplest pattern and, in many cases, the most effective.
The orchestrator receives the full goal, analyses the available context and generates a plan made of independent tasks. Each task carries the information needed to run it, the constraints it must respect and a way to check whether the result is correct.
An executor model then takes each task and works on it. When all of them finish, the orchestrator reviews the results and decides whether they meet the original goal.
The main advantage is simplicity. The flow is easy to observe and debug because every step has a clear input and a clear output. It also lets you exploit parallelism when tasks are independent.
A typical example would be a code migration. The orchestrator analyses a whole repository, detects the affected files and generates a set of migration tasks. Each executor works on one specific file, following the project's global conventions.
This pattern works especially well when the problem can be split before execution starts. Document processing, content generation, repetitive migrations or batch analysis are scenarios where it usually fits.
And this is the setup I use by default, with one caveat: when working with OpenCode, the harness itself uses the Task tool to assign work to the executor model, which is really pattern 2.
Pattern 2: the executor as a tool of the orchestrator
Instead of building the whole plan up front, the orchestrator keeps control during execution and uses other models as tools.
The flow looks more like a traditional agent. The main model analyses the situation, decides what information it needs, delegates a task and uses the result to decide the next step.
During a debugging session, for instance, the orchestrator can ask an executor to analyse one specific module, get back a hypothesis about the failure and use that to decide what to look at next.
This approach is more flexible because the plan can adapt as new data appears. It also makes the system more complex, since every executor result has to become useful input for the next decision cycle.
Contract design between models matters a lot in this pattern. If the executor returns too much irrelevant information, the orchestrator's context grows fast and the following decisions get worse.
Pattern 3: agents with shared state
The third pattern shows up when tasks stop being simple message exchanges and start to look like a whole project.
Here the agents share a common workspace. It can be a file system, a database, a code repository or any other mechanism where they can leave artefacts and inspect the work done by other agents.
An example would be an automated development system where one agent analyses requirements, another implements changes, another runs tests and another reviews the final result. Each one interacts with the same repository and leaves information for the next steps.
The advantage is that it avoids constantly hauling large amounts of context between models. Project state lives outside the conversation and each agent reaches only for the information it needs. The difficulty is designing what counts as shared state and who has authority to modify it.
The trade-off is that the system starts having the same problems as any distributed architecture. You have to manage versions, conflicts, partial failures and change traceability.
The handoff between models: designing work contracts
When one model delegates a task to another, a new boundary appears inside the system, and how that transition is communicated largely determines the quality of the result.
In an API-based architecture, models communicate through external representations: text, data structures or shared artefacts. That simplifies the technical integration, because any model with a compatible API can take part. The challenge is deciding what information should cross that boundary.
A common mistake, and the one I was making, is passing the orchestrator's entire conversation to the executor. It looks like the safe option because it preserves all available context, but it introduces three problems.
The first is relevance. An orchestrator's history contains discarded decisions, earlier exploration and results from other tasks with no bearing on the new run. The executor has to separate the useful information from the noise before it starts working.
The second is cost. Sending repeated information increases token consumption and makes every call more expensive, especially in systems that run many subtasks.
The third shows up with errors. If a task fails and its input context depends on a whole conversation, retrying it means dragging along the decisions and errors accumulated during that conversation too.
The answer is to treat every delegation as an independent work contract. The orchestrator turns its context into a specification another model can execute without knowing the full history.
The specification I have built has four elements:
- Goal. What result must exist when the task is done.
- Inputs. The data, files or resources needed to do the work.
- Constraints. The rules that cannot be broken: project conventions, technical limits or earlier decisions.
- Success criteria. How to validate that the work is correctly finished.
A simple example, with a code migration task:
goal:
Migrate test_payments.py from unittest to pytest
inputs:
- tests/test_payments.py
constraints:
- Keep the current test names
- Use the shared fixtures from conftest.py
success_criteria:
- pytest tests/test_payments.py runs clean
- No unittest imports leftIf a task cannot be expressed with that clarity, it is probably not defined well enough to be delegated yet.
The information coming back is part of the design too
The flow does not end when the executor receives a task. The result that goes back to the orchestrator needs the same level of design.
In my first implementations the executor returned its entire generated response to the main model. That works with a handful of tasks, but it scales badly once you run dozens or hundreds of subtasks. In my case, I watched GLM 5.2's token counter climb too high.
A more efficient architecture separates two kinds of output: the generated artefact (code, documents or transformed data) and an operational summary that lets the orchestrator make decisions.
The orchestrator does not need to read every modified line. It needs to know what was done, whether it finished correctly and whether anything needs attention. The artefact stays in the shared workspace and is only retrieved when a later review needs it.
This design has a direct economic advantage too. Prompt caching works on prefixes: when the start of the prompt is identical between calls, the provider does not process those tokens again and bills them at a discount. With DeepSeek, input tokens that hit the cache are charged with a reduction close to 98%, one of the most aggressive policies on the market.
Which gives you an ordering rule: constant information, like the executor's instructions or the project conventions, goes at the start of the context, and task-specific information is appended at the end. Any variation in the prefix invalidates the cache for everything behind it.
There is a second detail: the cache is built when a call finishes processing. If the system fires twenty tasks in parallel from the start, none of them finds the prefix cached, because they all arrive at once. The fix is simple: one lone first call that processes the full prefix, then the rest in parallel behind it with the cache already warm.
A worked example: migrating a test suite with several models
To see the whole architecture, let us apply these patterns to a common case: migrating a test suite from unittest to pytest.
It is a good example because it combines the three things that make orchestration interesting: there is a clear goal, there are many repetitive tasks that can run in parallel, and the result can be validated automatically.
The flow would be:
- GLM 5.2 analyses the repository and generates a migration plan.
- Each task becomes an independent specification.
- DeepSeek V4 Flash runs the individual migrations.
- Automated tests validate the changes.
- GLM 5.2 reviews the overall result and spots consistency problems.
The first important decision is where to put the expensive intelligence. The initial repository analysis needs an understanding of relationships between files, existing conventions and possible shared dependencies, and that is where the orchestrator model earns its price. During execution, by contrast, most tasks have a much smaller context. Migrating one file, updating imports or adapting a fixture are repetitive operations where speed and cost weigh more.
The resulting architecture looks like this:
The important detail is that the executors never receive the orchestrator's full conversation. Each one gets a self-contained task with the information it needs.
An executor does not need to know the repository has been under migration for three weeks. It needs to know which file to modify, which conventions to respect and how to check its change is correct.
That is what makes the tasks independent. If one migration fails, you retry that specific task with the error the tests returned, without restarting the whole process or dragging along the earlier history.
Where the saving actually comes from
The economic advantage of this architecture shows up as volume grows.
With first-party API prices as of August 2026, taken as an order of magnitude because they vary by provider: GLM 5.2 costs 1.40 dollars per million input tokens and 4.40 per million output. DeepSeek V4 Flash costs 0.14 and 0.28 respectively, roughly 15 times less on output, and it generates at more than 100 tokens per second.
Applied to the example migration, with 15 files:
- Planning and final review with GLM 5.2, the two calls with wide context: about 15 cents.
- The 15 executions with DeepSeek, with the common prefix cached and paying full price only for each task's contract and file: about 5 cents.
- Total: around 20 cents.
The same process run entirely on GLM 5.2 lands between 50 and 70 cents depending on how long each generation runs. Roughly three times as much, and slower in the parallelisable phase. At scale, using the biggest and most expensive model for everything means multiplying your bill by 3 at minimum.
And if the plan is good, the saving grows with the number of subtasks you delegate: the more work lands on the executor, the wider the gap against doing all of it with the big model.
The break-even point depends on three variables: the cost difference between models, the number of executions and the cost of coordination. On a one-off task, this architecture can even come out more expensive. In a pipeline that runs the process hundreds of times a month, or in tasks where the execution phase moves millions of tokens, the difference piles up fast, and that is what makes it viable in production.
The allocation logic is the same at any scale. GLM 5.2 takes part in the moments where a wrong decision is expensive: understanding the goal, designing the strategy and reviewing the final result. DeepSeek V4 Flash takes part in the operations where executing many times efficiently is what counts.
The saving does not come from price per token alone either. It also comes from reducing how much work each model has to do. The orchestrator does not process every operational detail, and the executors do not need to understand the project's whole history.
Other things to keep in mind
The model helps decide and execute, but the system needs deterministic mechanisms that confirm the result is correct. In this case, the usual tools: run the test suite, review the changes through version control, check static rules and validate the expected formats.
A multi-model architecture also needs observability, like any distributed system. In production it is worth logging which model version ran each task, which prompt and configuration it used, what each step cost, what result it produced and how long it took. That information lets you spot degradation when a model changes, compare orchestration strategies and improve the contracts between components.
And multi-model is not worth adding when the tasks are small, when the problem needs global context, when latency is critical or when your request volume is low.
You can do this with other models
None of this pattern is exclusive to GLM and DeepSeek. Before this combo I worked with Qwen 3.6 as the executor and DeepSeek V4 Flash or Opus as the orchestrator.
A different example: Claude Opus 5 as the orchestrator and Qwen 3.6-35B-A3B as the executor. Opus 5 is among the best things out there today for planning and agentic work (even if we all miss Opus 4.6). It costs quite a bit more than GLM 5.2, but if you already have the subscription, you may prefer it. It also lets you set the effort level per call, which maps naturally onto the role: high effort for the plan, medium for the review. And Qwen 3.6 is the perfect executor: we have used it as an all-rounder at Helmcode for everything.
You could also do it with GPT 5.6 Sol and Qwen 3.6, or GPT 5.6 and DeepSeek, or whichever combination you like best.
The main idea is this: the expensive, powerful model as the orchestrator, working only where it has to, and the cheap, fast model as the executor, doing most of the work.
Quickstart: try it in 5 minutes
If you want to try this architecture without writing anything, I have prepared an OpenCode quickstart that gets it running in two commands:
git clone https://github.com/helmcode/orchestrator-quickstart
bash orchestrator-quickstart/setup.shThe script is an installer. It asks you one question, which pair you want (GLM 5.2 + DeepSeek V4 Flash, Opus 5 + Qwen 3.6, or your own), and configures the rest: the provider, the two agents with their roles and permissions, and the project conventions template. You bring your API key and start delegating.
The agents are two markdown files you can read and modify. The orchestrator has writing denied on purpose, so delegating is its only route (you can change that if you are heading for something like pattern 3). The executor always returns a 3-line summary so it does not inflate anyone's context, and it is not restricted, so it can run anything. You can restrict it to stop it deleting files it should not touch.
All you need is a platform that serves these models behind an OpenAI-compatible API. We serve the ones with the best cost and throughput , all of them open models, with a flat rate and zero logs.
The advantage is in designing the system, not in stacking up models
The way models have evolved has pushed many teams to look for a solution built on a single generalist model. In complex systems, architecture tends to matter as much as the individual capability of the model: giving different responsibilities to different components is what makes systems more controllable and more efficient.
In a multi-model architecture, the orchestrator understands the goal, holds the direction of the process and makes the high-level decisions. The executors resolve concrete tasks at the right speed and cost.
The most important part of the design is the boundary between the two. A model does not improve because it receives more context, it improves because it receives the right information in the right format. The handoff works when there is a clear contract: what has to be done, with which resources, under which constraints and how the result is validated.
After going through all these patterns, the central idea is still the same: the orchestrator does not pass conversations, it passes work contracts.
I used GLM 5.2 and DeepSeek V4 Flash as the example because they are the two newest models we are serving at Helmcode and NaN.builders, and because they combine different capabilities. But the principle is broader: LLM-based systems need architecture, interfaces and validation mechanisms just like any other complex system.
Orchestration is a way of designing the whole system. And the best systems are not the ones using the most models, they are the ones that allocate responsibilities better, run faster and cost less.
