[Idea]: Show Notebook Chat request time and estimated progress

[stewfarq]

What are you trying to do?

When I submit a Notebook Chat question, I want useful feedback about how long
the current request has been running and a clearly labelled estimate of its
progress.

This is particularly useful with slower local models or larger notebook
contexts, where a request can take one or two minutes and the existing spinner
does not indicate whether the wait is typical.

What feels difficult or missing today?

Notebook Chat currently shows a loading state while a request is running, but
the user cannot see:

• when the request started;
• how long it has been running;
• the final elapsed response time;
• any rough indication of how the current wait compares with previous requests.

A long request can therefore look stalled even when it is progressing normally.

What outcome would help?

A compact Notebook Chat request-status panel could show:

• request start time;
• request end time after completion;
• live elapsed request time;
• final response time;
• clearly-labelled estimated progress;
• estimated remaining time while the request is active.

The estimate should never be presented as actual backend stage progress.

A local prototype estimates duration from previously completed requests for the
selected model and caps in-flight progress below 100%, only reaching 100% when
the response actually arrives.

Prototype UI

I have a working local prototype showing the request status directly above the
Notebook Chat model selector and prompt input.

Example shown in the prototype:

• Status: Processing
• Start: 26 Aug 2026, 00:26:58
• Elapsed request time: 28.5 s
• Estimated progress: 28%
• Estimated remaining: 1m 14.2s

How do you handle this today?

I currently judge progress from the spinner and external timing/logs.

I have built and tested a local frontend prototype that displays request
start/end times, elapsed duration and heuristic progress without changing the
backend API.

Additional context, examples, or possible directions

The prototype measures client-observed Notebook Chat request duration, so I
would label it elapsed request time / response time, not server processing
time.

The current prototype:

• uses performance.now() for elapsed timing;
• keeps a per-model duration estimate in browser localStorage;
• updates that estimate from completed requests;
• caps in-flight estimated progress at 95%;
• sets 100% only when the response arrives.

Before an upstream PR I would make the UI fully i18n-compliant, use the active
locale for date/time formatting, and add deterministic frontend tests with
fake timers.

The implementation would remain narrowly scoped to Notebook Chat frontend
telemetry and its focused frontend tests.

I can help implement and test an approved work item.

[lfnovo]

Thanks for building this before asking — the prototype and the care with labelling estimates as estimates show. Still, the direct answer is no, for two reasons:

• Estimates for local models don't hold. Duration depends on context length, hardware load, quantization, KV cache state and more; a history-based estimate is wrong exactly in the cases where the wait is longest. No mainstream AI interface shows progress for a completion, and that's why. Even labelled, a bar that reads 28% sets an expectation the system can't keep.
• The chat runtime is about to change significantly. We're redesigning how chat and research execution work in Open Notebook, and a UI layer written against today's synchronous request would be built on ground that's moving.

The right answer to "is it stalled or working?" is streaming — tokens arriving is the only honest progress signal. That comes with the runtime work, not as a patch on the current one. When it lands, testing it against slow local models is exactly where your setup helps.

Status: answer — not planned; the need is addressed by streaming in the upcoming chat runtime. Closing this thread.