Yappy vs HeyClicky on an involved task: computer use and browser use
Two macOS computer-use agents, the same Notion job application, the same answers file, the same prompt. Yappy finished about 5× faster, with a third of the actions, a ninth of the tokens, and about a seventh of the cost — and it never took over the screen.
A better run, at a fraction of the cost
Both agents reached the same completeness: every field filled except the resume, which needs a native file-upload dialog, and neither submitted. So this is not about one agent doing more — it is about how much time, effort, and disruption it took each one to reach the same finished form.
End-to-end time
From trigger to the agent reporting the form done. Lower is better.
Of HeyClicky's 13m 14s, about 2m 20s was spent stopped, waiting for the user to bring the form to the current Space and tell it to continue. Yappy waited on no one.
Actions taken
Steps the agent performed to fill the form. Fewer means a more direct path. Lower is better.
HeyClicky repeatedly re-read the whole screen as it worked; Yappy filled the fields directly.
Input tokens consumed
Total model input across the whole task, in millions. Lower is cheaper. Both are mostly cached reads.
Working from the screen means sending the model a picture of it again and again; reading the page directly keeps the context small.
Estimated cost of the run
Both runs' tokens priced on the same published rate card — $3 per million uncached input, $0.30 per million cached, $15 per million output — so this reflects token volume, not either vendor's private pricing. Lower is better.
The same task cost about seven times more to run with HeyClicky, almost entirely because it re-sends the screen to the model on nearly every step.
The full scorecard
| Measure | Yappy | HeyClicky |
|---|---|---|
| End-to-end time | 2m 38s | 13m 14s |
| Active execution time | 2m 38s | ~10m 54s |
| Time waiting on the user | 0s | 2m 20s |
| Manual "continue" needed | None | Yes, after an off-Space stall |
| Actions taken | 32 | ~104 |
| Input tokens (mostly cached) | 1.21M | 11.24M |
| Estimated cost of the run (same rate card) | ~$0.60 | ~$4.24 |
Behaviour and reliability
| Property | Yappy | HeyClicky |
|---|---|---|
| Works with the window in the background | Yes | No — needs it foregrounded |
| Works when the window is on another Space | Yes | No — stalled and asked for help |
| Leaves your screen and focus alone | Yes | No — brought the browser forward |
| Reused a single browser tab | Yes | No — opened several windows of the form |
| Completed the resume upload | No (handed off) | No (file picker failed) |
What we tested
The task was a genuine, live job posting: Notion's Software Engineer, Developer Platform application, hosted on Ashby. It is a long single-page form — name, email, phone, location (a typeahead), LinkedIn, resume upload, pronouns, two yes/no policy questions, a "how did you hear about us" multi-select, and the voluntary equal-opportunity self-identification groups.
We wrote the answers once into a Markdown file and gave both agents the same instruction: open the application link from that file in a new Chrome tab, fill every field from the file, do not submit, and report what was filled. The resume was a real file path, so both agents faced the same file-upload step.
Methodology
The goal was a fair, reproducible, execution-based comparison rather than an impression. Everything ran on one Apple-silicon MacBook Pro on macOS, back to back, in a quiet window.
Same task, same prompt, isolated runs
Each agent ran alone on a freshly closed form, so neither could write into the other's fields. (Running them at the same time confirmed why that is necessary: both target the same URL in the same browser and overwrite each other. Those runs were discarded.)
What counts as "done"
We scored completion the way OSWorld2 does — by inspecting the final state, not by trusting the agent's claim. After each run we read every field's value straight from the page and checked it against the answers file. "Filled and confirmed" means the value was actually there.
What we measured
For each run we recorded three things from the run on the test machine: the wall-clock time from trigger to the agent reporting done, the number of actions it took to fill the form, and the model tokens it consumed. We turn the tokens into an estimated dollar cost by pricing both runs on the same published API rate card (shown with the cost chart above), so cost reflects token volume rather than either vendor's contract. We separate active execution from time spent waiting on the human, because one agent needed manual help mid-task and the other did not. How each agent is started also differs and is reported as a result: Yappy is started hands-free by voice or a keypress and then runs on its own; HeyClicky is started the same hands-free way but, once running, needs the form kept in front of it.
Limits, stated up front. This is one run per agent on one task on one machine — an honest, transparent head-to-head, not a statistical benchmark. Model choice, network, and the live form all add variance. We publish the method and the raw figures so it can be repeated and challenged. HeyClicky is a capable, well-built product; the differences here are about how each approach behaves on this specific background-form-fill task, not a verdict on everything either app does.
Why the gap exists
The difference comes down to where each agent does its work.
HeyClicky works in the foreground
HeyClicky operates on the window you are looking at, driving the screen the way a person would. That is general and flexible, but it needs the target window on screen, in front, on the Space you are on. In our run it brought the browser forward repeatedly, opened the same form in several windows, and stopped outright when the form was on another Space until we moved it over and told it to continue.
Yappy works in the background
Yappy fills the page directly without bringing the window forward, so it reaches a tab that is minimized or on another Space and never steals your focus. That is why it finished in one quiet pass while you kept working in another app.
Neither agent reaches your logged-in browser through raw remote debugging: since Chrome 136, Chrome ignores the remote-debugging switches on your normal profile as an anti-cookie-theft measure.1 Both therefore work through the browser's ordinary surfaces instead.
Looking for a HeyClicky alternative?
If what drew you to HeyClicky was a Mac agent you can talk to that actually operates your apps, Yappy does the same class of work and adds the thing a background agent is supposed to have: it gets out of your way. You hold a key, say what you want, and it works in the apps you already have — minimized, on another Space, while you keep typing. On this job-application task it was about five times faster and never once interrupted the person who asked for it.
Sources
- "Changes to remote debugging switches to improve security," Chrome for Developers blog — from Chrome 136, the remote-debugging switches are ignored on the default browser profile.
- OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments (arXiv:2404.07972, NeurIPS 2024) — the execution-based evaluation model this test follows. See also OSWorld 2.0 (arXiv:2606.29537).
- HeyClicky — product and public changelog. The foreground and Space behaviour described here is what we observed during the test run on 6 September 2026.
- Yappy — Yappy 0.4.32. All timings and counts are from each agent's run on the test machine, 6 September 2026; the method above is sufficient to reproduce them.