DSCode

The deciding trait is that the usage is shown to you rather than reconciled later. Knowing what a session consumed while you are still in it changes how you ask for things, and it is the difference between a tool you trust with a long job and one you keep interrupting to check on.

If you are on a flat subscription and never think about tokens, this solves a problem you do not have. Pick it when the meter is something you actually watch. Pick a subscription tool when you would rather pay once a month and never see a number again.

The isolation is unspecified. A runtime that patches files and runs parallel agents leans on that boundary for everything, and the documentation describes it by category rather than by mechanism. Without a named backend a user cannot reason about what escapes it, cannot test it, and cannot tell whether it is enforced on their platform at all.

The three supported platforms make that worse, because operating-system isolation means three different mechanisms and the row names none of them. What it does right is being explicit that the runtime stays local and inspectable, which at least puts the user in a position to find out.

1. Applying edits is where agents fail most legibly, so a project that names patching as a design concern is looking in the right place. 2. The word safe, however, admits at least three implementations with different guarantees: validation before application, atomic application with rollback, or a copy taken beforehand. The documentation distinguishes none of them.

2. The distinction matters because it determines the failure a user must plan for: a rejected edit, a half-applied one, or a recoverable one. No evaluation accompanies the claim and none is asserted, so the reader is left to establish empirically what the word meant.

Defaulting to the cheapest capable model is a real position and a fragile one. It is a claim about somebody else's price list, and the provider can invalidate it by changing a number. There is a company here and no paid product, so the runtime is a distribution play with nothing yet to distribute.

Moat: none, and price leadership is the position with the shortest half-life in this category. Likely path: a hosted or team tier appears, or the project becomes marketing for the company's other work. Position: use it, and do not confuse a default with a commitment.

Two channels is one more than I want. The desktop app is signed and notarised on all three platforms, which passes review and installs through the tooling we already use. The terminal build is a global npm package, which is sixty unpinned versions unless somebody owns it, and both will end up on the same machines.

Beyond that the usual gaps: no single sign-on, no directory sync, no audit export, and nothing that runs unattended, so it never becomes a step I can measure. Sixty seats cost nothing beyond provider keys. Approved with conditions: the desktop build only, distributed by us, and the npm route blocked by policy.

Ten providers in one runtime is the kind of optionality I pay attention to. Switching between them is configuration rather than migration, and none of them is privileged by anything except a default I can change. That is the correct relationship between a tool and the companies it talks to.

What is missing is my side of it. There is no MCP client and no MCP server, so the servers I run stay outside the runtime, and every provider on that list is somebody else's endpoint rather than mine. MIT keeps the fork available, which is the consolation. Grudging respect for the breadth, withheld on the ownership.