Easy LLM CLI

The deciding trait is familiarity. This is the terminal workflow you already know, with the same commands and the same feel, and the only thing that changed is which model answers you. There is no new mental model to learn, which matters more than it sounds.

What you inherit alongside the workflow is the workflow's assumptions, which were written with one model in mind and now have to hold for any of them. Pick it if you have a provider you would rather pay and a habit you would rather keep. Stay on the original if the default model was fine and you want the name behind it.

The risk is drift. A fork inherits every defect the original carried on the day it was cut and none of the repairs afterwards unless somebody merges them, and no merge cadence, no upstream version marker and no divergence policy appear anywhere in the documentation. You cannot tell which release you are actually running.

The consequence is not dramatic, it is slow. Features land upstream, users ask for them here, and the answer depends on when the next merge happens. What it does right is keeping the change small: it alters where the model comes from and leaves everything else alone, which is the only kind of fork that survives.

1. A compatibility matrix is a useful artefact and an unusual one to publish, since most forks assert provider support and leave the reader to find the exceptions. 2. What it records is nevertheless binary: the harness connected and the tool calls parsed. It says nothing about edit quality, task completion, or the failure rate against a repository anyone works in.

2. That distinction matters because model substitution is the entire proposition, and substitution is precisely where quality diverges. A model that answers the protocol correctly and edits files badly passes this matrix cleanly. No evaluation of the second property exists, and the design makes one straightforward to run.

The structural problem is that the value here is a feature, not a product. Somebody upstream can add a configurable endpoint in an afternoon and the reason to run this evaporates the same day. That is not a criticism of the work. It is a description of where the leverage sits, and the leverage is not sitting here.

Moat: none. Pricing power: none, and no attempt at either, which is at least honest. Likely path is not acquisition but obsolescence by upstream feature, which is the quiet way these end. Position: use it freely, expect nothing, and keep anything you could not rewrite from depending on it.

The cost line is trivial and the control line is the whole problem. Nothing per seat, inference on accounts finance already reconciles, and then sixty developers each pointing their own copy at whichever backend they liked, on their own machine, with no central policy and no way for me to see the result afterwards.

That is a data-residency question I cannot answer, which means legal cannot answer it either. There is no identity integration, no usage record, and nothing that executes unattended, so it never becomes a measurable part of delivery. Not yet: I would need managed configuration and an allowlist of endpoints first.

This is the smallest possible version of the thing I keep asking for. No provider abstraction to learn, no plugin to write, no configuration format carrying its own opinions. Set a base URL, a key and a model name, and the agent is talking to a machine in my house.

MCP servers attach on top, and there is an embeddable class if I want the agent inside my own Node process with specific tools removed from it. The licence is permissive, so forking the fork stays available to me when the maintainer loses interest. Grudging respect for a project whose entire contribution is deleting a hard-coded provider.