Developer Cuts Median Cost of an LLM Game Turn to 0.34 Rubles

In a text RPG, a single model response must do several things at once: continue the scene, resolve the player's actions, update injuries and relationships, preserve character memories, and prepare the next turn. If even two fields disagree, the story starts to fall apart. An attack lands in the description but misses in the calculation. A character learns a secret despite not being present for the conversation. A companion leaves, then remains nearby in the next field.

The creator of the Telegram game AniWorlds encountered exactly this engineering problem. Instead of a chain of agents, the developer uses one request and receives a 38-field JSON object. The main practical finding is unexpectedly simple: the order of fields in a structured response affects the consistency of the result.

Decision First, Narrative Second

The model generates JSON sequentially. A later field can take account of what has already been written, but it cannot go back and rewrite an earlier one. That is why a hidden decision—whether an attack landed, for example—must come before the literary description of the fight.

When the order was reversed, the narrator could first vividly describe a hit and then record a miss in the result field. Instructions in the system prompt did not reliably eliminate the contradiction. Reordering the fields removed the source of the error itself: the model first records the outcome, then describes its consequences.

The second principle is that each decision should live in one place. If a companion's behavior is determined simultaneously by the rule for moving between locations and by a separate companion rule, the answers begin to diverge. In AniWorlds, the decision was moved into a single field, while the remaining parts of the schema only use its result.

What the Narrator Should Not Be Trusted With

The creator left randomness and exact arithmetic to the server. For every combatant, the code rolls two d6 dice, applies the relevant stat, and sends the model the resulting numbers. The model does not decide who got lucky: it calculates the outcome from the supplied data and turns it into a scene.

Ability costs, stamina, and cooldowns work the same way. The server reports in advance how much of a resource remains and which actions are unavailable. This reduces the risk that the narrator will forget an earlier expenditure or arbitrarily change the rules for the sake of a dramatic episode.

There is also a separate knowledge boundary. After the outcome, the model records exactly what the characters saw and heard. Their memories are updated only from this field, not from the player's complete message. The solution is not yet perfect: in some tests, characters still receive unnecessary information. The creator candidly notes that the improvement has not yet been proven.

The Cost of Context and the Cost of Errors

The complete input occupies 45–53 thousand tokens. The rules and world description rarely change, so they are placed at the beginning of the request and enter the provider's cache. By turn 71, the median cost of one request was 0.34 rubles and the average was 0.57 rubles. Without a cache hit, a turn cost approximately 1.25 rubles.

The cause of expensive misses was mundane: group identifiers were regenerated on every turn. Even a single changed character broke the prefix match. Once permanent identifiers were fixed in place, the cache became more stable. This is a useful lesson for any LLM product: caching depends not on semantic similarity, but on the input remaining byte-for-byte unchanged.

The creator tests changes in batches of 10 identical requests and records the error rate. The acceptance criterion is 10 out of 10 responses without the targeted defect. This does not prove absolute reliability, but it prevents the problem from being declared solved after one successful example. Before release, the rules are additionally reviewed by two clean model sessions, after which the change is tested over 20 live turns.

The practical conclusion extends beyond games. In systems with structured output, place facts and decisions first, followed by the text that depends on them. Keep deterministic calculations in code. Assign one source of truth to every decision. Make the stable part of the context byte-for-byte identical. And measure quality across batches of runs: a confident “done” from an assistant does not mean the error has disappeared.