OAuth, Subscriptions, and the Simplest Cloud Path

TL;DR

Two attempts at a cloud path for Hermes, from two subscriptions I already pay for: Claude via OAuth, which failed (401 invalid x-api-key) despite an active Claude Code subscription, and ChatGPT/Codex via subscription, which worked on the first try. This isn't a provider comparison, just the finding of what wired up simply and what didn't wire up at all.

---

Table of contents

• Why I needed a simple cloud path
• Claude via OAuth in Hermes: the good idea that wasn't
• ChatGPT / Codex: it worked on the first try
• What I'm taking away from this

---

Why I needed a simple cloud path

Hermes' background mode absorbs part of the local CPU's slowness problem, but not all of it: some tasks stay interactive by nature, and waiting several minutes for a reply to a routine question isn't sustainable day to day. I wanted a cloud path for those cases, but with one specific constraint: I already pay for a Claude Code subscription and an OpenAI subscription, and I didn't want to add a third, separate, usage-based bill just to wire a provider into Hermes.

Two obvious options, then: route Hermes through my Claude Code subscription, or through my ChatGPT/Codex subscription. In both cases the goal was the same: reuse a subscription I'd already paid for rather than open a metered API key. If either path refused to work by reusing the subscription, the alternative left over is exactly the one I was trying to avoid: paying for API access separately.

Claude via OAuth in Hermes: the good idea that wasn't

On paper it looked straightforward: Anthropic provider, OAuth authentication via Claude Code, generating a token with claude setup-token. ANTHROPIC_TOKEN and ANTHROPIC_API_KEY present in the environment, the old API key cleaned up to avoid a conflict. Result, despite all that: 401 invalid x-api-key, every single time.

I didn't dig further into Hermes' implementation to confirm the exact cause, but a plausible, unverified hypothesis: the token generated by claude setup-token is probably meant for the official tool's own use, not to be sent as-is as a generic API key by a third-party client. The lesson I'm taking away doesn't depend on that hypothesis, though: being able to use Claude Code with your subscription doesn't automatically mean a third-party orchestrator can reuse that same subscription as a backend. In practical terms, that meant the only alternative for routing Claude through Hermes would have been paying for separate Anthropic API access, exactly the extra expense I was trying to avoid by starting from the subscription rather than the API.

ChatGPT / Codex: it worked on the first try

Second attempt, Hermes provider configured as OpenAI → ChatGPT/Codex subscription. No complication comparable to the Claude failure: gpt-5.6-sol worked correctly from the first request, with good .NET/F# monitoring on the questions tested, and no extra billing to keep an eye on.

That's precisely the distinction that matters for this cloud path: not "which model is better," but which of the two subscriptions I was already paying for actually managed to replace a separate API key at no additional cost.

What I'm taking away from this

I'm not drawing a provider ranking from this: two attempts, one failure and one success, isn't a comprehensive survey, and the Claude failure might come down to a configuration detail I didn't identify rather than a fundamental limit. What I'm taking away is narrower: of the two subscriptions I was already paying for, only one could serve as a backend for Hermes with no additional billing, and that's the one I kept, not out of principle but because it's the one that worked on the first try, without a detour through separate billing. The rest of the series builds on this default choice.