The user has entered a support question. A local model starts downloading, a progress indicator appears, and the network becomes slow. There is still a perfectly usable text box on the page. The product decision is whether that person can finish the original task while the enhancement struggles. I would settle that question before choosing the model, because an optional feature should remain optional at the moment it becomes inconvenient.
Sylwia Laskowska’s browser AI experiments describe practical local applications alongside download, device and reliability limits. The author reports both useful results and approaches that did not work well enough for the demos. I have reviewed the article, not reproduced those experiments. The example below is an independent design exercise: an ordinary support form with an optional button that suggests a clearer ticket.
Count the wait the user has to own
Assume, purely for illustration, a 150-megabyte model payload and a sustained download rate of 20 megabits per second. Using decimal units, 150 times eight divided by twenty gives sixty seconds for the payload alone. Connection overhead, competing traffic, model preparation and inference would add time. The actual model size and connection could be very different. The calculation is useful because even this optimistic assumption produces a wait long enough to require a product decision, rather than a decorative spinner.
For the hypothetical form, I would leave manual submission available throughout. The enhancement would begin only after the user asks for it, and the interface would distinguish downloading from preparing and producing a suggestion. Those states explain different waits. A single message saying thinking hides whether any computation has started. It also makes cancellation ambiguous. Is the product cancelling a download, abandoning a result, or merely closing the progress display? The implementation contract should answer that question even if the interface uses simpler language.
Now consider a sequence: the user requests a suggestion, edits the original question, cancels, and requests another suggestion. The first result might arrive late. I would give each request an identity and associate it with the input version it used. A late result from the cancelled request must not replace the user’s newer text. This is a proposed state-management rule, not a claim about how the source article’s demos behave. It protects the meaning of cancel even when an underlying operation cannot stop instantly.
A suggestion should not silently become the record
When a result is ready, I would show it beside the original input and require a deliberate accept action. A suggested ticket can contain an incorrect detail or flatten an important qualification. The user needs to retain the original account and decide which version to submit. Accepting the result should also be separate from sending the ticket. Otherwise a helpful rewrite button has unexpectedly become an external communication action. The feature’s label, visible behaviour and actual authority should agree.
The unhappy path deserves a complete design. If the model cannot load, the text remains. If the device cannot run it, the manual form remains. If local storage no longer contains a previously cached model, the page should show the real loading state again rather than promising an instant return. These are requirements for the proposed product. Whether a chosen browser runtime can meet them must be verified on the supported devices and current library version. The article’s reported successes cannot establish that for a different application.
A small acceptance test can exercise the interface without downloading a real model. A stub result arrives after cancellation; another arrives after the input changes; a third reports a load error. In each case, the original text must survive and the manual path must stay usable. Those tests would verify state handling. Separate device tests would still be needed for memory, loading, inference and cancellation behaviour. Passing the cheap tests should not be described as proving that the model works on mobile hardware.
Keep a narrow promise
Local processing can be appealing when a task fits the device and the application handles its inputs appropriately. It does not remove the need to check model licences, data paths or fallback behaviour before a real release. I would keep this particular promise small: the enhancement may help the user rewrite a ticket, while the basic form continues to work independently. If fulfilling that promise requires loading the model before anyone can type, the design has already departed from its own rationale.
The cancel button is a good place to discover whether the architecture respects that promise. Pressing it should have a clear consequence, preserve the user’s work and prevent an obsolete result from taking over later. Those are ordinary interface responsibilities, even when the feature behind the button is new. Before celebrating a browser’s ability to run a model, I want to see what the page does when someone decides they would rather finish the task themselves.
