A purpose-built decision model and nine foundation models faced the same twenty well-defined choices. The test measured how long each took and what it cost. The results show where each approach fits in a marketing stack.
Why small repeated decisions add up
Marketing automation runs on thousands of tiny choices. Which subject line to send. When to follow up. Which segment gets which offer. Each decision is simple on its own. Multiply by millions of contacts and the latency and spend compound fast. Teams often reach for a large language model because it's easy to prompt. That convenience carries a hidden price tag when the call volume grows.
The benchmark setup
The author built a game called Sausage Battlefield. Each model played twenty turns, making one decision per turn. The test ran from Australia on 5 October 2026. Nine foundation models completed all twenty calls. A tenth, Grok 4.7, timed out on two calls and ranked slowest overall, so its data was dropped to keep the comparison fair.
The decisions were deterministic and scoped. No open-ended reasoning. No creative writing. Just clear inputs and expected outputs. This isolates the model's ability to follow instructions at speed and scale.
Latency and cost per decision
The decision model answered in single-digit milliseconds per call. Foundation models ranged from roughly one hundred to over two thousand milliseconds. Cost followed a similar spread. The decision model ran for fractions of a cent per thousand decisions. The foundation models cost dollars per thousand, with the slowest also being the most expensive.
Agreement with the expected answer was high across the board. Most foundation models matched the reference output on eighteen to twenty of twenty turns. The decision model hit twenty out of twenty. The gap in accuracy is small. The gap in latency and cost is not.
When to use each
Use a decision model when the decision is repetitive, well-defined, and latency-sensitive. Email routing, segment assignment, send-time optimization, and frequency capping all fit. The model is a small classifier or rule set trained on your data. It runs in your infrastructure. No API call. No per-token bill.
Use a foundation model when the decision needs context the decision model hasn't seen. Drafting a new subject line from scratch. Interpreting a free-form survey response. Handling a one-off edge case. These are low-volume, high-variety tasks where the flexibility justifies the cost.
Combining them in practice
A common pattern: the decision model handles the hot path. If its confidence drops below a threshold, the request falls back to a foundation model. The foundation model's output can then be labeled and added to the decision model's training set. Over time the decision model absorbs more cases and the fallback rate drops.
This architecture keeps the common case fast and cheap while preserving the ability to handle novel inputs. It also creates a feedback loop where the foundation model teaches the decision model, not the other way around.
The limits of this test
Twenty decisions is a small sample. The game scenario is narrower than most production workloads. Network conditions from Australia affect absolute latency numbers. The PDF linked from the case study covers the full method, including prompt templates, model versions, and statistical bounds. Treat the numbers as directional. The pattern—decision models win on speed and cost for scoped tasks—is the durable takeaway.