Skip to content
ActiveCLI

Pi provider

Why it is on the list

Section titled “Why it is on the list”

The largest competing JetBrains plugin, zhukunpenglinyutong/jetbrains-cc-gui (5,315 stars), attaches six CLI channels under ai-bridge/channels/ — claude, codex, grok, kimi, opencode, pi — with no common contract between them.

Pi is one of those six.

What is known

Section titled “What is known”

Two facts, from two different parts of the same survey.

  • It is one of the six channels the competing plugin drives, which is why it is planned here.
  • pi (87,262 stars) was also the highest-starred project the survey examined, and it was excluded from the comparison set for being a general-purpose toolkit rather than a CLI wrapper consumable as an SDK.

Those two facts sit together without contradicting each other. Being a general-purpose toolkit disqualified pi as a comparable project; it says nothing against pi being a CLI this library eventually drives. A provider is the identity of a CLI to point at, and what that CLI is for is the CLI’s business.

What is not known

Section titled “What is not known”

Everything about driving it. Not yet investigated:

  • The command name and how a conversation is identified.
  • Which flags make it a controllable two-way stream rather than a terminal UI.
  • Whether its output is NDJSON with a type discriminator, which would let EventParser work unchanged.
  • Its permission vocabulary, and whether the closed PermissionMode set can spell it.
  • Whether it has auth and mcp subcommands, and in what shape.
  • Whether a general-purpose toolkit even presents the session-shaped surface an adapter needs — which is the first thing to check, and has not been.

What attaching it would contribute

Section titled “What attaching it would contribute”

A CLI that is not primarily a coding agent is the most severe test of whether the contract generalises. SpawnOptions speaks in the library’s vocabulary rather than any CLI’s, and Command speaks in intent — a message, a model, a permission mode. If a differently-shaped CLI can be driven through those words unchanged, that is strong evidence the abstraction is real.

If it cannot, that is the more valuable finding, and the order of work is what surfaces it:

  1. Port the adapter accurately, matching the CLI’s real behaviour.
  2. Note every place the existing contract had to be worked around.
  3. Extract the common shape from the implementations that exist.
  4. Only then widen AbstractAdapter.

Where to go next

Section titled “Where to go next”