Hermes Agent adds an experimental Claude subscription bridge through the official CLI

Hermes Agent now has a new way to use a Claude subscription without replacing Hermes’ agent loop: an experimental model-provider plugin that launches the official Claude Code CLI and translates its native stream into Hermes’ provider interface.

The plugin, called Claude Subscription DirectSDK (Experimental), was announced by Hermes creator Teknium on September 21. The practical pitch is straightforward: authenticate Claude through Claude Code, select the new Hermes provider, and keep using Hermes’ tools, approvals, history and compaction around the model.

That description is more precise than “Hermes now has the Claude Agent SDK.” The plugin does not require Anthropic’s Python Agent SDK package. It drives the unmodified claude executable as a request-scoped client and speaks the CLI’s native stream-json protocol.

The provider is a bridge, not a second agent loop

The important design decision is where the boundary sits. Hermes remains responsible for the work around a model call: its tools, approval flow, persistence, compaction, steering and subagent lifecycle. The plugin supplies a model provider that starts Claude Code for an individual request, sends the reconstructed conversation, and turns the native response back into the interface Hermes already understands.

That split came through the Hermes core work in PR #117451, which added generic support for external-process model-provider plugins. The Claude-specific provider was moved into its own standalone repository, rather than being bundled into Hermes itself.

The separation has a useful consequence for users: selecting this provider does not silently replace Hermes’ normal controls with Claude Code’s native agent behavior. The plugin disables native tools, skills and ordinary MCP execution for the spawned process. Hermes advertises its own tool inventory through an inert MCP layer, then executes the tools itself after Claude requests them.

The implementation also puts a local admission boundary in front of the upstream request. The plugin documentation says native Claude Code can attempt recovery generations even when a caller asks for one turn and disables HTTP retries. The relay forwards only the first Messages request for that Hermes call. A completed first response, including usage and the native stop reason, is returned to Hermes; incomplete streams and upstream HTTP failures remain errors.

This is a small but consequential detail. Without an admission boundary, a CLI wrapper could accidentally allow the native client to generate again outside Hermes’ own accounting, approval and retry decisions. The plugin’s design tries to keep that policy with the host agent.

What users install

The requirements are deliberately ordinary:

• Hermes Agent 0.21.4 or newer, or a Hermes checkout containing the merged external-process provider support.
• Python 3.10 or newer.
• The official Claude Code CLI installed and logged in.

The documented setup is:

hermes plugins install claude-subscription-directsdk
claude auth login
hermes model

The plugin can also be installed directly from GitHub, and per-profile installs live under the profile’s Hermes plugin directory. The provider is registered as a kind: model-provider plugin, so it does not need a separate plugins.enabled entry.

The provider checks for the claude executable at several points. If it is missing, setup stops with an installation hint instead of writing an incomplete model configuration. The same check applies when the provider is selected from the model picker and when a request is made. The executable can be placed outside PATH with CLAUDE_SUBSCRIPTION_DIRECTSDK_COMMAND.

Authentication stays with Claude Code. The plugin does not create a parallel credential store, copy Claude credential files, or send a Hermes API key as a fallback. It also rejects conflicting inherited API-key, custom-endpoint and cloud-backend settings on the normal subscription path. That is a sensible boundary for a plugin handling a consumer login: Claude owns the login, while Hermes owns the model-provider process.

A subscription is still metered like a subscription

The word “subscription” needs careful handling here. This plugin does not turn Claude Pro or Max into an unlimited, free API endpoint. It uses the account’s native Claude Code authentication and entitlement, and its documentation warns that extra-usage settings still belong to the account. A list-price number reported by the native service is an estimate, not proof that a separate API charge was made.

Anthropic’s own Claude Code authentication documentation confirms that Pro and Max users can log in to Claude Code with their Claude account. But Anthropic’s current help-center article on the Agent SDK also matters: its June 15 update says a planned change to separate Agent SDK credits was paused. For now, the article says, Claude Agent SDK usage, claude -p, and third-party app usage still draw from subscription usage limits. The old monthly-credit description remains on the page as preserved reference, not as a change currently taking effect.

