I cut the coach’s prompt in half. The first word still took 20 seconds.

Every game review starts with one large request to a language model. Most of that request is the coach’s instructions: how to read the engine data, how to mark up a board, what to remember about you. Over months of fixes it had grown to about 29,000 tokens, and the first words of a review took around 20 seconds to appear. The obvious move was to put the prompt on a diet. I did, and cut it by more than half without making the reviews worse. The wait before the first word barely moved. This post is about why, and about the dial that does move it.

What the coach reads

A review request has two parts. The instructions are the same for every player and every game: 88,000 characters, about 21,000 tokens, roughly 85 percent of the request. Then there is the game itself: the moves with the engine’s verdict on each one, the handful of key moments with the exact position before each, your opening history and anything the coach remembers about you. That part is 14,000 to 19,000 characters.

Reading the instructions end to end, I found the usual sediment. The same chip rules stated in three files. Field descriptions for data the model no longer receives. Rules for blocks that only appear in a few games, sent with every game. The game’s moves printed twice, once plain and once annotated. And, as it turned out, a few things that were simply wrong (more on those below).

How I tested it

• Five reviewed games from the earlier baseline run on public games: three from Chess.com and two from Lichess, all blitz, with the player as White in two and Black in three, a win, a draw and three losses, from 30 to 73 moves. I am not naming the players here; they do not matter to the result.
• The real prompt, exactly. I ran the backend on a copy of that data and captured the request it sends, instead of reconstructing it by hand.
• Three rewrites, then one revision. Each rewrite is a full set of the coach’s instruction files plus changes to the game data. The table below says what each one changed.
• The same model as production (Gemini through OpenRouter, normal reasoning), streamed, timing the first word and the last. 140 timed reviews, interleaved so that a slow minute on the provider’s side hits every option.
• Two kinds of grading. A format checker built on the app’s own parsers (25 tests of its own) checks the things that break the screen: section markers, board chips, the memory block the coach writes for later. Then a blind judge, an AI model told to fact-check every claim against the game data with a chess library, compared each rewrite with the current prompt on the same game without knowing which was which.

The options side by side

Each row is one version of the prompt. Times are medians. Format clean counts replies that passed every check that matters to the screen. The judged column reads as three counts over ten blind pairs: the option preferred, the current prompt preferred, a tie.

• A, deduplicated removed a third of the input, kept the structure, and was the judges’ favourite (6 to 2). It did not fix a single format problem.
• B, restructured rewrote the instructions as one plan: who the coach is, what each data block means, the reply in order, the markup. It more than halved the input and went from 3 to 18 clean replies out of 20. It also had two regressions: it wrote move sequences in prose instead of on a board, and covered the key moments a little less often.
• C, conditional sent rules only for the data a game actually has. It was the smallest, and it was worse than B on both format and coverage.
• B2 is B with those two regressions fixed. Over ten blind pairs the judges split 4 to 4 with 2 ties, and it kept the format gain (14 of 15 against 2).

Where the wait goes

To see why the times hardly move, split each review into three parts: the model reading the request, the model reasoning before it writes anything, and the writing itself.

With normal reasoning, the first byte arrives after 3 to 4 seconds whatever the request’s size. The instructions are identical on every review, so the provider usually has them cached, and cutting 16,000 tokens saves well under a second. The gold segment is where the time goes: the model thinks for about 2,000 tokens before writing a word, and a shorter prompt did not make it think less.

Across those reviews, time to the first word tracks the reasoning length with a correlation of 0.90. It is the same lesson as the baseline post, one step earlier: there, the whole review followed how much the coach wrote; here, the first word follows how much it thought.

The dial that does move it

So I turned the reasoning down. On this model, the low setting switches it off entirely, and the first words arrived after about 2 seconds instead of 20. The whole review took 15 to 18 seconds instead of 31 to 38.

It is not free. Blind, the judges preferred the normal-reasoning reviews: 5 to 2 for today’s prompt and 5 to 3 for B2. The low-reasoning reviews still found the decisive moment, but they explained it less well: the judges’ insight score fell from 3.1 to 2.7 for today’s prompt and from 3.8 to 3.1 for B2. Somewhere between off and normal there is probably a reasoning budget that buys most of the speed for little of the quality. I have not measured it yet.

A second model

To check this was not a Gemini quirk, I reran B2 against the current prompt on a fast, cheap model from another lab: Claude Haiku 5.5, five games, two reviews each.

• Prompt size matters more here. Nothing was cached on this route, so the full request is read every time. Both at low reasoning, B2 was faster to the first word (53.9 s against 66.2 s) and about 30 percent cheaper.
• Reasoning still dominates. In a first try at the setting production uses, this model thought for 17,000 to 24,000 tokens and took one and a half to two minutes to start writing. Even at low it reasoned for 10,000 to 12,000 tokens. The right setting is per model; one setting for all of them would be a mistake.
• Quality held. The judges split 3 to 2 with 5 ties, with equal accuracy scores. Neither prompt produced fully clean markup on this model, which suggests the format rules lean on Gemini habits.

What the diet did buy

