io.github.libtmux.Pane.Pane.awaitText

Reach for this last. It reads the screen on a timer, which is a heuristic about a program's output rather than a fact about it, and the cheaper waits are exact:

• If you wrote the command, append ; tmux wait-for -S name to it and block on Server#channel . tmux blocks server-side and returns on the signal itself, so nothing is inferred from the screen and one tmux process covers the whole wait. That is the only deterministic wait here, and it is the right one whenever the command is yours.
• If you did not write the command — a daemon printing that it is ready, a build somebody else started — this is the case polling is for.

The timeout bounds the whole wait, reads included. Each read is given only what is left of it, so a slow tmux cannot stretch a short wait out to the server's default deadline, and text that first appears after the deadline is not reported. The first read alone is allowed at least a quarter of a second, so a timeout shorter than one read can still answer TextOutcome#PRESENT_AT_ENTRY .

Waiting longer is also less reliable, not more: tmux frees the oldest scrollback once history-limit is reached, so a long wait on a productive pane can end up reading past the lines it was watching for.