PearAI

PearAI's idea was honest: bundle good open tools instead of writing yet another editor. The trait that decides it today is freshness. You would be installing a VS Code fork that has fallen well behind upstream, which means a year of editor fixes and extension API changes is missing, wrapped around bundled extensions nobody is merging. On a real repo the wrapper adds nothing the underlying extensions do not already do on their own.

Pick Cline or Kilo Code inside stock VS Code and skip the middle layer; you get the same bring-your-own-key agent with an editor that still updates, and one fewer party to blame when it breaks.

Two dates and an error. The editor repository, pearai-app, last published a release in May 2025, and the documentation site returns a disabled-deployment error. That is sixteen months of upstream VS Code security fixes missing on your machine with no docs to explain the gap, and the failure is silent: nothing in the editor tells you it is stale.

An editor is a privileged process that opens untrusted files, and an unpatched one is a liability before the agent writes a line. What it does right: the third-party pieces live as separate repositories under the org, so a bug can be traced to its upstream.

PearAI is composition rather than construction. 1. A VS Code fork. 2. PearAI Chat, a fork of Continue. 3. PearAI Agent, a fork of Roo Code, itself descended from Cline. 4. A hosted router that picks a model per request. Context gathering, edit application and verification are all inherited, each only as current as the last merge from its upstream, which the repositories do not date.

No property of the system can be attributed to PearAI; any claim about its behavior is a claim about someone else's code at an unknown revision. The observation: the router is the only original component, and the one you pay for.

The business model is the problem. Pricing power is bounded by the cost of installing two extensions yourself, which is zero, so $15 a month for a router is a hard sell to the only audience that would find it, which is people who already know what the extensions are. Adoption signal: 706 GitHub stars, small for a VS Code fork with a launch behind it. Moat: none, and a dependency on upstreams that owe it nothing.

No acquirer needs a bundle of other people's code. Likely path: a quiet pivot, or a sunset nobody announces. Position: do not prepay the top-ups, non-expiring or not.

The demo is VS Code with extensions preinstalled and a model picker. Procurement: the hosted server is a per-seat subscription, $900 a month for sixty, with no SSO, no audit log and no retention policy on the page. The average engineer gains nothing over the extensions in the VS Code build we already manage, and loses the patch cadence, so the throughput case is negative before cost enters it.

There is no CI story and no support line. Onboarding would be a migration off it within a year, budgeted twice. Not yet, and there is nothing a pricing change could fix here.

Credit where due: the licenses are honest, MIT on the app and Apache-2.0 on the components, and bring-your-own-key and local models both work, so nothing forces me through the router. But I own less than if I skipped it: the upstream of the bundled agent shut down and archived its repository, so the bundle is a dead tree grafted onto a fork nobody prunes.

Forkability is technically total and practically pointless; I would be maintaining a VS Code fork to keep two extensions I could install in a minute. My move is the live upstream in a stock editor, same config, no wrapper.