Which early signals have actually been useful for rerouting an LLM request?

Discussion

We have been working on runtime control for LLM calls, and the part I keep coming back to is this:

A failure signal is only valuable if it appears early enough to change what happens next.

The obvious signals are familiar:

first-token latency is far outside the normal range

streamed token gaps become unstable

retries begin accumulating

total request duration spikes

error rate rises for a specific provider or model

an agent tool starts repeating or taking progressively longer

But I think these signals lead to two different kinds of intervention.

The first is normal runtime rerouting.

A request degrades or fails now. The runtime records the incident and chooses a different provider or model for the next comparable request. This is safer because it does not abandon an in-flight request, but it also means the current request is already lost or degraded.

The second is TTFT early rerouting.

Before the first token arrives, the request crosses a first-token-time threshold. If there is enough remaining time, the runtime can send the same request to an alternate execution target inside that request rather than waiting for the next one.

This is much harder in practice.

A slow first token can mean provider congestion, cold start, queueing, an unusually difficult prompt, or simply normal tail latency. Rerouting too quickly creates duplicate work and unnecessary cost. Waiting too long means the alternate request cannot catch up anyway.

So I am interested in what people have found actually works in production:

Which signal has given you the earliest reliable warning that a request is going bad?

Do you use different thresholds per provider, model, environment, or workload?

Has anyone made same-request TTFT rerouting work without creating a lot of false interventions?

For agents, what is the equivalent of TTFT? Is it tool-start delay, repeated tool calls, step count, or something else?

For transparency, I am building this in WAIL, a commercial AI runtime control and governance product. Technical reference: wailinfra/wail-runtime.

Posted Sep 10, 2026, 7:10 PM UTC

110
Loading comments…