Notice where the wait happens
A pause before the first useful response is different from a pause after a question. The first can involve screen capture, a provider request, and speech preparation. The second may be intentional: the companion is waiting for you to answer rather than producing the next part. Looking at the current status helps avoid interrupting a useful pause as if it were a failed request.
For a visual explanation, a step also needs to be complete enough to present. Displaying half an instruction or an unfinished drawing can be worse than waiting briefly for a coherent beat. This does not make every delay necessary; it means that “the model is slow” is not a complete diagnosis for every gap you notice.
Use playback controls for understanding
Pause when you need to inspect a relationship that is already on screen. Return to a previous explanation step when the next idea depends on something you did not catch. Adjust the explanation speed if the material is familiar or if you need more time to connect words with the drawing. These are controls over presentation, not a way to accelerate the provider’s reasoning.
A useful explanation leaves room for those choices without making you restart the entire conversation. Rayito supports live explanation controls so you can follow the current idea at a workable pace. Use the visible controls when you are unsure which keyboard shortcut is active; typing in another app should not be confused with controlling playback.
Try a smaller request before changing every setting
If a response feels slow, compare it with a short question about the same visible source. Asking for one relationship is easier to evaluate than requesting a complete tour, a detailed diagram, several app actions, and a summary at once. This is not a requirement to micromanage the drawing. It is a way to isolate whether the size of the request is part of the delay.
Voice selection can also change preparation behavior. Local models may need an initial warm-up, while cloud services depend on a network request. A changed voice or a missing local package can therefore affect the time before speech starts. Keep the source and question similar while testing one setting; otherwise you cannot tell what caused the difference.
A question to try“Explain only the first relationship, then let me respond.”
Report a delay with the stage that was visible
If you report a problem, describe whether it happened before the first answer, between narrated steps, after pressing Resume, or after answering a question. Mention the selected provider and voice, but do not include credentials or private screen content. That small amount of context is more useful than a general claim that everything is slow. It helps distinguish request latency, audio preparation, playback pacing, and a task that is intentionally waiting.