Cross-app coverage
Every Midcore-ecosystem app speaks the same Compute Router protocol. Decisions, holds, debits, refunds, and signed receipts all flow through the same /api/v1/billing/compute/* endpoints regardless of which app the user is in. One balance. One audit chain. One per-user preference dial.
The shared client library
The framework-agnostic @midcore/compute-client package ships three environment adapters that share one canonical decision engine:
| Adapter | Where it runs | Local dispatch backbone |
|---|---|---|
| browser | apps/web (Next.js), apps/desktop-shell (loads web cockpit) | Web Workers (module-type), WebGPU when present |
| node | apps/midcore-cli, apps/vscode-extension extension host | worker_threads with eval:false + resource caps |
| electron-renderer | apps/midcore-shell renderer (all package surfaces) | Proxies through window.midcore.compute* IPC to the host's worker pool |
Per-app coverage status
| App | Coverage | Notes |
|---|---|---|
| apps/midcore-shell (desktop) | full | Main-process ComputeRouter + LocalCompute plane + ASAR integrity + anti-tamper. Reference implementation. |
| apps/web (browser) | full | ComputeProvider mounted in app/layout. useComputeRouter() available in every client component. |
| apps/desktop-shell | inherited | Loads the web cockpit URL in a thin Electron wrapper; ComputeProvider applies as on plain web. |
| apps/midcore-cli | full | getCliComputeRouter() — Node adapter, worker_threads dispatch, MIDCORE_API_URL / AUTH_TOKEN env binding. |
| apps/vscode-extension | full | getExtensionComputeRouter(context) — Node adapter, Secrets API for the bearer, midcore.* settings for tenant + base URL. |
| apps/api | server-side | Hosts /api/v1/billing/compute/*. Not a client of itself. |
| apps/midcore-runner | server-side | Python service that complements apps/api. Server-side. |
| apps/desktop (legacy IDE) | deprecated | VS Code-fork being phased out. New work lands in midcore-shell + vscode-extension. |
| apps/zed-extension | remote ACP | Thin Rust agent registration; no client-side compute. Routes through the backend via ACP. |
| maestro-mobile-platform (submodule) | contract published | Implement the ComputeTransport + LocalDispatcher interfaces from @midcore/compute-client; same wire shape. |
Same balance, every app
Use the CLI to start a Monte Carlo run, switch to the web app to review the receipt, then open the desktop shell to bump your default-mode dial — the operations, debits, and receipts all live on the same tenant-scoped audit chain. One subscription, every surface.
Adding a new client (mobile, IDE, third-party)
Whatever environment you’re in, you only need to implement two interfaces from @midcore/compute-client:
- ComputeTransport — three methods (get / post / put) that hit
/api/v1/billing/compute/*with the auth bearer + tenant header attached. Any HTTP client works. - LocalDispatcher (optional) — one method,
dispatch(envelope), that runs a local runner by key. If your environment has no local execution substrate, omit it and everything routes to cloud.
Then instantiate new ComputeRouterClient({ transport, capability, dispatcher }) and you have the same five-tier decision logic, hold/charge, and audit chain integration as every first-party Midcore app.
What this guarantees
- No double-billing. Switching apps mid-task can’t produce duplicate charges — the hold ids are tenant-scoped and the finalize is idempotent.
- No app-shaped pricing. You don’t pay one price in the CLI and a different price for the same op in the web app. Pricing is per operation, not per app.
- Same audit trail. Every signed receipt records which app initiated the op (the actor field) so the audit chain captures provenance end-to-end.
- Same security posture. Sensitive-data operations are forced local everywhere. Cloud-only operations stay cloud everywhere. Per-op overrides apply uniformly.
Where to read next
Back to local vs cloud for the routing decision flow, or pricing for what each operation costs on the cloud path.