When people say the model is slow

A support ticket that reads ‘the model is slow’ is almost never a complete sentence. Slow compared with what, on which screen, after how many tries, and while doing what else?

In usage work we separate three clocks. The model’s own time is one. Time spent in your app before the request leaves is another. Time spent waiting on a retry, a queue, or a second call that the first screen did not mention is a third. Product conversations collapse all three into a single grievance.

We have sat with an app whose composer felt sluggish after lunch. The model’s own times had not moved. A new ‘helpful’ rewrite was firing after every keystroke pause longer than a second, and the composer waited for it before painting the suggestion. The route had changed; the model had not.

Retries deserve suspicion. A single timeout policy that retries three times, each wait longer than the last, can turn a one-second miss into a twelve-second stare. If your logs do not mark attempt number, a usage assessment will spend days reconstructing it from timestamps, and the reconstruction will be less certain than a field would have been.

Background work that blocks a foreground screen is another regular finding. A classify-on-open call that was meant to be speculative still holds the record view until it returns. People blame the model because the spinner sits next to generated text.

None of this means the model is never the slow part. It means you cannot know until the call inventory says which site the person was on, and the logs say whether that site waited on itself or on a neighbour.

If you want a practical check before you write to us: pick one complaint from last week. Name the screen. Ask whether that screen is allowed to paint without the model. If nobody in the room can answer, the latency problem is still a usage problem.