If you're building anything on top of AI coding agents — a dashboard, a mobile client, an orchestrator — you immediately hit a problem: how do you access the user's subscription plan?
Claude Max costs $200/month for heavy coding use. The equivalent API usage can run $1,000+/month. ChatGPT Pro is similar. These subscriptions are dramatically cheaper, but they're gated behind official CLI tools. There's no documented "subscription API" you can call with a bearer token.
Every project in this space has landed on a different approach. After reading the source code of five major projects, here's what we found.
The spectrum
From least to most structured:
Raw Terminal <----------------------------------------> Full API Wrapper
emdash Yep Anywhere OpenCode pi-mono Vercel AI
(PTY) (SDK process) (legit OAuth) (reverse-eng) (API keys) Approach 1: Raw terminal passthrough
Project: emdash (YC W26)
Emdash spawns CLI tools (claude, codex, gemini, etc.) in a pseudo-terminal via node-pty and streams raw terminal bytes to an xterm.js pane. The user sees exactly what they'd see in a terminal.
Subscription access is free — inherited from whatever CLI is installed. Adding a new agent is one registry entry:
{ id: 'gemini', cli: 'gemini', autoApproveFlag: '--yolo', resumeFlag: '--resume' } This is how they support 21 agents with minimal code. The tradeoff: no structured data. You can't parse tool calls, extract diffs, build a mobile UI, or do anything that requires understanding what the agent is actually doing. It's a fancy terminal multiplexer with git worktree management bolted on.
Works great for desktop power users. Unusable on a phone.
Approach 2: Official SDK wrapper
Project: Yep Anywhere (disclosure: this is our project)
Uses the official provider SDKs to spawn and manage agent processes:
- Claude:
@anthropic-ai/claude-codeSDK — structured events (messages, tool calls, diffs, permission requests, thinking blocks) - Codex:
@openai/codex-sdk— structured events (messages, shell commands, file patches, sandbox modes) - Gemini:
gemini -o stream-jsonCLI — structured JSON stream
Each SDK/CLI handles its own authentication. The wrapper inherits whatever plan the user is authenticated with. Provider-specific adapters normalize events into a unified format for the UI.
The tradeoff: each provider needs a custom adapter (~500+ lines) for event normalization. Claude SDK, Codex SDK, and Gemini CLI each have completely different event models. Adding a new provider is expensive. But subscription access is as stable as the official SDKs themselves — no reverse engineering, no spoofing.
Approach 3: Legitimate OAuth
Project: OpenCode
OpenCode uses Vercel AI SDK adapters internally for most providers (API-key-based), but implements legitimate OAuth for select providers:
- ChatGPT/Codex: OAuth via
auth.openai.comwith PKCE, accessing ChatGPT Plus/Pro subscription models - GitHub Copilot: Standard device code flow via GitHub's public OAuth app
No spoofing — honest opencode/{version} user-agent. These are public OAuth clients the providers expose intentionally.
Notable history: OpenCode previously had a mechanism for users to obtain Claude subscription tokens through the app, but had to remove it after TOS compliance pressure from Anthropic. For Claude, API keys are now required.
The tradeoff: only works for providers that expose public OAuth clients. Anthropic doesn't. So Claude subscription access isn't available through this path.
Approach 4: Reverse-engineered OAuth
Project: pi-mono
Pi-mono implements the same OAuth flows the official CLIs use, but independently. It makes direct HTTP API calls with OAuth tokens obtained from subscription authentication across multiple providers:
- Anthropic (Claude Pro/Max): Opens
claude.ai/oauth/authorizewith PKCE - OpenAI (ChatGPT Plus/Pro): OAuth callback server on localhost
- GitHub Copilot: Device code flow
- Google Gemini CLI: Cloud Code Assist OAuth
The critical detail: it spoofs the official CLI identity.
headers["user-agent"] = "claude-cli/2.1.2 (external, cli)";
headers["anthropic-beta"] = "claude-code-20250219,oauth-2025-04-20,..."; This gives you direct API streaming (lower latency than spawning a CLI process) with full structured data across multiple providers. Technically elegant.
But the consequences are real. Google has already permanently banned hundreds of subscribers who used OpenClaw projects that reverse-engineered Gemini CLI OAuth tokens. OpenCode had to remove its Claude subscription token mechanism. Providers are actively enforcing these boundaries.
Why providers enforce this
The official CLIs aren't just auth wrappers. They serve as control points for:
- Telemetry: Usage patterns, error rates, feature adoption
- Caching: Prompt caching is how providers make $20/mo subscriptions viable. Third-party clients break cache hit rates, potentially increasing serving costs 5-10x per request
- Sharing detection: One subscription shouldn't power a multi-user service
- Distillation prevention: Systematic API access enables model extraction
Bypassing the CLI to hit the API directly with spoofed credentials undermines all of these. Providers have strong economic incentives to detect and block it.
Approach 5: API keys only
Project: Vercel AI SDK
Client-side TypeScript SDK that makes direct HTTP calls to provider APIs using API keys. 55+ provider packages implementing a unified LanguageModelV3 interface. Battle-tested, framework-agnostic, the most mature option in this space.
No subscription-plan access at all. No CLI integration. No self-hosted server. Users must have and pay for API keys.
Solves a different problem. Included here because it's the most common starting point, and understanding why it doesn't solve subscription access clarifies what the other approaches are doing.
Summary
| Dimension | emdash | Yep Anywhere | OpenCode | pi-mono | Vercel AI |
|---|---|---|---|---|---|
| Subscription access | Yes (passive) | Yes (SDK) | Partial (Codex, Copilot) | Yes (reverse-eng) | No |
| Structured output | None | Full | Full | Full | Full |
| TOS risk | None | None | None (removed Claude OAuth) | High (bans observed) | None |
| Provider breadth | 21 CLIs | 3-4 SDKs | 10+ | 8+ | 55+ |
| Add new provider | ~1 KB | ~500+ lines | Via AI SDK | ~200 lines | ~500 lines |
| Self-hosted | Yes | Yes | Yes | Yes | No |
| Maintenance surface | CLI flags | SDK upgrades | SDK + OAuth clients | Undocumented OAuth endpoints, client IDs, headers | SDK upgrades |
The gap
No project provides a stable, documented, multi-provider API for subscription-plan access. The four strategies are:
- Spawn the official CLI (emdash, Yep Anywhere) — stable but per-provider, limited to what each CLI exposes
- Legitimate OAuth where available (OpenCode for Codex/Copilot) — stable but only works for providers that expose public OAuth clients
- Reverse-engineer OAuth (pi-mono) — broad but fragile, with real-world account bans
- API keys only (Vercel AI, OpenCode for other providers) — stable but expensive
What the ecosystem arguably needs is for providers to ship an official "subscription API" — an endpoint where you authenticate with your subscription credentials and make API calls against your plan limits, not a metered API key.
But providers have reasons to resist. The official CLIs are control points for telemetry, caching, sharing detection, and distillation prevention. Exposing a raw subscription API would bypass all of these. This tension — users wanting open access vs. providers wanting to own the harness — is why these workarounds exist and may persist.
Open questions
- Will providers formalize subscription APIs? Anthropic and OpenAI both ship SDKs that expose structured output from their CLIs, which is a step in this direction. But neither offers a documented HTTP endpoint for "make an API call against my Pro plan."
- Can the SDK wrapper approach become a shared layer? Rather than every project writing its own Claude SDK adapter, could there be an open-source normalization layer that multiple UIs build on top of?
- Will terminal passthrough get smarter? Projects like emdash could add lightweight output parsing without going full SDK integration. This middle ground is largely unexplored.
Projects referenced
- emdash — YC W26, desktop terminal multiplexer for 21 CLI agents
- Yep Anywhere — mobile-first structured supervisor using official SDKs
- OpenCode — open-source agentic coding CLI/server with legitimate Codex/Copilot OAuth
- pi-mono — multi-provider coding agent with independent OAuth implementation
- Vercel AI SDK — provider-agnostic TypeScript SDK (API keys only)
This post is based on source-code analysis of all five projects, not just documentation. The research doc with more architectural detail is in our GitHub repo.