I use AI agents heavily, and I often choose models such as Astra or Fable to get the best results. But I wonder how much of the work they do actually needs to be done by the most expensive model. I am not talking about the core problem-solving, but about reading large tool results, maintaining memory, and interacting with the user.
The idea is to pair the main agent with a much cheaper support model, such as Luna or DeepSeek. I am thinking of configurations where the price gap is substantial—on the order of 50×—rather than a slightly cheaper alternative.
Part of what makes this interesting to me is how quickly inexpensive models have improved. My impression is that some are already capable of complex tasks that required frontier models only a few months ago. For models that support fine-tuning, there is also the possibility of specializing them for these particular responsibilities. I would expect a well-chosen support model to handle these narrower tasks extremely well, potentially close to the main model’s quality. That is an expectation I would want to test, not a benchmark result I already have.
This is a general architecture, not a proposal tied to a particular coding agent. The initial version would have three responsibilities: input filtering, memory management, and an interactive interface with user-facing explanations.
The shared foundation: full context, including reasoning
The support model would receive the same informational context as the main agent: instructions, constraints, conversation, memory, tool calls, and the complete reasoning trace the main agent has already produced. Not just a summary or the last few messages.
It would also have its own stable instructions defining its support responsibilities. The main agent would not need to stop and prepare a new assignment each time: the support model would already be following the session and would be activated automatically when needed.
Reasoning is part of the requirement. It should help the support model understand not just which operation was performed, but why it was performed and what the main agent is trying to establish. Where the full trace is not accessible, this version of the architecture would require a different integration. Passing a reasoning summary would be a more limited variant, not the full proposal.
I would not ask the support model to solve the original problem as well as the main agent. I would ask it to use the information and reasoning already available to perform more narrowly defined tasks.
The economics: one support-model cache reused across all three functions
Filtering, memory management, and the interface would be functions of the same inexpensive support model—not three independent conversations that repeatedly rebuild their context.
The main model would have its own cache. The support model would have a separate cache, reused across its different responsibilities. I am not proposing to transfer Astra’s internal cache to Luna. The reuse happens between the different tasks performed by Luna.
The support instructions—even, for example, a 5,000-token initial prompt—would stay stable, followed by the session history. Switching from filtering a result to updating memory or answering a clarification should not, by itself, require processing that entire shared history again as new input. The unchanged prefix should remain reusable.
For example, suppose the support model has already processed a 500,000-token prefix and a new 5,000-token tool result arrives. With a cache hit, the call can read the existing prefix at the cached-input rate and process the new result as new input. If I then ask the support model to explain the state of the work, it should not have to pay for those same 500,000 tokens entirely as new input simply because the task has changed.
Sending the full context on every call is not the same as paying the full uncached-input price on every call. The existing, unchanged portion can be read from the support model’s cache; new or modified content must still be processed, and the support model’s output must still be generated.
This does not make the calls free or guarantee a cache hit. Changes to the prefix, compaction, and cache expiration can require new processing. The exact price ratio also depends on whether we are counting new input, cached input, or output. But these operations would be billed at the support model’s much lower rates rather than the main model’s.
There is a second source of potential savings: filtering reduces what enters the main agent’s context and therefore what it has to reread later. Moving memory maintenance and clarification conversations out of the main agent also avoids adding all of that ancillary work to its history. My expectation is that the combination could produce substantial savings while giving the main agent cleaner inputs and the user a better experience.
The three initial functions would be the following.
1. Input filtering before it reaches the main agent
When a tool returns a large result—a source file, document, log, search result, or response from a service—the support model reads it before the main agent does.
Knowing the session and the reasoning that led to the tool call, it decides which representation will be useful for the next step. It would not simply summarize everything or remove a fixed percentage of the text.
It could preserve some passages exactly, summarize others, or leave the entire result unchanged.
For example, in a source file it could keep lines 1–50 verbatim, summarize the functions in lines 51–300 with their names, responsibilities, and important relationships, and retain another implementation block needed for the current change. It might describe what call_spreadsheet() does without reproducing its entire body. For a descriptive document, it might summarize by section; for a log, it might preserve exact errors while condensing repetitive output.
The support model reads the new result in full. The main agent receives the prepared version, and that version becomes part of the shared working history for subsequent calls. The originals remain recoverable whenever an omitted detail is needed.
I would start with a small number of frequently used tools and a configurable threshold, perhaps 1,000 tokens. Below the threshold, the result passes through directly. Above it, the support model evaluates whether and how to reduce it. Crossing the threshold does not make compression mandatory.
The benefit is not limited to the first read: excluded material no longer occupies the main agent’s context or gets reread on every subsequent call.
2. Updating and managing memory
The second responsibility would be to keep track of what matters as the work progresses, without asking the main agent to stop and reconstruct the session.
The support model has already seen the requests, results, reasoning, and corrections. It can record decisions, user constraints, completed checks, unresolved issues, and failed attempts.
I do not mean generating a new, complete summary after every operation. I mean targeted updates: a hypothesis has been disproved, a decision has changed, a check is still outstanding, or a conclusion is no longer valid after a modification.
Filtering and memory answer different questions. Filtering asks, “What does the main agent need to read now?” Memory asks, “What will be important not to forget later?”
The two activities could also happen in the same call. After reading a complete tool result, the support model could produce both the version intended for the main agent and any information worth remembering. When memory needs consolidating, it would use the context it has already processed rather than require another briefing.
Verified facts, hypotheses, and user preferences should remain distinct. A summary must not turn a suspicion into a certainty.
3. An interactive interface and explanations for the user
This comes from a problem I increasingly notice: agents are becoming more autonomous, but their work is becoming harder to follow.
The main agent performs operations, changes its approach, and launches subagents. I keep finding myself asking, “Where are we?”, “What have you done so far?”, “Why are you reading this?”, or “What are the other agents doing?”
I would like the support model to update a persistent, interactive interface, not just a list of tool calls. It should explain the current objective, the work already completed, what the main agent is doing and why, which results have been verified, and what remains to be done.
Clicking on a subagent should show its assignment, what it has already done, its current activity, and the results it has produced. I am not imagining an entire HTML page regenerated continuously. The interface remains in place while the support model updates its state and explanations.
The same interface would also present questions and decisions that require my input.
If the main agent offers two alternatives and I do not understand the consequences, I could ask the support model:
What is the practical difference? Why is the agent asking me this? Which constraints in my project are relevant?
The inexpensive model could explain the options more clearly, give examples, and answer follow-up questions using the context and reasoning it already has—without calling the main agent again just to explain its question. These exchanges would reuse the same support-model context and cache used for filtering and memory.
My eventual decision or new constraints would go back to the main agent, but not necessarily the entire clarification conversation. If information is missing or a fresh judgment from the main agent is required, the support model should say so rather than invent an answer.
Later: tools and other ancillary tasks
Those three functions would be the starting point, not necessarily the limit.
The same support model could later call selected tools, retrieve material, and perform small side tasks: consulting an archive, locating a relevant document, recovering a previous decision, collecting subagent results, or preparing information for a subsequent step.
Again, the advantage would be starting with an already-informed support model rather than spending a main-model call to describe every ancillary operation.
These extensions would have bounded responsibilities and permissions. The goal is not to create a second agent independently making the same difficult decisions as the first. It is to remove more work from the main agent that does not necessarily require its level of capability.
Why not just use subagents?
A subagent could implement this architecture; the name is not important.
The distinction is that an expensive subagent with the full history adds cached-input reads and generation at the main model’s prices. A cheap subagent without that history requires someone to select its context, prepare its assignment, and handle missing information.
The proposal is an inexpensive support model that is already synchronized, activated automatically, and able to reuse the same context across multiple functions. The main agent should not need to manage each support operation as a separate delegation.
I have not yet measured whether the benefits outweigh latency, selection errors, and additional retrieval. The price gap between the models is the starting point, not a promise of an equivalent reduction in the total cost of the system.
Has anyone built or evaluated an architecture like this, especially one combining input filtering, memory management, and an interactive interface in the same support model? I would be interested in comparisons that include task quality, total cost, cache reuse, and the coordination work required from the main agent.