Tianshu Harness

The deciding trait is that it was built around one model rather than against all of them. Long sessions cost noticeably less because the tool is shaped to reuse what has already been sent, and that only happens when somebody optimises for a specific provider instead of writing to the lowest common denominator.

The same choice is the risk, because a tool tuned to one vendor inherits that vendor's future. Pick it if you have settled on that model. Pick something neutral if you expect to keep changing your mind.

The word is doing more work than the mechanism. Rules about which of the agent's tools may run are a useful thing to have and they are enforcement at the wrong layer: once a command is approved, it executes as the user with everything that user can reach, and a build script that does something unexpected is outside the policy's reach entirely. The gap is between what the term implies and what the documentation describes.

What it does right is document the permission model at all, which most competitors leave to discovery.

1. A cache hit rate is only interpretable against the traffic that produced it, and every variable that would make this number comparable is absent. Long sessions on a stable repository would produce a high figure under almost any implementation; short exploratory ones would not.

2. Reporting a range rather than a distribution also conceals whether the low end is common or exceptional.

3. The underlying technique is sound and well understood. The complaint is not about the design, it is that a measurement was published without the conditions that make it a measurement.

Building the differentiator on top of another vendor's serving behaviour is efficient and dependent. Caching characteristics are an implementation detail the provider may change in any release, and when they do, the advantage evaporates without anybody here being consulted or compensated. That is a position, not a moat.

Moat: none durable; the tuning is copyable and the substrate is rented. Likely path: the model vendor ships its own harness, or the optimisation becomes table stakes. Position: use it while the pairing holds, and do not build a cost model around it.

Distribution is easy and support is not. A single install command means my desktop team can ship it, and the documentation my engineers would need when something goes wrong is not written for them, which turns every incident into a translation exercise before it becomes a fix. Onboarding cost is where that lands, and it lands per person.

There is no console, no directory login, no audit trail and nothing that runs unattended, so sixty installs are sixty configurations nobody can inspect. Not yet, and not until the documentation covers my teams.

Supporting a self-hosted runtime alongside the vendor it was optimised for is what keeps this interesting to me. The tuning is somebody else's advantage; the escape hatch is mine, and it is a documented provider rather than a footnote about compatible endpoints.

Tool servers attach over the protocol, the licence is permissive enough that a fork stays legal, and the whole thing installs as one package I can pin. Shipping both a terminal and a graphical surface from the same project is more work than most maintainers accept, which I respect even though I will only ever use one of them.