Multi-model synthesis on DigitalOcean Serverless Inference: cost, latency, and when it's worth it

• Cost: 13× to 93× depending on configuration, 35× for the configuration we shipped. The configuration from our launch post costs $0.1928 per call against $0.0055 for GLM-5.2 alone, and about 26× a frontier single model.
• Latency: 216s median, 19 minutes observed maximum. Roughly 7.6× a single model call, and the tail is longer than a 600-second client timeout can see.
• Disagreement is entirely task-dependent: 0% vs. 64%. Four models never disagreed on tasks where the supplied evidence determined the answer, and disagreed on 64% of tasks where it didn’t.
• The synthesized answer usually matches the judge’s own answer: 86%. Where panel members genuinely disagreed, the final answer landed on the judge model’s solo position 6 times out of 7. It differed from a single panel member on 5% of all tasks.
• The launch configuration was the least reproducible thing we tested: 82%. Asked the same question three times, it agreed with itself less often than a single model (89%) — and worse on underdetermined tasks (72%), which is exactly where you’d use it.
• All three presets run two-model panels, not the escalating panel sizes the documentation implies, and none of them sets the judge.
• Panels fail quietly. A panel member dropped out on 23% of four-model calls and 32% of quality preset calls, and the API returned an ordinary completion every time.

That doesn’t make synthesis useless. It makes it narrow. Here’s the evidence.

Twenty-five tasks in four families: infrastructure and vendor decisions, contract and policy analysis, incident diagnosis, and open-ended research. Nineteen tasks offered five numbered options so answers could be compared mechanically; six were open-ended and are excluded from every agreement metric, because free-text answers can’t be matched across runs.

Each task was labeled dispositive — the supplied evidence determines the answer — or underdetermined, where two or more options remain defensible. We wrote those labels before running anything.

Twenty configurations: each candidate model alone at high and low reasoning effort, a frontier single-model baseline (openai-gpt-5.6-sol), the panel configuration from our launch post (GLM-5.2 + Kimi-K2.6, GLM judging), all three built-in presets, panels of two and four, and variants isolating the judge. Every synthesis arm ran with tool_choice: "required" so the tool fired on all 746 successful calls rather than at the model’s discretion. Configurations with three repetitions let us measure run-to-run stability.

The harness, the task corpus, and the analysis script are linked at the end.

Across all 18 comparable tasks, disagreement was 39%. GLM-5.2 asked the same question three times disagreed with itself on 16%. The gap — 23 percentage points — is the disagreement attributable to model choice rather than sampling variance.

So model diversity is real. It just isn’t a property you can quote a number for without saying what you asked. Zero versus 64% is not a subtle spread, and it is driven entirely by whether the task had a determinate answer.

We learned this the hard way. An earlier, incomplete run lost most of the underdetermined tasks to client timeouts, and reported 17% disagreement against a 17% noise floor — which would have supported the opposite conclusion: that model diversity contributes nothing. Same models, same prompts, same code. Only the task mix differed.

If you take one thing from this article, take that. Any claim about how often models agree, ours included, is uninterpretable without the task distribution behind it.

Here is where the case gets difficult for the tool.

Read those together. Genuine disagreement exists on most underdetermined tasks. The judge sees all of it. And the answer that comes back matches what the judge model would have said on its own, nearly every time. Adding Kimi-K2.6 to a panel judged by GLM-5.2 moved the final answer away from GLM’s solo answer on one task in nineteen.

One caveat we should raise ourselves: the judge that was not on the panel also matched its own solo answer 57% of the time (4/7), against a chance baseline of roughly 33% for a three-model panel. So some of this is probably models converging on defensible answers rather than judges preferring their own reasoning. The on-panel/off-panel gap is 29 points at n=7 each — directional, not settled.

The role-level token data suggests why panels have less internal argument than the name implies. Panel seats do wildly unequal amounts of work. On identical tasks, openai-gpt-5.6-sol as a panel member used 709 input and 156 output tokens while Kimi-K2.6 used 37,558 and 5,301. In one configuration, GLM-5.2 as a panel member read 964 input tokens — barely more than the question. A four-model panel is often one or two models doing analysis and the rest returning a quick opinion.

And critically: none of the disagreement reaches your application. The API returns a normal completion. Panel outputs are not exposed. On an incident retrospective, the dissent between models is arguably the most useful thing the system produced, and you cannot see it.

Ask the same configuration the same question three times and compare the answers. The launch panel agreed with itself less often than a single model did — and the gap widens on underdetermined tasks, which is exactly where you would deploy it.

This is not mysterious. Synthesis adds three stochastic stages: panel sampling, judge selection, and a synthesis rewrite. More moving parts, more variance. One caveat: the four-model panel lost a panel member on 17 of 75 calls, so part of its apparent steadiness may be degraded panels having less to argue about.

If you are choosing an approach because you need reproducible outputs, the panel is the wrong tool on this evidence. A preset or a single model is steadier. For run-to-run consistency of single models measured across providers rather than across synthesis configurations, see our separate study on serverless inference consistency — the baselines here are DO-only by design, since the subject is one DO feature.

Against the frontier single-model baseline, the launch configuration costs about 26×. Prices are a 2026-07-28 snapshot of Serverless Inference pricing and include cache-read rates; web search is billed per request, separately from tokens, which no token-based estimate will show you.

Measured sequentially with nothing else in flight: median 216 seconds against 28.5 seconds for a single high-effort GLM-5.2 call on the same tasks — 7.6×. Three and a half minutes for one answer.

The tail is worth a paragraph of its own. Our first full run used a 600-second client timeout, and the longest observed calls all landed just under it: 592s, 594s, 599s. They weren’t slow, they were truncated. Raising the timeout to 1,500 seconds revealed maxima of 19 minutes on the balanced preset and 17.5 minutes on a four-model low-effort panel. Measured tails are only as long as you let calls run, and ours had been hiding a factor of two.

You don’t need timing data to know why. A synthesis call can’t return until the slowest panel model finishes, then the judge reads every panel output, then the synthesizer writes the answer. That’s a max() across the panel followed by two serial stages.

Preset composition isn’t documented. We derived it from per-role usage in the responses.

Three things follow, and two of them are surprising.

All three panels have exactly two models. The documentation describes quality as the largest panel configuration. On our runs the dial changes model calibre, not panel size.

Cost is monotonic; work isn’t. balanced burns 63% more tokens than quality while costing a third less. The premium tier is expensive because of who sits on the panel, not because it does more.

No preset sets the judge. Your top-level model judges in all three cases. If you want a different judge, set model on the tool object yourself.

One anomaly we can’t explain. The balanced preset runs the same panel and the same judge as our hand-built launch configuration, yet costs 67% more and is 14 points more reproducible, and its judge reads 37,449 input tokens against 16,181. Something feeds that judge more than twice the evidence. We saw one quality-preset call issue 14 web searches on a self-contained question that required no lookup, so retrieval is a plausible candidate — but the arm that would have confirmed it produced no usable data, because of the search tool bug described below. This stays an open question rather than a finding, and it is the first thing we will re-run once the bug is fixed.

• A panel member failed on 17 of 75 four-model calls (23%) and 8 of 25 quality preset calls (32%). Each returned a normal completion. Your application never learns the panel it paid for ran short.
• Output format degraded: every single-model arm returned our requested trailer format 100% of the time. Synthesis arms dropped it on 13% of balanced preset calls, 9% of low-effort four-model calls, and 7% of four-model calls. The synthesizer rewrites the final answer in its own words. If you depend on structured output or a JSON schema, test this.
• 128 of our attempted calls failed outright and were excluded, roughly 15% of attempts. This number is not a synthesis reliability figure and not a Serverless Inference reliability figure: nearly all of these failures trace to a single bug in the server-side web search tool, which we have reported. Calls that did not invoke search completed at a rate we had no complaints about. The bug is also why the search-enabled comparison arm in the preset section returned no usable data, and it is worth knowing about if you plan to enable search on a synthesis call today.

Our launch post reports a GLM + Kimi panel outperforming a frontier model on quality at roughly half the cost, measured on a 100-task deep-research benchmark. Both results are true, and the reason is task shape.

