Model Releases
Ministral 3 3B on a Galaxy S21 relayed a conversation between Gemini and Z.ai across Chrome and Firefox
A follow-up to my earlier post about small models on phones. Last time it was fixed tasks in a single browser. This is something else. Ministral 3 3B Q4_K_M in llama.cpp on a Samsung Galaxy S21, four
A follow-up to my earlier post about small models on phones. Last time it was fixed tasks in a single browser. This is something else. Ministral 3 3B Q4_K_M in llama.cpp on a Samsung Galaxy S21, four CPU threads, no GPU, running on battery, relaying between Chrome with Gemini open and Firefox with Z.ai open. There is no direct integration between the two services. The model on the phone works with both web interfaces, and the script carries the replies between them. After a round of testing we did 10 runs as a series and got 10 out of 10: four browser hops each, forty replies, twenty automatic resets to a new chat. Run time from 7:59 to 11:55, median 9:29. Over the 98 minutes of the series the battery went from 79% to 63%. What I find interesting is this: The script contains no per-site conditions and no hard-coded selectors. The same file drives both pages. The model gets neither a screenshot nor HTML - it receives a short list of named elements and answers with a single line saying which one to use. In one representative capture, Gemini 118 page nodes collapse to two candidates, in Z.ai 124 to four. The earlier series gave a raw-HTML control with Qwen3-0.6B: about 25x the prompt tokens and 17x the time on a small sandbox page, while a live Wikipedia page did not fit the phone's context and scored 0/3. So the question is not how smart a 3B is on its own, but what it is shown. A couple of observations about the model: In Z.ai the layer hands it two send buttons, the real one and a wrapper. The model picked the right one 20 times in a row. In Gemini there is a single candidate, and it is not asked. The first call is expensive: 9 seconds to choose the composer, after which the same decisions take about 3 seconds. In the recorded run, the reset decisions were the most expensive: 4.7 and 5.6 seconds. It returns JSON unpredictably, sometimes bare, sometimes in a code fence. The parser survives it, but the behaviour drifts. One run out of ten needed a recovery: the composer did not take the message, the script re-captured the page and retried. The retry happened before the send, there was no second click on the button. That run is in the log as it is. I attached the video of the full run with no cuts, almost nine minutes, including the waiting. The script, the public JSONL log of all ten runs with SHA-256 hashes and the redaction procedure, plus the control measurements from the earlier series, are on GitHub. Link: https://github.com/e2llm/edge-browser-agent This is a harness for one repeated scenario with two services, not a browser-agent benchmark. submitted by /u/Mean-Standard7390 [link] [comments]
Related
Source: r/LocalLLaMA | 2026-09-16