In other words, Hermes users should expect account-level limits, model entitlements and usage-credit behavior to apply. The plugin’s pinned catalog lists routes such as Sonnet 5 with a 1-million-token context, Haiku 4.5 at 200,000 tokens, Opus 5, Opus 4.8 and Fable 5.1. The live Claude account picker can add plan-specific notes, and some models may draw from usage credits or be unavailable without the right entitlement. A model appearing in the fallback catalog is not a promise that every Pro or Max account can use it.

The same caution applies to the project’s cost comparisons. The README reports a September 9 Pro-plan measurement in which the provider drew usage at the same rate as claude -p and the Agent SDK, while interactive Claude Code was metered at a lower rate in that test. That is maintainer-reported qualification data, not an independent billing study or a guarantee for every model, plan or future Claude Code release.

The qualification results are promising, with a narrow claim

The plugin’s documentation describes it as “live-qualified,” not production-ready or full-parity. The project reports a real subscription-backed Hermes task that made seven Hermes calls with seven upstream requests, executed twelve Hermes tools and preserved twelve durable tool results. It also reports tests for streaming tool rounds, restart and resume, host-side denial, steering, cancellation and a CLI subagent completion.

Those numbers show that the authors tested more than a happy-path text response. They do not prove that every history transformation, native Claude Code version, platform or adversarial steering case is covered. The README explicitly lists broader history transformations, cross-model signed replay, native-version and platform breadth, and adversarial steering reliability as remaining qualification work.

Version drift is another practical concern. The project qualified a specific Claude Code release, and it describes replay acknowledgments and extra-body behavior as version-sensitive interfaces rather than a general public SDK guarantee. A future Claude Code update could change the native wire behavior that this adapter depends on. That is normal for an external-process integration, but it is why the “experimental” label is doing real work.

The policy boundary is not optional

Anthropic’s Claude Code legal and compliance documentation draws a line between ordinary use of Claude Code with a subscription and building a product or service around Claude credentials. It says Claude Code may be run in products or services under the applicable commercial terms, with the unmodified binary and each end user authenticating with their own Anthropic credential. The same page says developers building products or services that interact with Claude, including Agent SDK applications, should use API-key authentication through Claude Console or a supported cloud provider, and that third parties may not offer Claude.ai login inside their own applications or route requests through consumer plan credentials on users’ behalf.

The plugin’s local shape matters: it uses the unmodified official executable, leaves login to Claude Code, and is presented as a user-installed Hermes provider. But that implementation detail is not the same thing as an Anthropic endorsement or a blanket answer for hosted, multi-user deployments. Anyone embedding Hermes in a service, reselling access, or brokering accounts should treat Anthropic’s terms and commercial requirements as a separate review before deploying this pattern.

Who should use it?

For a developer already running Hermes locally, with Claude Code installed and an eligible Claude plan, the plugin offers a coherent way to bring Claude into Hermes without giving up Hermes’ distinctive controls. The appeal is strongest for people who want one persistent agent workspace, durable tool results, compacted history and messaging integrations while retaining Claude’s model family as a selectable backend.

It is less suitable as a drop-in replacement for a metered Claude API integration, a guarantee of unlimited subscription throughput, or a production multi-tenant gateway. The provider is an experimental adapter around a moving CLI surface, and both Anthropic’s usage rules and Claude’s account entitlements remain in force.

That is still a meaningful release. Hermes is treating provider integration as a plugin boundary instead of hard-coding every vendor transport into the agent core. In this case, the result is not “Claude inside Hermes” by way of a hidden API shortcut. It is a deliberately narrow bridge: official CLI on one side, Hermes’ agent machinery on the other, with the awkward billing and policy questions left visible rather than abstracted away.