ukkin vs ChatGPT Operator: On-Device vs Cloud Agents

This comparison was revised in October 2026 to match ukkin’s documented capabilities and platform support and to correct how the cloud agents work.

The question

Should I build my AI agent with ukkin, OpenAI’s Operator, or Anthropic’s computer use?

The question is slightly malformed, and it is worth saying why before comparing anything. These are three different kinds of thing. ukkin is an open-source Android app for building background agents that drive other apps on the phone. Operator was OpenAI’s consumer agent that browses the web in a hosted browser, and its capabilities have since been folded into ChatGPT’s agent mode. Computer use is an Anthropic API tool that lets a developer’s own harness feed Claude screenshots and carry out the mouse and keyboard actions Claude returns.

The 60-second version: the cloud agents send what they see to a hosted frontier model; ukkin’s design intent is to keep the agent and its data on the phone. Whether that intent holds for a given ukkin build depends on where its model runs, which we come back to below.

What each project is

ukkin is an MIT-licensed Flutter app. You describe a workflow in plain English and a conversational agent builder turns it into an agent that runs in the background, scheduled around device conditions such as Wi-Fi, charging and time of day. It reads screens and acts on other apps through the Android Accessibility Service. Android is supported today; iOS automation is on the roadmap and not implemented.

OpenAI’s Operator launched as a research preview of an agent that operates a browser hosted by OpenAI: it navigates pages, fills forms and completes web tasks, handing control back to the user for things like logins and payments. The browser runs in OpenAI’s infrastructure, so the pages it sees are processed there. OpenAI has since merged Operator into ChatGPT’s agent mode.

Anthropic’s computer use is a tool in the Claude API rather than a finished product. The developer runs the environment — Anthropic recommends a dedicated virtual machine or container with minimal privileges — takes screenshots, sends them to Claude, and executes the actions Claude returns. The screenshots go to the API; what they contain depends entirely on what the developer lets the environment show.

The dimensions

Dimension	ukkin	OpenAI Operator	Anthropic computer use
What it is	Open-source Android app	Hosted consumer agent	API tool for developers
Where actions happen	On the user’s phone	In an OpenAI-hosted browser	In the developer’s own environment
What it acts on	Installed Android apps	Websites	Whatever the environment exposes (desktop, browser)
How it sees	Accessibility tree, plus visual-model code for screen understanding	Screenshots of the hosted browser	Screenshots from the developer’s environment
Model	Local-first by design; check your build	OpenAI’s hosted models	Claude via the API
Data leaving the device	None if the model runs locally	Page content the agent sees	Screenshots sent to the API
Mobile	Android today, iOS on the roadmap	Web-based	Depends on the developer’s harness
Licence	MIT	Proprietary service	Proprietary API

When to use which

Consider ukkin when:

The workflow lives inside Android apps the user already has, using their existing sessions.
The data the agent sees is personal — messages, email, shopping history — and you want it handled on the phone.
The task is routine and repetitive: watching prices, monitoring mentions, triaging email, drafting replies for review.
You are prepared to work with experimental, Android-only software and to verify where its model runs.

Consider Operator / ChatGPT’s agent mode when:

The task is web-based and the content is not sensitive.
You want a finished consumer product rather than something to build on.
The task needs frontier-model reasoning.

Consider Anthropic’s computer use when:

You are building your own agent and want to control the environment it operates in.
The task needs desktop or OS-level actions, not just a browser.
You can sandbox the environment so that the screenshots it produces contain only what you are willing to send to an API.

The privacy / capability trade-off

The underlying trade-off is between capability and privacy:

Cloud-model agents reason with frontier models. They can handle open-ended, multi-step tasks that small local models cannot. The cost is that what the agent sees is processed off the device.
Phone-side agents can keep data on the device, and can act on apps the user is already signed in to. The cost is a much smaller model, if the model is local at all, and therefore less sophisticated reasoning.

ukkin’s documentation is candid that local-first is the design intent rather than a guarantee for every configuration: its roadmap lists an on-device LLM for natural-language understanding as a phase still to come, and some build configurations use a cloud LLM for the conversational agent builder. If the privacy property is why you are choosing ukkin, verify the build you are running. Putting a local model inside a Flutter app is the problem llamafu addresses, but ukkin’s documentation does not name a specific runtime, so we do not claim an integration.

A concrete example: watching prices

Suppose you want to be told when items on a shopping wishlist drop in price.

With ukkin, you describe the workflow, and a price-watching agent runs in the background on a schedule you choose, opens the shopping app through the Accessibility Service, extracts prices, keeps a history and notifies you. It uses the app and session already on your phone.

With Operator, the hosted browser visits the shop’s website, which typically means signing in inside OpenAI’s browser to see a wishlist. The reasoning happens on OpenAI’s side.

With computer use, you would build the harness yourself: provision an environment, sign in there, and loop screenshots through the API. Flexible, but it is a development project rather than a setting.

None of the three is “best”. They answer different versions of the question.

What ukkin does NOT do

No iOS automation yet. It is Android-only today.
No frontier reasoning. A phone-side model is small. ukkin suits routine tasks, not open-ended research.
No guarantee of on-device inference in every build. Check where the model runs.
No cross-app workflows yet. Chaining email into calendar into reminders is on the roadmap.
No published reliability or timing figures. We have not measured how often its agents complete, or how long they take, on a stated device and app set.