Claude Code can keep its interface
Developers should not need a new coding interface simply because a platform team needs governance, cost visibility, or model routing. Claude Code already owns the developer interaction, repository context, and local coding loop. Punk can sit beneath that experience instead of replacing it.
The integration has two independent modes:
- Model backend: Claude Code sends its Anthropic-compatible model traffic through Punk.
- MCP runtime tools: Claude can call Punk workflows, semantic web fetches, approvals, savings, and run explanations as tools.
Teams can use either mode alone or combine them. Keeping the modes separate makes the deployment boundary easier to understand: the gateway governs model requests, while MCP intentionally exposes selected Punk capabilities to the agent.
Model-backend mode creates an inspectable route
The punk launch claude command starts Claude Code with a managed Anthropic base URL pointing to Punk. Model requests reach Punk’s /v1/messages endpoint in the shape Claude expects.
Punk then applies the same operating controls used for other agent traffic: tenant and application identity, policy, cost accounting, provider selection, fallback, trace evidence, and route explanations. Compatible repeated work may become eligible for a proven cache or artifact route, but unsupported or uncertain work stays on a live provider path.
The launcher clears inherited Anthropic credentials from the child environment so a direct provider key cannot accidentally bypass the selected gateway. The Punk API key is supplied as the gateway credential. This is particularly important on shared engineering teams, where “we configured a gateway” is not useful if an existing shell variable silently routes around it.
Anthropic’s own LLM gateway guidance describes centralized authentication, usage tracking, cost controls, audit logging, and model routing as common gateway goals. Punk adds its evidence-gated learning and route explanation to that operating model.
MCP adds runtime capabilities, not another model path
Registering Punk as an MCP server gives Claude a typed way to use Punk’s runtime functions. Those tools can include workflow discovery and execution, compact semantic web fetches, savings summaries, approval actions, and run explanations.
MCP does not replace model-backend routing. If a team configures only MCP, Claude can call the exposed Punk tools while its model traffic follows whatever provider path Claude Code already uses. If a team configures only the launcher, model traffic flows through Punk but Claude does not automatically receive the additional runtime tools.
Using both modes produces a useful composition:
- Claude remains the developer-facing agent.
- Punk governs each model step.
- Claude can ask Punk for operational evidence or invoke an approved workflow.
- Consequential actions still encounter Punk policy and approval controls.
This distinction also prevents a common architecture mistake: treating an MCP server as proof that all model traffic passes through the same governance boundary.
Anthropic wire compatibility matters
Claude Code depends on more than plain assistant text. Its traffic can include system instructions, structured content, tool declarations, tool-use blocks, tool results, stop controls, token-count preflights, and streaming events.
Punk preserves the Anthropic-compatible wire rather than requiring Claude Code to speak an OpenAI-shaped protocol. The runtime supports the Messages endpoint and the token-count endpoint Claude clients use before a request. Buffered and streamed responses keep Anthropic content blocks and tool events in their expected form.
That fidelity supports safer routing. If a proposed route cannot preserve the requested tool or response semantics, Punk can reject it as ineligible and retain the live fallback. A lower-cost answer is not an optimization if it breaks the client’s next turn.
The same reasoning shaped Punk’s native Responses runtime for Codex and other OpenAI-compatible agents: the gateway should govern the protocol the harness actually uses, not flatten every client into a lowest-common-denominator format.
What operators can inspect
Every routed Claude model request can become a Punk run. Operators can review:
- the model and provider selected;
- the app, agent, and subject identity;
- policy and DLP results;
- live, cached, artifact, Chorus, or fallback routing;
- token, cost, and latency evidence;
- tool plans and side-effect records when applicable;
- the final route explanation and linked receipt evidence.
When Claude uses Punk through MCP, the tool invocation creates its own runtime evidence. That makes it possible to distinguish “Claude asked the model for a plan” from “Claude invoked a Punk workflow” and from “an approved external action executed.”
Those are different events with different authority, even when they appear in one developer conversation.
Account connectors require an explicit choice
Claude Code can also use account-linked capabilities supplied directly by Claude’s hosted environment. Gateway authentication and those account connectors are not the same path.
When Punk launches Claude Code in model-backend mode, Claude may report that account connectors are unavailable because the child process is intentionally using gateway authentication. Punk surfaces that handoff instead of hiding it. Launch Claude Code directly when the immediate task requires those account connectors; launch it through Punk when the governed model route is the requirement.
This is a product boundary, not a troubleshooting trick. Platform teams should decide which route a task needs rather than assuming every identity and connector can be combined safely.
A practical Claude Code rollout
Begin with --dry-run to inspect the resolved command, gateway, model, and redacted environment. Then run one read-only Claude task and confirm the corresponding Punk run carries the expected identity and route.
Add the MCP server separately and run its self-check before exposing tools to Claude. Start with read-only evidence tools, confirm their audit records, and introduce workflows or approvals only after the team understands the action boundary.
Finally, test the bypass and failure cases: inherited Anthropic credentials, an unavailable gateway, an invalid Punk key, and an MCP server that is not running. A governed Claude Code deployment should make each failure visible and recoverable.
The result is not a different coding agent. It is Claude Code with a clearer operating layer: familiar work for developers, and inspectable model and tool behavior for the teams responsible for production risk.
Questions readers ask
Does Punk replace Claude Code?
No. Claude Code remains the interface and coding-agent harness. Punk operates underneath it as an Anthropic-compatible model gateway and, optionally, as an MCP server exposing Punk runtime tools.
Can Claude Code use Punk without the MCP server?
Yes. Model-backend routing and MCP runtime tools are independent. Use only the launcher when you want Claude model traffic governed by Punk, and add MCP when Claude also needs direct Punk workflows or evidence tools.
How does the launcher prevent accidental direct Anthropic traffic?
The launcher sets the managed Anthropic base URL and authentication environment for the child process while clearing inherited Anthropic credentials that could bypass the selected Punk gateway.