UI-TARS Desktop and the two products hiding behind one repository name

One repository, two products, and tags that do not say which

This repository does not hold a single application. It ships two, and the README sets them side by side: Agent TARS, a general multimodal agent stack delivered as a CLI and a Web UI, and UI-TARS Desktop, a desktop application that provides a native GUI agent on top of the UI-TARS model, with its entry point at ./dist/main/main.js and @electron-toolkit/tsconfig in the toolchain.

That split matters the moment you read a version number. The three most recent tags are v0.3.0-beta.11 dated 2025-09-09, v0.3.0-beta.12 dated 2025-09-19, and v0.3.0 dated 2025-11-04, and the announcement attached to that v0.3.0 is titled Agent TARS CLI v0.3.0. A tag reading v0.3.0 therefore describes the command line tool, while a desktop user is really on the v0.2.0 line announced on 2025-06-12. The consequence for a reader is concrete: search for the desktop app and you land in a repository whose release history is mostly about a CLI. Pin the tag you tested and write down which product it belongs to, because the numbers collide.

The entire model configuration is four lines in .env.example

The application ships no model of its own. Everything about inference sits in one sample file:

VLM_PROVIDER=huggingface
VLM_BASE_URL=http://your_endpoint.aws.endpoints.huggingface.cloud/v1
VLM_API_KEY=hf_your_api_key
VLM_MODEL_NAME=your_model_name

VLM_PROVIDER ships set to huggingface and points at a Hugging Face serverless endpoint template, so the choice of provider is a value you edit rather than a mode you select in the interface. Three of the four values are placeholders, which means a fresh clone has no working vision model until you supply an endpoint, a key, and a model name. Nothing in the repository documents what the app shows you when those values are still placeholders, so you have no documented failure mode to recognise. Apache-2.0 covers the code and stops there: the weights live in a separate UI-TARS repository, and the endpoint is a service you operate.

pnpm is pinned at 9.10.0, so npm install is the wrong door

The root package.json names its package manager and the workspace enforces it: pnpm-workspace.yaml defines the workspace, pnpm-lock.yaml is the only lockfile in the tree, and .node-version pins the Node release. The scripts follow the same discipline.

"packageManager": "[email protected]",
"bootstrap": "pnpm i",
"dev:ui-tars": "turbo run ui-tars-desktop#dev",
"lint": "eslint . --ext .js,.jsx,.cjs,.mjs,.ts,.tsx,.cts,.mts --fix",
"test": "vitest"

There is no npm run dev here. The desktop entry point is turbo run ui-tars-desktop#dev, which reaches into apps/ and packages/ for that one target, and the devDependency on @common/configs is declared as workspace:*, a form that only resolves inside this workspace. The consequence for someone who wants the app rather than the source: the root is private, named monorepo, versioned 0.0.1, and publishes nothing. The installable pieces are the workspace packages, one of which is @agent-tars/cli, not the root directory.

Remote operators arrive with no configuration step and no documented access control

The v0.2.0 announcement of 2025-06-12 introduced a Remote Computer Operator and a Remote Browser Operator, described as completely free, needing no configuration, activated by clicking to remotely control any computer or browser. The tree also carries examples/operator-browserbase/ as a sample operator, and examples/gui-agent-2.0/ and examples/presets/ alongside it.

So the repository ships a path where an agent drives a machine you may not be sitting at, and it documents nothing about authentication, about who is allowed to connect, about which ports are opened, or about how a session is recorded. The one diagnostic tool in the release history is the Event Stream Viewer that arrived with Agent TARS CLI v0.3.0 on 2025-11-05 for data flow tracking and debugging, and that notice describes the CLI, not the desktop app. If you evaluate the remote path, the network exposure question is one you have to answer yourself, and on a shared or unattended machine that is the first gap to close.

v0.3.0 adds streaming and timing, and ships no numbers

The v0.3.0 notice lists streaming support for multiple tools, naming shell commands and multi-file structured display, runtime settings carrying timing statistics for tool calls and deep thinking, the Event Stream Viewer, and exclusive support for the AIO agent Sandbox as an isolated all in one tool execution environment. Read that list closely and every item is about observability or execution isolation. Not one is a performance claim: no latency figure, no token cost, no task completion rate.

The instruments exist without published output. The scripts carry a coverage command and a test:bench entry running vitest bench, codecov.yml sits at the root, and the dev toolchain includes electron-playwright-helpers and @playwright/test, yet no result table appears anywhere in the README. The consequence is that you cannot size a deployment from the documentation. Budget for measuring the operator loop on your own endpoints, and start with the timing statistics in the runtime settings, since that is the instrumentation the maintainers added for exactly this question.

Hooks and changesets decide what you can commit and what you can install

The contributor gate is visible in the tree. .husky/ holds the hooks, .lintstagedrc.mjs governs what runs on staged files, .secretlintrc.json with .secretlintignore blocks secrets before they land, and .commitlintrc.cjs plus the commit script wired to opencommit enforce the message format. Releases come out of the same machine: .changeset/ collects entries, publish:packages runs bash scripts/release-pkgs.sh, and publish-beta:packages runs bash scripts/release-beta-pkgs.sh, which is where the beta tags in the history come from.

Two consequences. For a user, the npm packages move on their own schedule, decoupled from the desktop application, so the version of @agent-tars/cli you install is not the version the news entries describe. For a fork, the hooks travel with the clone, and a team that does not want opencommit rewriting commit messages has to edit .husky/ and the commit script before its first commit rather than after it fails.

The deployment tutorial lives outside the repository, in a Lark document

Repository docs carry the local and remote operator paths in docs/quick-start.md and the cloud deployment in docs/deployment.md, but the news entry of 2025-01-23 records that the Cloud Deployment section was updated in the Chinese version with ModelScope information, and the link it points at is a Lark document rather than a file in the tree. The English side of the repository is not where that update landed. docs/sdk.md arrived on 2025-02-20 as a cross platform toolkit for building GUI automation agents, and rfcs/ holds design notes while examples/ holds the rest of the runnable material.

The consequence: the instructions that decide how a model is served live somewhere you cannot diff against the code, and the file that was refreshed in January 2025 is the Chinese one, with README.zh-CN.md as its counterpart here. Before planning a deployment, confirm that the provider advice you are following matches the commit you are building, and keep your own copy of the endpoint settings next to it instead of trusting the tutorial to stay current.

Editorial conclusion

UI-TARS Desktop suits someone willing to host a vision model endpoint and drive the agent themselves, and it fits a team that already runs inference infrastructure. It is a poor fit if you expect a self contained install, a single version line across the stack, or documented access control on the remote operators. Before you commit, fill in the four VLM variables and confirm the endpoint works, read which of the two products the tag you are pinning belongs to, and decide for yourself how a remote computer session is exposed and audited.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes