Better-Clawd

The deciding trait is provider freedom inside a familiar shell. Everything you know about the original terminal agent still applies, and the model behind it can now be an OpenAI key, an imported Codex login or a router account. If the interface was the part you liked and the billing was the part you did not, this is a narrow, precise answer.

It is also a community fork of somebody else's product, which is a thin place to stand for a year. Pick it for an experiment. Pick the upstream tool if you want the version that gets fixed first.

The structural problem is drift. This tracks a product it does not control, published by a company that has no reason to keep the fork's surface stable, and the rebranding reaches into the CLI, the config paths, the installers and the app identity. Every one of those is a place a future upstream release lands badly. Nothing documented says how long the gap between releases will be.

What it does right is state the relationship plainly. The README says it is unaffiliated and unendorsed, which is the correct disclosure and not every fork bothers.

1. Supporting one router through two different API surfaces means tool-call encoding, streaming semantics and error handling each have two implementations, and the agent loop above them assumes one. 2. That is the standard place where a compatibility layer silently changes behaviour: not in the happy path, but in how a malformed tool call or a truncated stream is recovered.

2. No evaluation is published, and for a fork the interesting measurement would be a differential one against the original rather than an absolute score. Nothing of the kind accompanies the project.

This is the diligence question that ends deals. A permissive declaration in package metadata does not grant rights the publisher may not hold, and a derivative of a proprietary product needs the original owner's terms to permit exactly what was done here. No counsel signs that off from a README, and no acquirer inherits it knowingly.

Moat: none, and the distribution advantage belongs entirely to the upstream vendor. Likely path: a takedown, a rename, or quiet abandonment. Position: do not put this anywhere near a commercial codebase.

Procurement does not get a counterparty. There is no support contract, no security contact and no indemnity, which means an incident here is entirely my team's problem and an unaffiliated project is the answer I would have to give in the postmortem. The disclaimer in the README is honest and it is also disqualifying.

Environment variables are the documented path for non-interactive use, so it would slot into a pipeline technically. That is the only box it ticks. Not yet, and not from me.

Removing the reporting code entirely is a different promise from an opt-out toggle, and it is the one I actually believe, because there is nothing left to re-enable in a later release. Upstream service dependencies are cut down too, so the tool phones fewer places it has no business phoning.

Credentials are handled inside the session with two commands, and I can point it at whichever account is cheapest that week without editing a config by hand. This is the fork I would have written, which is a compliment and a warning in the same sentence.