Yaochi Desktop 中文

YAOCHI DESKTOP · WINDOWS APP

Every action crosses six boundaries first

Yaochi is a digital assistant that runs on your own machine. You ask for things in one continuous session; it puts subagents to work reading the repository, editing files, running commands and checking tests. The model decides what to propose. You decide what actually happens.

See the whole path Bring your own model
Current stage

Not distributed yet, and there is no public download. Downloads and the closed beta will be announced on this page once signing and device validation are done.

An intent starts at the centre and asks its way outward, one boundary at a time.
  1. ActionIntent Intent
  2. Policy
  3. Approval
  4. CapabilityTicket
  5. ToolHost
  6. Evidence
An intent starts at the centre and asks its way outward, one boundary at a time.

ACTIONINTENT → EVIDENCE

The full path of a single action

Subagents never call tools directly. Every action they propose travels the same chain, and any layer can end it. There is no bypass: the main agent gets no shortcut for being the one who talks to you, and skills and MCP servers neither register tools nor step around approval.

  1. ActionIntent Intent

    The subagent files an intent that names the target paths, the arguments and the scope. It is recorded before anything runs, which makes it the anchor every later audit refers back to.

  2. Policy Policy

    The runtime rules on it against the scope this task currently holds. A path outside that scope cannot be talked into being allowed, and a refusal comes back attributed rather than as a vague failure.

  3. Approval Approval

    Anything that needs your word stops here and shows you exactly what it intends to do. Approve it once, trust it for this task, or refuse it. Stopping is the design, not latency.

  4. CapabilityTicket Capability ticket

    An approval buys a ticket bounded in both scope and time. It covers this action only. It does not settle into a standing permission, and it cannot be reused on another path.

  5. ToolHost Tool host

    Execution happens inside a constrained tool host. Path containment, extension limits, size ceilings and timeouts are enforced here, so a write outside the boundary is not logged after the fact — it does not happen.

  6. Evidence Evidence

    Diffs, command output, test results and summaries are sealed together. Long after the task closes you can still go back and see what was done and on what basis.

Workspace trust sits in front of the whole chain: an untrusted directory never flows into model context on its own, and the MCP servers, hooks, LSPs, skills and scripts inside a project do not run by themselves.

ONE DIGITAL ASSISTANT

Just one box

Say it the way you'd say it to a person. Nothing to file: no conversation to start, no tasks to sort into groups, no working out which agent to ask, no pasting last week's context back in. You say it, and it takes it from there.

Left

Work in flight

Connected workspaces, tasks it grouped on its own, running subagents, and anything waiting on you. An index, not a list of chat tabs.

Centre

One continuous session

Your own words, the assistant's replies, progress, and the final delivery. Switching tasks does not open a new conversation.

Right

Context

The plan, approvals, diffs, tests and evidence behind whatever is selected. Quiet by default, open when you want it.

The three regions are not three separate applications

Roles are data, not hard-coded

Seven definitions ship with it and five of them are Builder — they differ only in which tools they may touch, not in code of their own. Adding a role should never have meant touching code. Write your own, edit them, switch them off. A definition shapes how a subagent thinks and which tools it asks for, but it grants nothing: what it can actually use is always the intersection of what the definition asked for and what this task is authorised for.

  • Main The only role that talks to you and delegates. Not a configurable definition, and no shortcut for being the one you hear from
  • Explorer Sorts out what is known, what is not, and the smallest next step
  • Builder Locates, reads, edits and verifies code inside the authorised scope
  • Verifier Judges on the evidence handed back, and never implies it saw more

LOCAL-FIRST

Your data stays on your machine

Yaochi runs no cloud service that stores or processes your task data. The desktop app stands on its own; accounts and cloud models are optional connections.

Only three things ever leave your device: task context sent to the model endpoint you configured, call arguments sent to a local MCP server you reviewed and enabled, and read-only web text you approved. You turn each of them on, and you can turn each of them off.

BRING YOUR OWN KEY

Bring your own model

No Yaochi account is needed to start. Pick a provider and its base URL is filled in for you and re-checked by the runtime; or point it at any OpenAI-compatible endpoint of your own, which is how a local Ollama connects through its compatible interface.

WHERE THIS STANDS

Not distributed yet

Yaochi Desktop is in private review ahead of any public release. There is no public download and no installer in circulation. Windows x86_64 is the first target.

The runtime, the data formats and the tool protocol have been cross-platform since the first version. Support for macOS, Linux and domestic Chinese hardware will be announced as specific combinations of CPU, operating system, WebView and inference runtime — not as a blanket claim of “Linux support”.

Still to finish before distribution

  • Validation across a real Windows device matrix
  • Security and chaos regression
  • Code signing for the installer and executables

An unsigned beta build will not be presented as a trusted public distribution or as an update source. This page is where downloads and the beta will appear when they open.

Requirements

Operating system
Windows 10 / 11 (x86_64)
Runtime dependency
Microsoft Edge WebView2
Model
Configured by you, local or remote
Account
Not required