u/Mean-Standard7390

The phone in the video is a Samsung Galaxy A04e - SM-A042F/DS, 4GB RAM.

GLM-Edge-1.5B-Chat is running locally on the phone through llama.cpp.
The browser is a normal desktop Firefox session on Amazon.

The task was simple:

• find a 24-count pack of AA alkaline batteries
• find yellow rubber ducks
• add both to the cart
• stop before checkout

The model sees the browser through E2LLM/SiFR, the structured browser perception layer we’re building. Instead of screenshots or raw HTML, it gets a compact structured representation of the current browser state and chooses what to do from that.

The run went:

cart 0 → batteries → cart 1 → rubber ducks → cart 2

No checkout, Buy Now or payment action was attempted.

The same setup was run twice on the A04e and both runs ended with the two expected items in the cart.

On this phone the full run takes about 9 minutes 22 seconds.
The same workflow on a Galaxy S21 takes about 3 minutes.

The video is sped up 4×, but it is one continuous run with no steps removed.

What's interesting here isn’t that GLM-Edge-1.5B-Chat is fast on this hardware. It really isn’t.

It’s that a 1.5B model running locally on a 4GB budget Android phone can still make useful decisions against a real, changing Amazon UI when the perception problem is reduced enough.

Up front: I'm one of the people building the page-perception layer used here. We started by testing small local models. The result turned out to be more interesting than the original test. 12 small models, 3 verifiable tasks, logs, and offline replay.

Setup: Galaxy Note 8 (2017, Android 9, 6 GB), llama.cpp in Termux, Qwen3-0.6B Q4_K_M. A laptop with Chrome open, not headless. The phone drives the browser through our relay.

What the model does: it gets a structured representation of the page (here, about 10 named links or fields, roughly 200 tokens), picks one by name, and at the end copies the facts it was given into JSON. Everything else (capturing the page as structure, candidate selection, the click, reading the facts, verifying the result) is done by the stack around it. The model never sees HTML, a screenshot, or a URL.

Tasks:

1. sandbox, books.toscrape.com - category, book, price/rating/stock;

2. live Wikipedia - from an unrelated site to the Galaxy Note series page, pick "Note 8" among "Note 8.0", "Samsung Galaxy Note 8.0", "Galaxy Note 8.0", "Note FE" and other similar names on a page with roughly 760 interactive nodes, return the release date from the infobox;

3. five fields, including the UPC from a table.

Each task: 10 runs, checked against a fixed expected value.

Results for 12 models on task 1 (same script, same prompt):

Model Params Task 1 Note

Qwen3-0.6B 0.6B 10/10

Qwen2.5-1.5B 1.5B 10/10

GLM-Edge-1.5B 1.5B 10/10 rating as digit

Gemma-2-2B 2.6B 10/10

Llama-3.2-3B 3B 10/10

MiniCPM5-2B 2B 9/10 "£" -> "$" once

Qwen2.5-0.5B 0.5B 6/10

LFM2.5-1.2B 1.2B 0/10 placeholder

Llama-3.2-1B 1B 0/10 pseudo-code

Gemma-3-1B 1B 0/10 placeholder

LFM2-350M 0.35B 0/10 random click

Gemma-3-270M 0.27B 0/10 placeholder

Qwen3-0.6B on Wikipedia: 10/10; on the five-field task: 10/10

Control:

Everything the same, but raw HTML instead of structured browser perception: on the sandbox it gets there 4 times out of 5, at 12k tokens and 22 minutes per task instead of about 500 tokens and 80 seconds; on Wikipedia the page HTML is 467k characters, 9% of it fits into a 16k context, and the model does not find the link in that 9% - 0/3.

Important limits:

the tasks are name matching and copying. Where judgement about the page is needed, 1.5B breaks - it can't pick "next" among topical decoys. Pagination was not tested.
BTW on the account question: 'replay.py' (see github repo) rebuilds the prompts from the logs and runs them through any OpenAI-compatible local server. Whether your model picks "Note 8" among the decoys takes ten minutes to check, without us.

This is a measurement on three fixed tasks, not a benchmark.

Repo:
github.com/e2llm/edge-browser-agent - scripts, every JSONL as is (including early runs with harness bugs), model hashes, environment. replay.py re-runs the model side offline from the recorded candidates on any local server - no relay, no account.

NB: This isn't a new idea. AgentOccam showed the same general effect for the GPT-4 class, WebLINX and MindAct for small fine-tuned models. Here it is tested at the extreme: no fine-tuning, below 1B, on a 2017 phone.

TL;DR

• Pointed Codex (gpt-5.6, medium) at a live ServiceNow incident queue via browser tools
• 4 incidents triaged, AI work notes posted on all four, verified in the Activity stream
• 6m 55s total. Zero incident fields changed - recommendations only, the human decides

