TuriX-CUA: a desktop GUI agent you configure through config.json

The problem TuriX-CUA targets: software with no API and no automation hook

Most automation tooling assumes an interface you can call. Playwright drives browsers, vendor SDKs drive SaaS products, and shell scripts drive servers. The remaining software, which includes in-house tools, older desktop clients, and anything that only exists as a window, has no such interface. TuriX-CUA takes the other route. Its README states the agent has "No app-specific APIs" and that "If a human can click it, TuriX can too", naming WhatsApp, Excel, Outlook and in-house tools as examples. The audience is therefore people who own a desktop workflow that spans several applications and cannot be stitched together with APIs: a research task that starts in a browser, continues in a document editor, and ends with a message to a colleague. The README's own demo descriptions follow that shape, for instance generating a bar chart from a Numbers file received in Discord, inserting it into a PowerPoint, and replying to the sender. If your task is a single HTTP call, this is the wrong layer of abstraction and you will pay for screen capture and model inference to do something curl already does.

How the loop works: a planner, a skill library, and a swappable VLM brain

The architecture described in the README has three named parts. A brain is the vision-language model policy that decides each step. A planner selects relevant skill guides, using their name and description, and the brain then reads the full instructions of the chosen skill to plan. Skills themselves are markdown playbooks, which means the behaviour of the agent can be extended by adding documents rather than code. The README describes the model as "Hot-swappable" and says you replace the VLM policy through config.json without touching code. The advertised default is a Qwen3-VL model, which appears both in the repository topics and in the January 2026 update notes about model capability improvements. Multi-model support was upgraded in the core architecture in the same period. MCP support is the fourth piece: the README says the agent can be hooked up to Claude for Desktop or any other agent through the Model Context Protocol, and there is a demo described as Claude searching for AI news, calling TuriX over MCP, and having the result written into a Pages document and sent to a contact. What the README does not document is the observation format, the action space, or how the planner decides which skill is relevant. Those are the details that determine whether a GUI agent is reliable on your screens, and they are not in the supplied material.

Getting it running on macOS 15+: app, Python 3.12, permissions, config.json

The Quick Start is titled macOS 15+ and is the only fully documented path. It has four numbered steps: download the app, create a Python 3.12 environment, grant macOS permissions, then configure and run. The permissions section is split into Accessibility and Safari Automation, which tells you the agent's reach is bounded by what macOS will let a process control. Accessibility is what allows synthetic clicks and keystrokes into other applications; Safari Automation is what allows the browser portion of a task. If either prompt is denied or silently skipped, the agent will likely appear to run while doing nothing, and the README does not describe a diagnostic for that state. Configuration is a single config.json, and the README's own phrasing for swapping models is "Change in config.json and go." Skills are optional and sit under step 4.4. There is also a published ClawHub skill at clawhub.ai/Tongyu-Yan/turix-cua, and the repository carries local OpenClaw skill packages: a macOS package on main with SKILL.md and scripts/run_turix.sh, and a Windows package on the multi-agent-windows branch with SKILL.md, scripts/run_turix.ps1, and agents/openai.yaml. Installation and permission details for those packages live in OpenCLaw_TuriX_skill/README.md rather than the top-level README, so you will be reading two documents.

Platform support is split across branches, which is the main adoption cost

The most consequential fact in the README is not a feature, it is where each platform lives. Linux support, announced March 16 2026, is on branch multi-agent-linux, and the instructions are explicit: run git checkout multi-agent-linux first. A faster, lighter OpenClaw Flash/Fast Mode skill for macOS sits on mac_legacy, again with a checkout instruction. The Windows OpenClaw local skill is on multi-agent-windows, updated March 5 2026 with direct dispatch and what the notes call safer pre-flight checks. Only macOS appears to be the default main-branch experience. This means a team running mixed machines cannot install one thing everywhere; they either standardise on macOS or accept that Windows and Linux users are tracking divergent branches with their own skill packages and their own scripts. Branch-based distribution also makes upgrade cost hard to reason about, because a fix on main may not exist on the branch you run, and the README gives no merge or backport policy. If you need a single supported install target across an organisation, that constraint alone may rule this out.

