Skip to content

[Feature]: run the agent on a Claude subscription instead of metered API credits #589

Description

@cakelesscoder

Problem

The agent is excellent, but every turn costs metered API credits. Instatic is self-hosted and a lot of us running it are a single operator editing our own site — and many of that group already pay for a Claude subscription (Pro/Max). Today those people pay twice: once for the subscription they already have, and again per token to use the agent that ships with the CMS.

In practice that makes the agent something you ration rather than something you reach for. The cost isn't the API's fault — it's that there's no way to point the existing agent at a plan you're already paying for.

Proposed solution

A claude-code provider that runs the agent on the machine's Claude subscription by spawning the headless claude CLI, instead of calling a REST API.

The smallest useful version is exactly the existing shape — it's a driver, nothing else changes:

  • The driver spawns claude -p --output-format stream-json and translates the CLI's output into the same AiStreamEvent stream every other driver emits, so the panel, history, tool rows and context meter work unchanged.
  • The CLI reaches the CMS through Instatic's own MCP server, with an internally minted connector token granted exactly the chatting user's capabilities — so it can do precisely what that user could through the agent panel, never more, and browser-execution tools still route to the open workspace via the editor bridge.
  • It's the deliberate exception to the SDK ban and compliant by construction: it imports nothing and spawns a binary. ai-driver-isolation.test.ts passes untouched.
  • In the UI it's a credential-less provider: the connect form collects a display label and nothing else.

I've opened #577 with a working implementation (4 commits: server, UI, docker, docs) — but I'd rather have your read on whether you want this direction before you spend review time on the diff. Happy to close it if the answer is no.

Two things in there that might be of interest regardless of this feature:

  • The UI change isn't Claude-Code-specific. It adds credentialLess / credentialLessHint / sentinelBaseUrl to the provider catalogue, so ProvidersTab handles "this provider brings its own auth" generically rather than branching on a provider id. Any future provider authenticating outside Instatic gets it free.
  • fix(agent): hash code assets without Web Crypto so AI tools work over non-secure origins #576 is split out and independent of all of this: crypto.subtle is undefined on non-secure origins, so the code-asset agent tools throw on any install reached over a LAN or Tailscale IP on plain http://. That one's a plain bug fix.

Alternatives considered

  • @anthropic-ai/claude-agent-sdk — bills API credits, so it doesn't solve the problem at all, and it's banned repo-wide anyway.
  • The existing MCP connectors feature (docs/features/mcp-connectors.md) — already covers the inverse direction: point an external Claude Code at the CMS. That works well, but you drive it from a terminal rather than the agent panel, so you lose the panel's history, context meter and model picker. This proposal is the same capability pointed the other way round, and the two share the same MCP tool surface.
  • Do nothing — reasonable. The workaround is "pay for API credits", which is what everyone does now.

Area

AI


Caveats I'd rather raise myself than have you find:

  • Single-operator in spirit. Driving a subscription programmatically to back an application is a grey area of Anthropic's terms. It's intended for an operator editing their own site, not multi-tenant serving, and the docs in the PR say exactly that. If that alone makes it a no for a project you distribute, I completely understand — that's the main reason I'm asking first.
  • Auth is machine-wide. One Claude account for the server, not per Instatic user. Per-user scoping is handled by the MCP connector's capability grant, but the subscription itself is shared. The CLI exposes auth status --json and an OAuth flow that proxies cleanly through a browser, so an in-app connect/re-auth panel is very doable — I just didn't want to build it into a PR you might not want.
  • Subscription rate limits apply, and the driver surfaces them with their reset time rather than letting the turn look like it stalled.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions