Running a Local 9B Decision Model for Web Browsing Automation: Clef-Flash in Practice

Automating Web Browsing with a Lightweight 9B Model

A developer recently shared an experimental project on Reddit: using a decision model called Clef-Flash 9B, running entirely on-device, to automate web browsing. What makes this approach stand out is that it doesn't rely on a massive cloud-based LLM. Instead, a lightweight local model handles the decision-making — figuring out what to click and what to do next.

For anyone interested in edge computing and on-device AI, this project is worth a closer look. It takes on a practical question: without access to a model with hundreds of billions of parameters, how far can a 9B-scale model take you when it comes to agent-style web interaction?

A Clear Division of Labor: Decision Model + Real-Time Text Extraction

The core architecture reflects a deliberate separation of responsibilities. The author notes that this decision model cannot generate text on its own, so the system is designed to extract and process text from web pages at runtime to inform the model's decisions.

In other words, the 9B model acts as the judgment center of the "brain" — not the content creation center. Text, buttons, links, and other on-page information are extracted in real time and fed to the model, which then decides on the next action. By narrowing the model's role to pure decision-making, the system enables a relatively small model to handle the job without being burdened by long-form text generation.

This is a classic strategy for deploying smaller models in production: rather than chasing a single all-capable giant model, break complex tasks into well-defined sub-steps and use the most appropriate component for each.

This separation of "perception" and "decision" has a more formal name in the AI agent world: Tool Use or the Perception-Action Loop. Traditional large-model agents typically require models with 70B+ parameters to simultaneously handle webpage comprehension, step planning, and instruction generation — all at significant computational cost. Clef-Flash 9B takes a "specialization" approach: the model only handles action decisions (where to click, what to fill in a form), not content generation. This type of task demands relatively modest reasoning capability, and 9B parameters is sufficient.

Real-time text extraction is typically implemented by parsing the page's DOM (Document Object Model) tree, organizing structured information — button text, link anchor text, form labels — into a format the model can read. The advantage of this approach is that it's lightweight and privacy-friendly, requiring no screenshots or vision models. The downside, as discussed later in this article, is that plain text can't capture visual state information.

Three Test Tasks and Completion Times

The demo video showcases three specific tasks with their respective completion times:

1. Check when Tibo's usage quota resets — 17 seconds
2. Find the latest stable version of Godot for Windows x86_64 and download the standard version (not the .NET version) — 13 seconds
3. Play a video about the Jev model on YouTube — 11 seconds

All three tasks completed in the ten-to-twenty-second range — quite impressive. The second task is particularly notable: it's not just a simple lookup. It requires distinguishing between the "standard version" and the ".NET version" and then executing a download. Completing that in 13 seconds suggests the model's decision accuracy in targeted scenarios is solid.

It's worth noting that in this demo, the instructions were entered manually. The author emphasizes, however, that the entire pipeline can be fully automated — simply add an LLM upstream to generate and issue those instructions, and you have an end-to-end autonomous loop. The current demo validates the "decision execution" layer, while the "instruction generation" layer is left to a higher-level model.

Simple Navigation Works; Complex UI Is the Weak Spot

The author gives an honest assessment of the results: the system performs well on websites with clear navigation structures, but success rates drop significantly on sites with complex UI elements.

Two categories are specifically called out as problematic: toggles and multiple tabs. These interactions are tricky because their states can't always be inferred from page text alone. Whether a toggle is on or off, or which tab is currently active, depends more on visual layout or DOM state — exactly the kind of context that pure text extraction tends to miss.

This exposes the architectural limits of a "text-extraction-driven decision" approach. For pages dominated by text and links, the model can understand and operate effectively. But once complex controls requiring an understanding of visual layout or interaction state come into play, the combination of a 9B model and text-only input starts to fall short.

This limitation is known in the browser automation field as the Visual Grounding Problem. Multimodal models like GPT-4o and Claude 3 can directly interpret UI visual state from screenshots — determining whether a toggle is active or which tab is selected — but this requires integrating an image understanding model, significantly increasing computational cost.

Another approach is to leverage the Accessibility Tree — structured UI state information that browsers expose for assistive technologies like screen readers. It's richer than plain text, includes state attributes for controls (such as aria-checked and aria-selected), and avoids the overhead of processing raw pixels. Leading browser agent frameworks like Playwright Agent and Browser Use already combine accessibility trees with visual screenshots to improve handling of complex UIs. For Clef-Flash's current text extraction approach, incorporating the accessibility tree may be a lighter-weight path forward than full visual understanding.

What This Experiment Tells Us

Beyond the specific numbers, the most valuable takeaway from this project is the lightweight agent architecture it demonstrates. It shows that under local, small-model constraints, a carefully decomposed task pipeline with real-time information extraction can genuinely power a subset of browser automation use cases.

But it also draws a clear ceiling: complex interactions remain a hard problem. Going further likely means incorporating visual understanding capabilities or improving how the system models page state — not just relying on text extraction.

For developers exploring on-device AI agents, this is both an inspiring and cautionary example. Lightweight solutions offer real advantages in cost and privacy, but there's still significant engineering work required to handle the full complexity of real-world web pages. The complete demo is available in the YouTube video the author shared.