Everyone shows Codex writing code. We pointed it at a ServiceNow ticket queue instead.

Setup: Codex CLI + browser tools over MCP. Real ServiceNow dev instance, live queue. The model reads the page as a structured snapshot. It sees the form, the fields, the activity stream.

Task: triage the queue. Read each incident, assess priority, recommend an assignment group, post a work note. Don't change any fields - a human approves.

Result:

INC	Recommended	Assignment group	Posted
INC0000020	P4 Low	Field Services	Yes
INC0000018	P3 Moderate	Service Desk	Yes
INC0000007	P3 Moderate	SFA application team	Yes
INC0007001	P1 Critical	Payroll application team	Yes

It caught that the payroll server is down, users are locked out, and this is a critical incident P1. With rationale, next actions, and the right team.

All four notes posted (I asked for 4 in the prompt) and verified in the activity stream. 6m 55s. No field changes, no random clicks, no "element not found".

The interesting part: it never misread the page. ServiceNow is exactly the kind of enterprise UI that breaks agents: iframes, dynamic forms, elements re-rendering under you. Stale state gets re-read. Weather, not failure.

Honest boundary: a test with 4 incidents. No long runs yet. But it's proof the perception layer works on one of the hardest enterprise UIs.

The pattern matters more than the demo: the agent recommends, the human approves. Notes only. That's how this earns trust with real queues.

Tools: Codex (gpt-5.6-sol, medium) + E2LLM (extension + MCP).
Format: SiFR (Single-File RAG, pronounced "see-far") - the whole page state as one file the model reads.

Been running long browser tasks through ChatGPT on the web and hit a limit I can't find documented anywhere. Any prompt whose answer involves continuous tool work in the browser stops at right about 25 minutes 45 seconds. 25:42, 25:42, 25:44, 25:50, 25:50. Documented runs only. Still never longer. Same wall every time.
It resets on the next prompt. So a genuinely long task looks like:
Session 1 - 25:42. It says it just stopped. Me: "proceed."
Session 2 - 25:42. Says it just stopped again. "Proceed."
Session 3 - ...
I'm driving an external browser through an MCP connector, not the sandboxed VM browser.

Has anyone hit this? Is it documented somewhere I haven't found? Everything I can find just says "tasks take 5-30 minutes" but it's not about that.

Been running long browser tasks through ChatGPT on the web and hit a limit I can't find documented anywhere. Any prompt whose answer involves continuous tool work in the browser stops at right about 25 minutes 45 seconds. 25:42, 25:42, 25:44, 25:50, 25:50. Documented runs only. Still never longer.
One run closed 13 items, another 15, another was on a completely different site. Same wall every time.
It resets on the next prompt. So a genuinely long task looks like:
Session 1 - 25:42. It says it just stopped. Me: "proceed."
Session 2 - 25:42. Says it just stopped again. "Proceed."
Session 3 - ...
I'm driving an external browser through an MCP connector, not the sandboxed VM browser.

Has anyone hit this? Is it documented somewhere I haven't found? Everything I can find just says "tasks take 5-30 minutes" but it's not about that.

https://youtu.be/hnVE5uPmOLI

Disclosure: posted by the team behind E2LLM/SiFR, the browser-perception layer shown here. The SiFR specification is MIT-licensed: https://github.com/e2llm/e2llm-sifr

The MCP angle: one live browser session, a real signed-in Duolingo tab, a Hindi lesson - and three different MCP clients taking turns driving it through the same server. Claude Opus 4.8 starts. At 2:09 it is stopped and the task is handed to GPT-5.5 Medium in ChatGPT; at 4:35, to Nemotron 3 Ultra via Perplexity. Each handoff is manual and on screen. Same tab, same browser state, no restart - the clients share nothing except the same MCP server and what each reads from the page.

What makes the swap work: every client calls the same tools (sifr_capture, query, inspect, act, batch_act) and gets the same structured SiFR view of the page - roles, text, actionable elements, selectors, positions. Session state lives browser-side, not in any client, so a mid-task client swap just works. Client-agnostic by construction, not by adapter code.

The recording runs uncut - the swaps, the prompts, and the moment the disk fills up and stops the recording are all on screen, with 12 correct answers in a row at that point.

To reproduce: install the Element to LLM MCP add-on (distinct from the regular capture extension), connect any MCP client.

Chrome MCP add-on:

https://chromewebstore.google.com/detail/ddjlkdonfmjfblighhpppkcnkiaplhfd

Firefox MCP add-on:

https://addons.mozilla.org/en-US/firefox/addon/element-to-llm-mcp/

Setup guide:

https://e2llm.com/docs/setup/

MCP tools reference:

https://e2llm.com/docs/mcp-tools/

Questions welcome - the capture format and the client-swap mechanics are fair game in the comments.