The benchmark numbers, and what they do and do not tell you

The README claims 64.2 percent (229.88 / 358) on the full OSWorld benchmark at 50 steps, placing the agent third overall among submitted agents, and states it was built and optimised for macOS where it reaches an 80 percent or higher success rate on a self-hosted OSWorld-style Mac benchmark. It also notes the OSWorld environment is Linux-based and that the team used zero Linux training data. Two things deserve care here. First, the 80 percent figure is on a self-hosted benchmark, so it is not directly comparable to the public leaderboard number; the comparison you would want, same tasks, same scoring, is not available. Second, the README's feature table claims the default model outperforms previous open-source agents such as UI-TARS on success rate and speed on Mac, but the supplied material contains no head-to-head table. Treat the leaderboard placement as the stronger of the two claims because it is an external harness, and treat the Mac number as indicative until you reproduce it on your own applications. Neither number is a substitute for testing on the specific software you intend to automate.

Where a GUI-only agent breaks, and what to use instead

The failure mode is structural rather than incidental. A GUI agent observes pixels and emits clicks, so anything that changes the screen invalidates its assumptions: a modal dialog, a notification banner, a login session that expires mid-task, a window that opens on a second monitor. The README's permission section hints at a second class of failure, where the operating system withholds control and the agent has no way to proceed. Because the README does not describe retry logic, checkpointing, or a recovery path, you should assume a long multi-application task is fragile until you observe otherwise. The real alternative for browser-centric work is Playwright or Selenium, and the difference in approach is fundamental: those tools address elements through the DOM and a stable selector, so a layout change does not break them, and they run headless on a server. TuriX-CUA cannot do that, because its whole premise is that no such interface exists. Conversely, if your task is entirely inside a browser, using a pixel-driven agent adds capture and inference cost for control you could have had deterministically. The honest split is: DOM-based tools for web applications, TuriX-CUA for the desktop software that has no other door.

Licence, maintenance, and what the release cadence implies

The repository is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are preserved. That is a permissive licence and it is the reason a company can evaluate this without a procurement conversation, but it also means no warranty and no support obligation from the authors. This is not legal advice; check how MIT interacts with any model weights or third-party services you pair with the agent, because the licence covers the code, not necessarily the model you point config.json at. On maintenance, the release history is v0.2 in December 2025, v0.3 in January 2026, and v0.4 in March 2026, with the last push to the repository dated July 2026. Between those releases the README records a steady stream of platform work: Windows skill updates in March, Linux support in March, the mac_legacy fast mode in March, and a 3.0.0-alpha announcement in April that folds TuriX CUA and a CLI into one productivity app with TuriX-work and TuriX-code. That alpha matters for planning: if the direction of travel is a bundled commercial app distributed from ngtechai.com, the open repository may increasingly serve as the agent component rather than the whole product. Budget for reading branch notes before every upgrade, not just release notes.

Editorial conclusion

Adopt TuriX-CUA if you are on macOS 15+ or Windows, you are willing to grant Accessibility and Safari Automation permissions, and you want a GUI agent whose model you can swap in config.json without touching Python. Do not adopt it if you need a single installable package across macOS, Linux and Windows from main, or if a GUI-only loop is a poor fit for headless servers. Before committing, verify three things yourself: that the OSWorld 64.2 percent figure and the 80 percent Mac number reproduce on your tasks, that the branch you intend to run (main, multi-agent-linux, multi-agent-windows, or mac_legacy) is the one still receiving the updates you need, and that the permission prompts actually resolve on your macOS build, because the Quick Start lists them as a required step rather than an optional one.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. TurixAI/TuriX-CUA on GitHub