There is a version of “use a better model” that is too blunt. Sometimes the cheaper model already knows enough, but one sample is brittle. It misses a constraint, takes the wrong branch, or writes the first plausible answer. Recursive Self-Aggregation, RSA, attacks that failure mode by spending test-time compute on a population of answers and repeatedly asking the model to aggregate them.
Tangle Router exposes RSA as a gateway strategy on the normal chat-completions path. The important product point is not that RSA is free. It is that a caller can trade latency and extra calls for answer quality without changing the model API.
For the surrounding runtime, read OpenAI-compatible routers for agents and How AI agents discover products. RSA is one request-time strategy inside that larger routing surface.
Quick Answer
Use RSA when a request can tolerate extra latency and the answer quality matters more than a single cheap completion: planning, code generation, structured analysis, eval pipelines, research summaries, and async agent steps.
Do not use RSA for every chat turn. It multiplies calls. If the task is interactive, cheap, or already verifier-backed, the extra fan-out may be wasted.
What The Paper Shows
Venkatraman et al. study a simple but useful idea: generate a population of candidate reasoning chains, aggregate random subsets into improved answers, repeat, then return one converged candidate. In shorthand:
generate N candidates
repeat T rounds:
for each candidate slot:
sample K candidates
ask the model to aggregate them
return population[0]The method is interesting because it does not require a separate verifier. That is also the risk. If the model family is confidently wrong, aggregation can polish the wrong answer. RSA is a test-time scaling strategy, not a correctness proof.
Tangle Router Shape
RSA fits naturally in a Router because the caller should not have to build a parallel inference harness. The request stays OpenAI-compatible, with the strategy carried in gateway options:
{
"model": "google/gemini-3-flash",
"messages": [
{ "role": "user", "content": "Write and justify the migration plan." }
],
"gateway": {
"rsa": { "n": 8, "k": 3, "t": 3 }
}
}The call budget is N + N*T. With n=8 and t=3, the Router expects 32 model calls. With n=16 and t=5, it expects 96. That number has to be visible before the first fan-out starts.
Budget Gate
RSA without a budget gate is an outage waiting to happen. The Router should estimate maximum spend before launching the population:
| Setting | Calls | Production concern |
|---|---|---|
n=4, t=2 | 12 | useful smoke test |
n=8, t=3 | 32 | reasonable async quality pass |
n=16, t=5 | 96 | expensive, slow, needs explicit approval |
If the caller cannot cover the projected spend, the request should fail before work begins. In a paid service path, that means returning a payment or credit requirement instead of starting partial fan-out.
What It Costs In Latency
RSA buys quality by spending serial rounds. The first population can run in parallel. Each aggregation round depends on the previous population. That means wall-clock latency grows with T, even if each round fans out internally.
Use RSA when the output is worth waiting for:
| Good fit | Bad fit |
|---|---|
| async agent planning | live chat typing |
| code generation before PR | autocomplete |
| eval and judge tasks | tiny extraction |
| research synthesis | low-stakes summarization |
| migration plans | latency-sensitive tool calls |
The useful default is not “turn RSA on.” The useful default is “make RSA selectable at the step where the agent would otherwise ask a human to think harder.”
Evidence To Capture
An RSA run should return more than the final answer when the caller is debugging quality:
{
"strategy": "rsa",
"model": "google/gemini-3-flash",
"n": 8,
"k": 3,
"t": 3,
"calls_planned": 32,
"calls_completed": 32,
"latency_ms": 12480,
"stop_reason": "completed",
"trace_id": "router-run-id"
}The candidate text does not always need to be returned to the end user, but the trace should exist. Otherwise a bad RSA answer is impossible to inspect.
Two Extensions
Mixture-of-Agents uses different models in the population and one model as aggregator:
{
"gateway": {
"rsa": {
"n": 4,
"k": 3,
"t": 2,
"models": [
"anthropic/claude-sonnet-4-6",
"google/gemini-3-flash",
"openai/gpt-4o",
"deepseek/deepseek-chat"
]
}
}
}Best-of-N is the verifier-backed cousin: generate candidates, score them with a user-supplied scorer, and return the winner. If you have a real scorer, use it. RSA is more useful when you do not.
What RSA Does Not Prove
RSA does not prove a model is correct. It does not replace domain evaluation. It does not make a weak model safe for high-stakes execution. It increases the search and aggregation budget at inference time.
The benchmark that matters for your product is simple: compare baseline, RSA, and a stronger model on the same tasks, with equal reporting of cost, latency, and failure cases. If RSA wins on quality per dollar and the latency is acceptable, use it. If the stronger model wins cleanly, use the stronger model.
Start
Open Tangle Router, read the RSA paper, and run a small strategy first:
{
"gateway": {
"rsa": { "n": 4, "k": 2, "t": 2 }
}
}Then increase n and t only after you know the task benefits from aggregation.
FAQ
What is Recursive Self-Aggregation?
Recursive Self-Aggregation is a test-time scaling method that generates multiple candidate answers, repeatedly aggregates subsets of them, and returns a converged answer.
Does RSA make a small model as good as a frontier model?
Sometimes it can close a gap on specific tasks, but that is workload-dependent. It should be benchmarked against both the baseline model and a stronger model with cost and latency included.
Why put RSA in Tangle Router?
The Router can run RSA behind the same chat-completions surface, estimate cost before fan-out, preserve traces, and let agents choose the strategy per request.
When should I avoid RSA?
Avoid RSA for low-latency chat, tiny extraction tasks, high-stakes tasks without verification, or any workload where extra samples do not improve the measured outcome.