CUA S1 Forms: Run a 706K-Parameter GUI Form-Filling Model Locally
CUA S1 Forms is a 2.8MB model that fills GUI forms in one forward pass. Here's how it works and how to install it on your own machine.
What is CUA S1 Forms?
CUA S1 Forms is a 706,000-parameter model, about 2.8 MB on disk, built to do exactly one thing: decide what action to take on a GUI form field. Given a form element and a set of candidate values pulled from a document, it picks fill, check, click, or skip in a single forward pass. No chain-of-thought, no multi-turn reasoning, no API call to a large language model. It’s published on Hugging Face under cua-ai/cua-s1-forms, tagged as part of a “system-one” family of models built for computer-use tasks, and released under an MIT license.
The model acts as a decision layer inside CUA, an open-source framework that lets AI agents operate real computers by reading the accessibility tree of a live GUI and issuing clicks, keystrokes, and typed input. CUA S1 Forms plugs into CUA’s form-filling pipeline specifically, sitting between “here’s a document with extracted values” and “here’s what to actually type into this specific field.”
TL;DR
- CUA S1 Forms is a 706K-parameter, 2.8MB byte-level transformer that classifies a single GUI form action (fill, check, click, skip) in one forward pass instead of reasoning through it like an LLM would.
- The model reportedly scores 99.7% accuracy on real form-filling decisions, compared to roughly 83.6% for a general-purpose LLM API used as a baseline, according to the model’s Hugging Face card.
- It runs comfortably on CPU, drawing no meaningful GPU load even when a GPU is available, which matches its tiny size and architecture.
- The architecture is a two-layer, 128-width transformer with four attention heads that reads raw bytes instead of using a tokenizer, which is part of why it stays so small and fast.
- It works as a decision layer inside CUA’s driver, the tool that reads a computer’s live accessibility tree and performs the actual clicks and typing.
- In hands-on testing, the model correctly distinguished between near-identical field labels (a general phone number versus an emergency contact phone number), suggesting it reads label semantics rather than just pattern-matching similar-looking values.
- Installing it locally requires PyTorch, Git LFS, and two repo clones (the model repo and the CUA framework repo), all straightforward on a standard Linux setup.
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
How does CUA S1 Forms actually work?
Most AI approaches to filling out a form on screen involve handing a large language model the form’s structure, a document’s worth of extracted data, and asking it to reason field by field about what goes where. That works, but it’s slow and expensive at scale, especially if you’re filling out thousands of forms in a pipeline.
CUA S1 Forms skips the reasoning step entirely. It’s a byte-level transformer, meaning it reads raw text character by character instead of breaking input into tokens the way GPT-style models do. That removes the need for a tokenizer and vocabulary embeddings, which are usually a big chunk of a language model’s parameter count. Combined with a genuinely small architecture (two transformer layers, 128-dimensional width, four attention heads), the result is a model that fits in under 3 MB.
Its job at inference time is narrow: look at one form field, a short list of candidate values extracted from a source document, and pick one of four actions (fill, check, click, skip) plus, when relevant, which value to use. It’s a classifier dressed up as a tiny transformer, not a general-purpose assistant. That framing explains both why it’s so fast and why it’s not trying to compete with LLMs on anything outside this one task.
Is a 706K-parameter model actually reliable enough to use?
Based on the benchmark figures shared on the model’s Hugging Face card, yes, at least for the narrow task it’s built for. The model reportedly hits 99.7% accuracy on real form-filling decisions, with the card comparing that to a general LLM API scoring around 83.6% on the same kind of decisions. That’s a meaningful gap for a task that’s binary or small-multiple-choice by nature: pick the right field, pick the right value, or correctly decide to skip.
In hands-on testing, the model was given a form field labeled “phone number” alongside two candidate values (a phone number and a date of birth) plus the fill/check/click/skip options. It picked “fill phone number” with 100% confidence and correctly ignored the date of birth. A harder test followed: a field labeled “emergency contact phone” alongside both a regular phone number and an emergency contact number as near-identical-looking candidates. The model correctly picked the emergency contact value, which suggests it’s reading the actual field label semantics rather than just matching similar-looking strings.
That’s a meaningfully different failure mode than what you’d expect from a purely pattern-matching heuristic, and it’s the kind of decision that trips up naive rule-based form fillers.
What do you need to run it locally?
The setup is lightweight, matching the model’s size. On a standard Linux machine (Ubuntu was used in testing), the requirements are:
- PyTorch, installable via
uvor pip, since the model is distributed as a.ptand.safetensorscheckpoint. - Git LFS (Git Large File Storage), needed because the model repo stores large binary files (weights) as pointers rather than committing them directly into Git history.
- A clone of the model repo (
cua-ai/cua-s1-formson Hugging Face). - A clone of the CUA framework repo, which provides the driver and tooling the model plugs into.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
Once cloned, loading the model is a matter of running the load script bundled with the repo. On a GPU-equipped machine, the model loads onto the GPU but, notably, barely touches it during inference. Monitoring GPU memory during a test run showed no meaningful jump, consistent with a model this small being CPU-friendly by default. That’s a practical point: you don’t need a GPU at all to run this in production.
How does it connect to a real GUI form?
The model itself doesn’t touch pixels or windows. That’s the job of CUA driver, the component inside the CUA framework that reads a live accessibility tree from whatever’s on screen and executes actions like clicking, typing, or hotkeys. CUA driver exposes a broader toolkit too: listing open windows, listing installed apps, launching applications, and more.
The workflow demonstrated against a sample HTML patient registration form in Firefox looked like this: start the CUA driver, query it for windows on screen, get back a process ID and window ID for the target application, then query that specific window for its form elements (which returns the underlying accessibility tree, including field labels and structure buried in the page’s JavaScript). From there, CUA S1 Forms makes the fill/skip/check/click decision for each field, and the driver executes it, down to moving the mouse pointer and typing the value into the actual form in the browser.
The model is the decision-maker. The driver is the hands.
Is this the right tool for your use case?
If your workload involves filling out a small number of forms occasionally, a general LLM with vision or accessibility-tree input is probably fine and more flexible. Where a model like CUA S1 Forms earns its keep is high-volume, repetitive form-filling: intake forms, registration workflows, data-entry pipelines where you’re processing the same form shapes over and over and want speed and low cost per decision rather than open-ended reasoning.
Its narrowness is the point. It won’t help you reason about ambiguous or novel form layouts the way a large multimodal model might, and it’s not meant to. But for the specific job of “given this field and these candidate values, what do I do,” it’s fast, cheap to run, doesn’t need a GPU, and according to its published benchmarks, more accurate on this task than a general-purpose LLM API.
Frequently Asked Questions
What is CUA S1 Forms used for?
It’s used as a decision-making component inside GUI automation pipelines, specifically for filling out on-screen forms. It decides, for each form field, whether to fill it, check it, click it, or skip it, based on a field label and a list of candidate values from a source document.
How big is the CUA S1 Forms model?
It has about 706,000 parameters and takes up roughly 2.8 MB on disk, distributed as both a .pt PyTorch checkpoint and a .safetensors file on Hugging Face.
Do I need a GPU to run CUA S1 Forms?
No. It’s small enough to run efficiently on CPU. Testing with a GPU present showed negligible GPU memory usage during inference, meaning a GPU offers no real advantage here.
How accurate is CUA S1 Forms compared to using an LLM?
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
According to figures published on its Hugging Face model card, it scores about 99.7% accuracy on real form-filling decisions, compared to roughly 83.6% for a general LLM API used as a baseline, while being dramatically smaller and cheaper to run.
What do I need to install it locally?
PyTorch, Git LFS, a clone of the CUA S1 Forms model repo, and a clone of the CUA framework repo (which provides the driver that reads GUI accessibility trees and executes actions). No specialized hardware is required.