Tabby

The trait that decides it is the answer engine over your indexed repositories, issues and merge requests. Asking why a module exists and getting an answer drawn from your own history, rather than from the internet's average opinion, is the thing that makes people keep it, and it is what separates this from every offline autocomplete.

In exchange you are running a service, and someone has to care when it stops. Pick it when the code cannot leave and the team is big enough to justify an owner. Pick Llama Coder if you want completions with nothing to operate.

The mismatch is expectation, not engineering. The capability list shows no multi-file editing, no command execution and no repository operations. This is an assistant in the original sense: it suggests and it answers, and a human does everything else. The product page is honest about that; the surrounding market is not, and buyers arriving from agent demonstrations will feel a gap.

Judge it against a completion product, not against an agent. What it does right: it needs no database and no external service, so the deployment is one process rather than a stack somebody has to diagram.

1. The indexed corpus deliberately extends past source into issues and merge requests, which is where intent is recorded; code states what happens and the discussion states why. 2. Retrieval and completion are served from the same deployment, so the context assembled for a question and for a suggestion come from one index rather than two subsystems that can disagree.

2. Verification is the developer, as with any suggestion-based tool. No benchmark is published, and index quality, which is the variable that actually determines usefulness here, is not measured anywhere.

Thirty-four thousand stars and not a single published figure anywhere is a deliberate omission, not an oversight. It means the commercial motion is bespoke, each deal negotiated against whatever a bank or a defence contractor will pay for keeping code inside the building. That produces good revenue per customer and a sales cycle that does not compound.

Moat: regulated buyers with no alternative, which is defensible and small. Likely acquirer: a self-hosted developer platform that already sells into those accounts and wants the assistant in its bundle. Position: sound niche business, capped ceiling, probably acquired rather than scaled.

Zero acquisition cost, and then the honest accounting. Serving sixty engineers means graphics hardware sized for concurrent load, capacity planning nobody on my team has done before, and a person who gets paged when completions stop at ten on a Monday. That is a headcount conversation dressed as a savings opportunity.

Against that, the compliance answer is complete: nothing leaves our network, which closes questions that have blocked three previous evaluations. It sits outside our pipeline, and onboarding is installing an editor extension. Approved with conditions: a named owner, a capacity plan, and hardware budgeted before rollout.

Mostly Apache-2.0, with an ee/ directory living under separate terms inside the same repository. I can read that code and I cannot freely use it, which is open core wearing an open-source badge, and the honest thing is that they left it in the tree where I can see the boundary rather than shipping a hollow build.

What buys back my goodwill is the OpenAPI surface: everything is reachable over a documented interface, so I can script it, monitor it and wire it into tooling nobody anticipated. Serving my own weights on my own machine, with a fork that survives the vendor for everything outside ee/. Good enough.