claude-code - 💡(How to fix) Fix [Feature/Policy] Provide an interactive-auth path for ACP/editor integrations so human-paced Claude Code use isn't billed as autonomous Agent SDK usage

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

The billing boundary for Agent SDK usage is drawn by transport mechanism, not by usage pattern. A single human using Claude Code interactively through an editor's ACP chat buffer (CodeCompanion in Neovim -> Zed's claude-agent-acp -> Agent SDK) is billed identically to an unattended, autonomous, multi-agent orchestration harness, because both arrive via the Agent SDK rather than the first-party interactive client.

From the user's side, the only variable that changes between subsidized and raw-API-rate billing is editor buffer vs terminal - same models, same human pacing, same one-request-at-a-time interaction, same cache-friendly workflow. The stated rationale (first-party tooling maximizes prompt-cache hit rates) is an argument about cache efficiency and concurrency, not about which UI surface a human types into; an interactive ACP session has the same cache and concurrency profile as the interactive TUI. The policy currently can't distinguish them because it keys on auth/transport, which is enforceable but conflates interactive editor use with autonomous orchestration.

Proposed Solution

An interactive-auth mode for ACP integrations that draws on the interactive subscription pool, gated on interactive characteristics - single session, human-paced, no autonomous looping - rather than on transport mechanism.

Alternative Solutions

1. Recognize Zed's claude-agent-acp, or an Anthropic-published ACP adapter, as a first-party interactive surface for billing purposes.
2. Publish clear, documented criteria distinguishing "interactive editor use" from "autonomous orchestration," so integration authors can deliberately build to stay on the interactive side.

Any one of these, or the primary proposal, would resolve it.

Priority

Critical - Blocking my work

Feature Category

Developer tools/SDK

Use Case Example

I am an active, heavy, interactive Claude Code user who wants to keep using it as an interactive harness, and my only goal is a native editor chat buffer instead of a terminal window. I am explicitly not asking to run a third-party orchestration framework on subscription economics - I understand that's what the April 2026 policy was built to curb and I think that goal is reasonable. My request is narrower: keep human-paced, single-session, interactive editor usage on the interactive pool regardless of whether the transport is the TUI or ACP.

At my normal interactive workload, the Agent SDK monthly credit (even at the top tier) is exhausted in roughly one to two days, after which usage my subscription covers today would bill at full API rates - a difference on the order of several thousand dollars per month, driven entirely by editor surface choice, not by any change in how I work. The practical effect is that the policy pushes interactive users toward either a worse workflow (terminal-embedded Claude Code) purely to preserve economics, or churn - neither being the behavior the policy intended to encourage.

Additional Context

Filing as a feature/policy request, not a bug - it does not fit the bug template; submitting per the repo's feedback guidance. I searched existing issues for ACP / Agent SDK / editor-integration billing; happy to consolidate if there's a canonical thread.

To be explicit about scope: I am not asking for subsidized economics for unattended or multi-agent orchestration. The interactive-vs-autonomous distinction is the right line - my only point is that it should be drawn on usage pattern, not on whether the human is in a terminal or an editor.

Specific token and cost figures are available privately (omitted here as this is a public repo). Happy to provide anonymized usage data, a reproduction of the CodeCompanion -> ACP path, or to test any interactive-auth mechanism.