FuXi

You will appreciate the packaging on day one: a single static binary, no runtime, no dependency tree to keep alive on three machines. The trait that decides it in daily use is session durability, because checkpoints and forking a session mean a long task survives your mistakes, and you can branch an approach rather than starting the conversation again from the beginning.

Pick it if you want a terminal agent that installs in one command and answers to your own provider. Pick OpenCode when transparency matters more to you than packaging, or Aider if you want the edit loop under your thumb.

Everything here is testimony. Command classification, permission granularity and the safety model are described in a usage document published by the same party that ships the binary, and there is no source to compare it against. The product is one month old and carries a preview label. A tool asking for shell access should be the easiest thing on this board to audit, and this is the hardest.

What it does right: permissions are described at fine granularity rather than as a single trust toggle, which at least means the vendor has thought about the question it will not let you verify.

One design choice is worth isolating. 1. Deciding whether a command is dangerous by analysing its parsed structure is categorically stronger than matching text, because shells offer unlimited ways to spell the same instruction and a string comparison loses to every one of them. 2. That approach also degrades predictably: an unparseable command is an unknown, not a false negative.

The claim is documented and not demonstrated, no evaluation accompanies it, and the documentation is a single usage page. The method is right. Whether the implementation is right is not a question the published material can answer.

The shape is familiar: give away the client, monetise the inference. Sign-in for vendor-hosted models sits beside the option to use your own provider, which means the revenue depends entirely on convenience beating configuration, and that is a thin advantage against competitors doing the same thing with published source.

Distribution is real and strange. Over three thousand stars accrued to a repository containing documentation and installers, which measures attention rather than adoption. No entity detail, no funding signal, no pricing page. Likely outcome is a paid tier within two quarters or silence. Position: pass on the managed service, treat the client as disposable.

The cost line is easy and irrelevant. What I need is a counterparty, and the row gives me a preview product first released last month, no published entity, no support terms and no retention statement. Nothing describes SSO, SCIM or an audit trail. It does provide a documented token flow for unattended runs, so the pipeline story is real, which makes the absence of everything else more frustrating rather than less.

Onboarding would be an hour. Not yet. Revisit when there is a company to sign a contract with and a security page to send to my auditors.

The licence is a single proprietary line, so a fork is not on the table and I hate that. What keeps it in my toolbox is the escape hatch: a base URL from config, an environment variable or a command flag, which means the model can be anything speaking the common API, including one served locally, and my keys never touch the vendor. MCP works in both directions, so my servers attach and its tools are exposed back.

Model freedom without source freedom is half of what I want. I will run it, and I will not depend on it.