codeburn/docs/providers/README.md
iamtoruk d64b29f64d feat(cli): rehome the cline-cli provider into the workspace layout
Upstream `main` ships a provider this branch has no counterpart for: the
Cline CLI (npm `cline`, 3.x), whose sessions live in a layout unrelated to the
VS Code extension tree `cline.ts` reads. Files added on one side only produce
no merge conflict, so a `main` merge would happily create `src/providers/
cline-cli.ts` — a path npm workspaces does not build and no registry imports.
Green build, and a whole provider quietly does not exist.

Ported from #940 (@ozymandiashh), which carried it faithfully: identical dedup
keys, all 34 upstream test cases, and the clean phase-8 split — discovery and
file I/O host-side, pure record decode in @codeburn/core, registered next to
its neighbours and deliberately separate from the shared vscode-cline tier.

Two changes on top of that port:

  - `observations.ts` follows the post-#1074 conventions: the model is routed
    through `normalizeModelIdentifier` at the observation boundary like every
    other provider, and measured cost is carried the way the sibling decoders
    carry it rather than through a cast.

  - the estimated-cost path reports zero web-search requests. Upstream prices
    that path with a hardcoded 0; letting the decoded `fetch_web_content`
    count reach the pricing pass would bill $0.01 per fetch on top of tokens,
    a billing change nobody asked for. A metered call keeps the real count —
    its dollar figure comes from the CLI, so nothing prices off it.

DAILY_CACHE_VERSION takes 27 (MIN_SUPPORTED 27): every historical Cline CLI
session contributes usage no older rollup ever contained, and usage-aggregator
serves every day before today from that cache for ten years, so without the
bump an upgrading user would keep cline-cli-less history forever while today's
numbers silently included it.
2026-08-21 13:27:57 -07:00

4.7 KiB

Provider Docs

One file per provider integration. If you are fixing a bug or adding a feature scoped to a single provider, read the file for that provider first; it tells you which file to edit, where on disk the source data lives, and what edge cases the test suite already covers.

For the architectural picture, see ../architecture.md.

Provider Index

Eager (always loaded)

Provider Storage Source Test
Claude JSONL (no parser) src/providers/claude.ts none (covered indirectly)
Cline JSON src/providers/cline.ts tests/providers/cline.test.ts
Cline CLI JSON src/providers/cline-cli.ts tests/providers/cline-cli.test.ts
CodeWhale JSON src/providers/codewhale.ts tests/providers/codewhale.test.ts
Codex JSONL src/providers/codex.ts tests/providers/codex.test.ts
Copilot JSONL + SQLite (OTel) + Nitrite .db (JetBrains) src/providers/copilot.ts tests/providers/copilot.test.ts
Devin JSON + SQLite enrichment src/providers/devin.ts tests/providers/devin.test.ts
Droid JSONL src/providers/droid.ts tests/providers/droid.test.ts
Gemini JSON / JSONL src/providers/gemini.ts none
Hermes Agent SQLite src/providers/hermes.ts tests/providers/hermes.test.ts
IBM Bob JSON src/providers/ibm-bob.ts tests/providers/ibm-bob.test.ts
KiloCode JSON src/providers/kilo-code.ts tests/providers/kilo-code.test.ts
Kiro JSON src/providers/kiro.ts tests/providers/kiro.test.ts
Kimi JSONL src/providers/kimi.ts tests/providers/kimi.test.ts
Kimi Code JSONL src/providers/kimicode.ts tests/providers/kimicode.test.ts
LingTai TUI JSONL src/providers/lingtai-tui.ts tests/providers/lingtai-tui.test.ts
Mistral Vibe JSON / JSONL src/providers/mistral-vibe.ts tests/providers/mistral-vibe.test.ts
OpenClaw JSONL src/providers/openclaw.ts tests/providers/openclaw.test.ts
Pi JSONL src/providers/pi.ts tests/providers/pi.test.ts
OMP JSONL src/providers/pi.ts tests/providers/omp.test.ts
Qwen JSONL src/providers/qwen.ts none
Quick Desktop EMF JSONL + SQLite src/providers/quickdesk.ts tests/providers/quickdesk.test.ts
Roo Code JSON src/providers/roo-code.ts tests/providers/roo-code.test.ts
Zerostack JSON src/providers/zerostack.ts tests/providers/zerostack.test.ts
Grok Build JSON/JSONL src/providers/grok.ts tests/providers/grok.test.ts

Lazy (loaded on first call)

Provider Storage Source Test
Antigravity protobuf over RPC src/providers/antigravity.ts none
Crush SQLite (per-project) src/providers/crush.ts tests/providers/crush.test.ts
Forge SQLite src/providers/forge.ts tests/providers/forge.test.ts
Cursor SQLite src/providers/cursor.ts tests/providers/cursor.test.ts
Cursor Agent text / JSONL src/providers/cursor-agent.ts tests/providers/cursor-agent.test.ts
Goose SQLite src/providers/goose.ts none
OpenCode SQLite src/providers/opencode.ts tests/providers/opencode.test.ts
Warp SQLite src/providers/warp.ts tests/providers/warp.test.ts
Vercel AI Gateway REST API src/providers/vercel-gateway.ts tests/providers/vercel-gateway.test.ts
ZCode SQLite src/providers/zcode.ts tests/providers/zcode.test.ts

Shared

Helper Used by Source
vscode-cline-parser cline, ibm-bob, kilo-code, roo-code src/providers/vscode-cline-parser.ts

File Format

Each provider doc has the same structure:

  1. One-line summary of what the provider integrates.
  2. Where it reads from on disk (or over RPC).
  3. Storage format and validation rules.
  4. Caching (which cache layer, if any).
  5. Deduplication key so you understand cross-provider dedup.
  6. Quirks that have bitten us before.
  7. When fixing a bug here as a checklist.

If you add a new provider, copy claude.md as a template and fill in your provider's specifics. Update this index, and prefer adding a real test fixture under tests/providers/.