Imagine a small app that sorts inquiries into schedule, place, or other. If its page loads without internet access, can its AI classify messages too? We planned to check 10 Korean–English pairs of synthetic inquiries with matched meanings (20 inquiries total) in a browser on one Mac, but we never ran a measured test of the AI actually classifying them (NOT RUN). An unattributed connection attempt prevented acceptance of the traffic observation and controls, so work stopped during preparation. Classification results and speed in both languages remain unknown. This article explains the test plan and why preparation stopped, then offers untested design questions for readers building apps with AI.
The planned block simulated disconnection within the test browser context, not across the entire computer. The checks intended to verify that block also have no accepted execution results.
In this article
Check the page, files, and computation separately
The descriptions associated with the five documentation links below rely on the research record checked on October 4, 2026. Those pages were not reopened while drafting or revising this article.
The Transformers.js documentation checked then described browser execution of compatible models, including a WebGPU path. WebGPU is a way for browser code to use GPU computation. Support in a runtime, however, does not guarantee that a particular model will work on your device. Transformers.js project
There are three separate questions: Does the page load? Are the files needed for computation available? Does the app use those files to produce a new answer? A browser service worker can serve cached files to display an offline page. Reopening that page alone does not establish that AI computation occurred. MDN service worker guide
Model files alone may not be enough. Execution code and supporting WASM files may also be needed. The ONNX Runtime Web deployment guide distinguishes these assets. To examine preparation time and the initial download, we need an inventory of all required files. ONNX Runtime Web deployment guide
Here, “without a server” needs a narrow meaning: not sending AI computation to a remote server. Our design still uses a small server on the same computer to deliver the page and files. Where computation happens and where files come from are different questions.
Use the same inquiries in three conditions
The prepared inputs are 10 pairs with matched Korean and English meanings. They contain no real customer inquiries. The table and all the checking and scoring rules below describe plans, not results.
| Condition | What we intended to check | Planned count |
|---|---|---|
A: Before model preparation, test browser context offline |
A not-prepared message and a manual classification option |
20 UI checks |
B: After preparation, online |
The model's answers as produced and agreement with the classification rules |
3 passes of the same 20 sentences |
C: After preparation, test browser context offline |
Starting fresh computation from stored files and classifying inquiries |
3 passes of the same 20 sentences |
Each language has four schedule, three place, and three other inquiries. B and C would each repeat the same 20 sentences in ascending ID order, descending order, and an order shuffled with seed 27. The final plan also included one unscored warm-up call asking for a short greeting in Korean and English. That call did not run either.
Both languages would receive the same English instructions to avoid adding variation from two instruction translations, with answers restricted to schedule, place, or other. Here are two actual English inputs, each with a Korean counterpart of the same meaning. “My Saturday booking is unchanged. Please tell me only the room number.” is a place inquiry despite mentioning a day. “When does the class start, and where is it held?” asks about both schedule and place, so its assigned category is other. These are the app's classification rules, not universal correct answers.
The planned score would allow only leading and trailing whitespace to be removed before an exact match to a lowercase label. Malformed output, refusals, truncation, errors, and timeouts would remain unsuccessful attempted items; human corrections would be separate. Items never submitted would remain unattempted, not incorrect. Planned, attempted, completed, and unattempted counts would be reported separately, with failed attempts included in any attempted-item denominator. A would have no model-accuracy score. Repeating the same 10 pairs does not provide a more varied set of inquiries, and shared English instructions cannot be assumed to affect both languages equally. Even a completed measurement would not support a general ranking of Korean and English performance.
For C, we planned to shut down the inference worker—the unit that would handle classification while online in condition B—block the test browser context's networking, and create a new inference worker. This would not restart the browser or operating system, and a diagnostic using an already-loaded engine would not count as C. A fresh worker or reference value, a label on the page, or GPU activity alone cannot prove new model computation. Code and actual model-call and raw-answer records would need to exclude stored answers or a keyword shortcut and show that the answer key stayed outside the app and prompts.
We also planned to compare file inventories and actual reads after preparation, warm-up, and online classification. This was an untested acceptance requirement: C would have to use necessary files already present after warm-up. The aim was to prevent a required file acquired later from hiding a gap in preparation.
The block itself also needs checking. We planned to verify, separately in the page, worker, and service worker, that test requests bypassing the cache succeeded online. We would then check whether the same kind of request failed after blocking. Playwright, a browser-automation tool, simulates disconnection only within a specified browser context—the isolated browser session under test. It does not disconnect the entire computer from the internet. Playwright offline setting
What preparation established
On October 6, 2026, a check on this Mac found that Chrome 154 obtained a WebGPU adapter and reported the shader-f16 feature. This was not a measurement of GPU computation or model execution.
The initial WebLLM/Qwen candidate did not proceed because explicit license evidence for the converted model files was insufficient. On October 7, 2026, we selected LiquidAI's LFM2.5-1.2B-Instruct-ONNX at revision 10f72e70abf67ac0fd7ebf15bc5854726891d864, Transformers.js 4.3.1, and ONNX Runtime Web development build 1.31.0-dev.20260914-8d85527a0. The internal record names LFM Open License v1.0 for the converted files and records file identities and access checks without a login (HEAD requests). Recording the license name is not a general permission to use the files or a legal or security conclusion. Sizes and hashes in public metadata and access checks do not mean every file was downloaded and its contents verified. This selection did not establish successful Korean or English classification.
The first execution plan stopped during setup after downloading the runtime libraries. The review at the time identified a defect in the measurement tools' initialization and connection procedure as the likely cause. No warm-up or classification calls occurred. None of the second plan's four preliminary check attempts was accepted either. Zero transferred bytes and an older cache fill were not accepted as proof that this specific worker request was served from cache.
Later preparation revised the test-tool design for linking cached files to the worker that would execute them, and for observing and blocking traffic through a proxy—a relay that watches traffic and can block it. A reviewer separate from the tool author checked the tools on October 26: 77 tests passed without launching a browser or opening network connections. Hash comparisons covered local candidate, source, and input files for the test tools. These results checked the tools' logic; they did not verify downloaded model files, establish a working cache-to-browser-worker execution chain, prove complete browser control, or demonstrate AI execution.
Why did the final check stop?
On October 26, we performed one browser startup check that did not load a model. File and environment preflight checks passed, but an attempted connection to www.gstatic.com:443, a Google domain, was observed before navigation to the test page. The proxy, configured to reject all external destinations, blocked it. The recorded number of bytes the proxy forwarded to that external destination was zero; the component that initiated the attempt remained unidentified. That count covers only bytes forwarded by this proxy to that destination; the attempt's content and traffic on paths outside the proxy remain unknown.
The Google hostname and timing alone do not establish that the app or model sent the request. Nor could we ignore an unattributed connection attempt and conclude that traffic observation was complete. This was the fourth startup refusal along the final preparation route. In this run, the same destination was refused again after background-traffic suppression options had been added. The records do not establish which components those options covered or their effectiveness. Permitting an unidentified destination would not resolve the gap in observation. Following the predefined stop rule, we ended measurement preparation for this route without retrying or expanding the list of permitted connections.
A, B, and C therefore all remain unrun. This was a failure to prepare for measurement, not evidence that offline classification failed or that the model cannot run on this device. Classification accuracy, response time, and differences between the languages remain unknown.
Questions to carry into your own app
The following questions are an untested design proposal for each feature. When asking AI to build an app, ask for evidence that answers them, using the page/files/computation distinction and conditions A, B, and C above, instead of accepting a one-line “offline support” claim:
- Where does computation happen, and which files are needed before blocking networking in the test browser context?
- Have the converted files' license and identities been checked, distinguishing listed hashes from verification of the actual bytes received?
- Does the app show different messages for “not prepared yet,” “preparation failed,” and “the AI failed while running”?
- Which browser context does the block cover, and is unobserved transfer left unknown rather than reported as zero?
- What establishes that fresh computation began after networking was blocked?
- Is each required language tested separately, and can users sort an inquiry by hand without losing what they typed?
- What network requests does the app send outside classification, and which areas remain unobserved?
Stored files should not be assumed to last forever. Browser storage has limits and eviction conditions; the design proposal therefore includes a message for missing required files, whose behavior we did not test. MDN storage quotas and eviction criteria
We did not empirically validate these questions' effectiveness or the message the app would show when AI is not ready. Even verified local computation would not establish privacy across the whole app. Distinguishing the evidence needed for “the page loads” from that needed for “it classifies my inquiry” remains an untested design proposal.
AI assisted with research and drafting. The author reviewed the final manuscript and directed the revisions.