When the model got faster, players changed how they played

Fourteen seconds after a command, the board was still frozen.

The plan was usually fine. The actions were legal. The engine was still the authority. None of that mattered much while the match sat idle waiting for the model.

Players stopped choosing those modes. We did too, when we were testing.

Waiting is not playing

In a tactics match, some pauses feel natural. You are thinking. The opponent is thinking. The board is still yours.

A pause while the system thinks for you feels different.

You typed what you wanted. Now nothing happens. Then something happens all at once. Then you wait again.

The mode was correct.

It just was not fun to use.

Before we cut that wait, AI-powered modes accounted for less than 5% of gameplay. That number is easier to understand once you sit through a few sessions. Players tried the modes. They did not stay in them.

We had assumed the hard part was getting the model to understand intent and respect the rules. We had spent a lot of time on that, and for good reason.

What we had underweighted was how much the wait itself decided whether anyone would use the result.

The assumption worth questioning

It is easy to treat model latency as an infrastructure detail. Something to improve later, once the feature is "done."

That framing made sense when models mostly ran in batch jobs or chat windows where a few extra seconds were annoying but not fatal.

Interactive agents are different.

In Arena Tactics, a language command is not a side request. It sits inside the match. The player is waiting for units to move, abilities to fire, and the turn to continue. If the system cannot keep that rhythm, the mode stops competing with ordinary play.

So the useful question is not only "Can the agent do this?"

It is "Can the agent do this fast enough that players keep choosing it?"

Those are not the same product bar.

What we changed

We rebuilt the AI path around a multi-agent architecture using LangChain and LangGraph. A planning agent reads the command, inspects game state, plans, emits actions, checks them against legal constraints, and repairs the plan when something fails.

That made the system more inspectable and more reliable. It also made the cost of each model call harder to ignore. More steps meant more calls. More calls meant more cumulative wait if the underlying model was slow.

Once the agent graph was in place, the bottleneck was obvious. Better planning without faster inference still left AI modes on the shelf.

So we changed the inference layer. We ran GPT-OSS-20B on GroqCloud and compared it with Gemini 2.5 Flash and GPT-5-nano under the same gameplay workload.

What the numbers showed

Per-call latency landed at roughly 3.82 seconds on Groq, against 14.35 seconds for Gemini 2.5 Flash and 26.19 seconds for GPT-5-nano.

That gap is the difference between a command that can stay inside a match and a command that breaks it.

Full-game model time told the same story across a whole session: 184.56 seconds with Groq, 770.52 seconds with Gemini, and 1580.05 seconds on the OpenAI baseline.

Cost moved with latency. Groq came in at about 14× less than Gemini and about 2.3× less than OpenAI per game.

On the player-facing side, commands became roughly 7× faster.

AI-powered modes went from less than 5% of gameplay to more than 60%.

The capability had not suddenly become new. The system could already interpret intent and stay inside the rules. What changed was whether that capability felt like play.

Arunan Sri put it plainly: "Speed is everything. Inference is the fuel that powers that entire matrix of options."

The matrix is the set of modes you can afford to keep in the main loop. Faster inference expands that set. Slower inference shrinks it, no matter how careful the agent design looks on a whiteboard.

Players changed because the constraint changed

When AI modes cost roughly 14 seconds per command, players treated them as experiments.

When commands got fast enough to keep match rhythm, players started using those modes as ordinary play.

Adoption above 60% is not a preference score from a survey. It is evidence that the mode finally cleared the bar for repeated use inside a real match.

That pattern should feel familiar to anyone shipping interactive agents. Feature completeness is not enough. People adopt the path that preserves flow. In games, flow is paced by turns, animations, and opponent response times. An agent that cannot keep that pace loses, even if its plans look better on paper.

There is a second consequence for product teams. Once AI modes are cheap and fast enough to run often, they stop living only as a niche accessibility layer. They start showing up in how people actually play. Arguments about opening new ways to play only hold if the mode can survive contact with match length and cost.

Latency as a design variable

The broader lesson is simple, and it travels outside Arena Tactics.

For conversational control, adaptive opponents, and co-play agents, latency is not only an ops metric. It decides whether a new interface can own a meaningful share of play.

Measure the loop the player feels, beyond the single API call. Track model time across a full game. Ask whether your planning architecture multiplies calls in ways that make a decent per-call number fail at match scale. Treat adoption of AI modes as a latency-sensitive signal rather than a feature-awareness metric.

We learned that the hard way, then the useful way: by watching what players did when the wait went away.

If you are working through the same constraint in your own title or tool, that is the conversation worth having. Where does inference sit inside the experience, and what becomes possible once it no longer owns the wait?