You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@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.
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-codeprovider that runs the agent on the machine's Claude subscription by spawning the headlessclaudeCLI, instead of calling a REST API.The smallest useful version is exactly the existing shape — it's a driver, nothing else changes:
claude -p --output-format stream-jsonand translates the CLI's output into the sameAiStreamEventstream every other driver emits, so the panel, history, tool rows and context meter work unchanged.ai-driver-isolation.test.tspasses untouched.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:
credentialLess/credentialLessHint/sentinelBaseUrlto the provider catalogue, soProvidersTabhandles "this provider brings its own auth" generically rather than branching on a provider id. Any future provider authenticating outside Instatic gets it free.crypto.subtleis undefined on non-secure origins, so the code-asset agent tools throw on any install reached over a LAN or Tailscale IP on plainhttp://. 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.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.Area
AI
Caveats I'd rather raise myself than have you find:
auth status --jsonand 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.