Not speed, but three useful things. The restructured prompt follows the screen’s format far more reliably. It costs a little less per review. And reading every line found real mistakes, which no amount of reasoning time would have fixed:

• The instructions said a key moment’s win probability was White’s. It is the player’s own. For every review of a game played as Black, the coach was told the opposite.
• The instructions told the coach to leave out an opening board’s subtitle when it repeated the name. The app rejects an opening board without one, so the prompt was asking for boards that never render.
• The game table’s move count is in half-moves. The judges found reviews saying “a 146-move game” about a game of 73 moves, under every prompt.
• The examples showed board chips inside code blocks, and the model copied the wrapping.

What this does not tell you

• Five games. Enough to see a large effect and a null one, not enough to rank options that are close. Ten blind pairs per option is a signal, not a verdict.
• Strong players. All five are rated well above 2,600, Maia’s ceiling. Some of the data savings, like dropping a peer figure that repeats when two rating tiers agree, will be smaller for a 1200 player.
• No coaching memory. None of these players had a profile yet, so the parts of the prompt about remembering you were not exercised.
• An AI judge. Its fact-checks were concrete and checked with a chess library, but it is still one model grading another.

Update: a stricter test

The second round was written down before any run: the arms, the games, the measures and what would count as a pass. A variant had to be at least as good on every quality measure, not on average, and a faster prompt only counted as a win at equal quality.

• Every chess claim checked by code. A small model lists each factual claim in a review (a piece on a square, a pin, a defender, a capture, the material count) and chess.js rules it right or wrong against the actual position. I checked 60 of those rulings by hand: every claim ruled right was right, and about 7 in 10 claims ruled wrong were real coach errors, the rest misreadings by the extractor.
• A judge with a measured noise floor. The blind judge scores story, depth, learning value and grounding, and counts statements about what the player thought or felt that nothing supports. Judging the same prompt against itself moved its scores by 0.2 to 0.3 on a five-point scale. Any real difference has to clear that.
• One change at a time. Bug fixes, removing repeats, reordering sections and trimming the game data were each tried alone, then the best combination went up against today's prompt on 15 games it had never seen: 12 public games from players rated 550 to 3,160, and 3 reviews from our own closed beta, rebuilt on a local copy and never quoted here.

The trimmed prompt came out inconclusive. Chess errors were 6.5 against 7.2 per 100 claims, too close to call. The judge preferred today's prompt in 6 games, the trimmed one in 3, with 6 ties, and the first word was not reliably faster. Nothing was shown to be worse, but nothing was shown to be equal either, and equal was the bar.

Update: where the coach actually goes wrong

The claim checker made the real problem visible. The coach is reliable about what it reads from the engine data, and unreliable about what it works out on the board for itself.

This held even with the board in front of it. Since the board vision change, every key moment lists each piece by its square, and that works: on a board the coach was shown, only 3% of its piece locations were wrong, against 14% elsewhere. But its claims about pins, defenders and loose pieces were wrong 27% of the time on those same boards, no better than without them. Knowing the bishop is on a5 and the knight on c3 did not stop it calling the knight pinned with a pawn in between. It had the coordinates and still got the geometry wrong.

Update: what we shipped instead

• Board facts. Under each key moment, code now lists the exact relationships before and after the player's move: the material count, pieces attacked with no defender, pieces attacked by a cheaper piece, real pins, and what attacks and defends the piece that moved. The coach is told these lines are its only source for those claims. It is the same idea as board vision, one level up: the coach reports relationships instead of computing them.
• Four things the coach was being told wrong. The "human read" under each moment was inverted for every player who had Black: a player who was losing after the move could be told they were still holding. A key moment's win probability was described as White's when it is the player's own. An opening board with no subtitle was dropped, which shifted every later board in the review one slot. And the game table counted half-moves as moves.

Update: did it move the needle?

On 19 October I ran today's prompt and the new one side by side on the same 15 test games, same model, same judge, same checker.

Every quality measure moved the right way. The judge preferred the new reviews two to one, and scored all four dimensions slightly higher. Fewer relationship claims were wrong, and none of the errors reached the coach's memory of the player. Honestly, though, none of it is statistically certain at 15 games: each difference sits inside its margin of error, and the first-word gain is within normal variation. One measure went the wrong way: bishop colour errors rose from 2 of 18 to 6 of 19, because the facts do not name square colours yet.

Here is what the difference looks like, from a seven-move game by a 550-rated player who missed a queen and bishop aiming at f7. Today's prompt wrote, two sentences apart:

The f7 pawn was defended solely by your king on e8. [...] it left f7 completely unprotected against two attackers. [...] White wasted no time, capturing the undefended pawn with 4.Qxf7+.

With board facts, the same moment read:

The light-squared bishop on c4 and the queen on f3 were both aiming directly at your f7-pawn, which was defended solely by your king on e8. [...] The queen on f7 was defended by the light-squared bishop on c4, meaning your king could not capture it.

Both statements in the second version check out. It still made a mistake elsewhere in the same review, saying a knight on f6 would attack the queen on f3, which it would not. Board facts cover the key moments, not every sentence.