Detailed Analysis
A Reddit post in r/ClaudeAI raises a pointed developer-experience question about Claude Code's tooling ecosystem: while Anthropic has invested heavily in standardizing the Model Context Protocol (MCP) for connecting Claude to external data sources and tools, there is comparatively little standardization around simpler, more fundamental API surfaces—things like querying token usage, listing available models, or retrieving session metadata. The poster is building a custom front-end for richer content rendering and looked to the Agent Client Protocol (ACP, sometimes referenced via tooling like "acpx") as a potential foundation, only to find that ACP doesn't define primitives like "usage" or "models." This gap forces developers building on top of Claude Code into ad hoc, reverse-engineered integrations rather than stable, documented interfaces.
The distinction being drawn here matters because MCP and ACP solve different problems than what the poster needs. MCP standardizes how Claude (or any LLM) connects to external tools, databases, and services—it's about extending the model's capabilities outward. ACP, by contrast, is oriented toward agent-to-agent or agent-to-client communication protocols for interoperability between coding agents and editors/IDEs. Neither was designed as a general-purpose management or introspection API for the CLI tool itself—things developers building companion apps, dashboards, or alternative front-ends would want: current model in use, remaining quota, session state, streaming output formatting, etc. This is a common pattern in fast-moving developer tools: the "exciting" protocol work (MCP for tool connectivity) gets standardized and heavily marketed because it drives ecosystem adoption and differentiates the product, while the "boring" plumbing APIs (usage metering, model enumeration, config introspection) lag behind because they're seen as internal implementation details rather than strategic surface area.
This tension reflects a broader growing pain across the AI coding-assistant space. As Claude Code, GitHub Copilot, Cursor, and similar tools have moved from single-vendor CLI experiences toward becoming platforms with plugin ecosystems, third-party developers increasingly want to build on top of them—wrapping them in custom UIs, integrating them into IDEs Anthropic doesn't officially support, or building usage-monitoring dashboards for teams managing API costs. Without stable, versioned APIs for these basic operations, developers are left scraping CLI output, parsing undocumented JSON responses, or maintaining brittle integrations that break with every Claude Code update. This is a familiar pattern from earlier platform maturation cycles (e.g., early Slack or Stripe APIs), where community pressure eventually pushed vendors to formalize what had been internal-only interfaces.
The request also signals something about Anthropic's product priorities at this stage: MCP was released and promoted specifically as an open standard to build ecosystem lock-in and third-party tool adoption, giving Anthropic outsized influence over how the industry connects LLMs to external systems. Usage and model-listing APIs don't carry the same strategic value for Anthropic, since they're more about servicing power users and integrators than expanding what Claude itself can do. Whether Anthropic responds to this kind of grassroots developer feedback with a formal API will likely depend on how loudly the Claude Code developer community continues to push, and whether competitors like Cursor or OpenAI's Codex CLI move first to offer more transparent, programmatic access to session and usage data—turning it into a competitive differentiator rather than an afterthought.
Read original article →