/**
 * How often to re-check for the assistant's reply while a turn is in flight.
 *
 * The assistant has no streaming transport: the prompt is a fire-and-forget POST
 * and the reply is discovered by re-fetching the message list. So this interval
 * is the granularity of the whole experience — it bounds how late the answer
 * appears in chat AND how late speech can start, because auto-speak only fires
 * once a poll observes the reply completed.
 *
 * A flat 1500ms was the previous behaviour, which meant up to 1.5s of dead time
 * after the answer was already sitting on the server, and made streamed text
 * arrive in visible jerks rather than flowing.
 *
 * ★ The schedule is a compromise, not free. Every poll re-fetches the newest
 * messages in full rather than a delta, so a faster interval is a real increase
 * in request rate. It is spent where it buys the most — the first few seconds,
 * where most replies land — and given back afterwards, so a long-running turn
 * costs no more than it used to.
 *
 * The proper fix is a delta fetch (`sinceMs`, which the shared client already
 * supports) or a streaming transport; both are larger changes than this.
 */
/** While the answer is most likely to land. */
export declare const POLL_FAST_MS = 600;
/** Still active, but the cheap wins are gone. */
export declare const POLL_STEADY_MS = 1000;
/** Long-running turn: back to the original cadence. */
export declare const POLL_SLOW_MS = 1500;
export declare const POLL_FAST_UNTIL_MS = 6000;
export declare const POLL_STEADY_UNTIL_MS = 20000;
/**
 * Delay before the next poll, given how long this turn has been running.
 *
 * `elapsedMs` is injected rather than read from a clock so the schedule is
 * testable and cannot drift with a mocked timer.
 */
export declare function pollDelayMs(elapsedMs: number): number;
//# sourceMappingURL=assistantPollSchedule.d.ts.map