On deep research, a frontier single model also consumes very large token volumes, so the cost ratio between it and a panel compresses, and the panel can genuinely win on price. On bounded decision tasks, a single call is about 1,492 tokens and a synthesis call is about 95,395. The economics invert completely.

The published number is real on the workload it measures. This article measures a different workload and reaches a different conclusion, which is what you’d expect. If you’re evaluating the feature, the question isn’t which result is right — it’s which workload yours resembles.

For that last row, the arithmetic is simple enough to do in your head:

worth it when:  P(single model is wrong) × cost of being wrong
                 >  (N − 1) × cost per call

A vendor commitment worth $40,000 decided ten times a month clears that bar by orders of magnitude — $2 a month in extra inference against a five-figure downside. A classification endpoint serving two million requests a day does not, and it isn’t close.

We did not measure answer quality. Judge self-preference rests on seven tasks per arm. Difficulty labels were authored by us before running, not discovered — though the 0%-versus-64% separation suggests they captured something real. Panel composition is inferred from usage metadata because panel outputs aren’t exposed. One provider, one price snapshot, a feature in public preview. 128 calls excluded, nearly all attributable to a web search tool bug rather than to synthesis or to the platform. And our headline finding moved substantially between an incomplete run and a complete one.

Expose panel outputs, or at least a disagreement signal. This is our main ask, and the data above is the argument: real disagreement exists on most underdetermined tasks, and none of it reaches the caller.

Surface partial panel failure in the response rather than returning a normal completion when a third of the panel didn’t run.

Document preset composition, and reconcile the quality description with its two-model panel.

Preserve the caller’s output format through the synthesis step.

Does multi-model synthesis make answers more accurate? We don’t know, and this study can’t tell you. We measured cost, latency, agreement, and reproducibility, not quality. What we can say is that on 95% of our tasks the synthesized answer was identical to what a single panel member returned — so whatever accuracy gain exists has to come from the 5% of cases where the answer changed.

What does model synthesis cost compared to a single model call? Between 26× and 93×, depending on configuration. The launch configuration is $0.1928 per call versus $0.0055 for GLM-5.2 alone and $0.0075 for a frontier single model. The driver is input tokens: each panel member’s output is read by the judge and then again by the synthesizer, so you pay for every panel member roughly three times.

Is model synthesis fast enough for a user-facing application? No. Median latency was 216 seconds and we observed a 19-minute call. A synthesis request cannot return until the slowest panel model finishes, followed by two serial stages.

Which models does each preset use? budget runs deepseek-4-flash and gpt-5.6-luna; balanced runs glm-5.2 and kimi-k2.6; quality runs claude-fable-5 and gpt-5.6-sol. All three are two-model panels, and all three use your top-level model as the judge.

Can I see what the individual panel models said? Not currently. The API returns a single synthesized completion; panel outputs are not exposed. If the disagreement itself is what you need — incident retrospectives are the clearest case — orchestrate the panel yourself with parallel Chat Completions calls.

How do I know if a panel member failed? You don’t. Partial panel failures return an ordinary completion. In our run, 23% of four-model calls and 32% of quality preset calls lost at least one panel member with no signal in the response.

Why were 128 calls excluded from the results? Nearly all of them hit a bug in the server-side web search tool, which we have reported. It is not a synthesis failure mode or a platform reliability figure, and it is separate from the client-timeout truncation described in the latency section.

When is synthesis actually worth the cost? When the question is genuinely underdetermined, the decision is low-volume, and a wrong answer is expensive. A five-figure vendor decision made ten times a month clears the bar easily. Anything running at classification volume does not.

The harness, the 25-task corpus, the configuration set, and the analysis script are at github.com/Jameshskelton/fusion_test, along with the raw results this article is based on. Per the first finding, the variable that matters most is your own task mix — so the useful version of this experiment is the one you run on your workload, not ours.

Model synthesis documentation: Use the model synthesis tool

Serverless inference documentation: Use serverless inference

Pricing: Serverless Inference pricing details

Already running on the OpenAI API and want to reproduce this against DO? The endpoint is Chat Completions–compatible: migrating from the OpenAI API to DigitalOcean Serverless Inference.