Comments URL: https://news.ycombinator.com/item?id=50396469

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49859211

Points: 2

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=49845850

Points: 1

# Comments: 0

We were wondering how many computer use tasks actually need a full general purpose LLM (e.g. gpt-6-astra, claude-opus-5 etc.) to think through all their decisions and steps. Some tasks require thinking about a plan, exploring different paths, recovering from failure. Other tasks are a question of making local decisions, like this value should go in this box, or should I check this box, or this element should be ignored.

We wondered how far we could go with a small model trained to only make these kinds of decisions.

Our inspiration was Typesafe's Jev and its System One Model framing. This is a nod to the dichotomy between thinking quickly, automatically, and intuitively (system 1) vs. thinking slowly, analytically (system 2), as described by Daniel Kahneman.

The interesting question for us was: what happens if you give a model an interface of current context, and a set of possible choices, and you ask it to return a probability for each choice? This kind of model does not generate output token by token like most LLMs do, but rather scores the options you give it, which you can check, trust, and use to drive your app's behavior.

CUA-S1 is our answer for narrow, specialized decision models for computer use. Our first release is CUA-S1-FORMS. We built this from ideas and code in jevlike, and then trained a second model just to handle form interactions. It has 706k parameters, and the original checkpoint is 2.8 MB.

The first training iteration took less than 30 minutes on synthetic data. Given a set of structured elements and values extracted from a document, it predicts whether to use the given value, CHECK, CLICK, or SKIP for each element. It does not predict new values for text fields, and does not consider screenshots. Element decisions are scored together, and your code can order the actions, and Cua Driver will execute them one at a time.

A first evaluation of this specialist vs. hosted Jev on our form task:

- For the whole decision set: 99.7% correct vs 83.6%.

- For the subset of steps that require an action: 100% correct vs 96%.

- For the subset of steps that are just leaving already-filled fields alone: 100% correct vs 74%.

The specialist was trained specifically for this task and convention (just press skip for already filled boxes), while hosted Jev has not been fine-tuned for it, so this is an experiment in scoped specialization.

We measured 7-9 ms to score a form locally vs. 260-280 ms per call to hosted Jev including network latency, though those samples measure different things and are not end-to-end form completion times.

Our interest here is in the space between a brittle script and a general agent loop. The content and layout of form fields vary enough that scripts get unwieldy, but the set of available decisions can remain narrow and well scoped. We want to explore the possibility of a general agent encountering something novel, and passing well understood decisions over to specialists like this.

That is a direction we are looking into. The current release is for forms only. We're open sourced the synthetic data generation, training, evaluation, and Driver integration under libs/cua-s1 with an MIT license.

Comments welcome! Especially if you are building computer-use agents and have run into a recurring decision that is too variable to script but is too narrow to call another LLM for.

Comments URL: https://news.ycombinator.com/item?id=49767564

Points: 95

# Comments: 10

Comments URL: https://news.ycombinator.com/item?id=49653196

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49533004

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49512549

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49482640

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49350030

Points: 1

# Comments: 0

correct. these figures apply to llama.cpp inside the macOS guest configuration we tested. Lume is the VM frontend we used, while Apple's Virtualization.framework provides the virtual GPU. bare-metal llama.cpp is unaffected.

> The fix here works around a problem where the VM was causing llama.cpp to select the wrong kernels.

mostly, with one nuance: llama.cpp is selecting the correct kernels for the capability answers it receives. the stock guest reports an older Apple GPU family and a 32 KB threadgroup memory limit, so llama.cpp chooses slower kernels. Our process-scoped layer reports the tested Apple 9 and 64 KB values while allowing llama.cpp to select newer paths that the paravirtual GPU successfully execute

the layer itself though works at the Metal API boundary, independently of llama.cpp. other Metal compute and graphics apps now may select newer paths from the same capability answers, although this is still preliminary and each app needs separate testing. for example, MLX-LM stayed flat in our tests

historically related limitations have been coming up across Apple Silicon VM frontends for a while e.g. Tart tracked MPS/GPU support back in 2023: - https://github.com/openai/tart/issues/501 - https://github.com/openai/tart/issues/1032

UTM also has related cases where apps detect the Apple paravirtual Metal device but falls back to software rendering: https://github.com/utmapp/UTM/issues/7671

Comments URL: https://news.ycombinator.com/item?id=49259339

Points: 307

# Comments: 41