Claude Agent SDK billed on a dedicated monthly credit

[laughinglion]

Good day,

I love Ouroboros. I think the dedicated monthly credit is going to be a real pain point. Since Ouroboros uses the Claude Agent SDK, is there any way to mitigate the effect of this?

https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan

[shaun0927]

Good catch — this is a valid concern for Claude-backed Ouroboros usage.

Ouroboros is not intended to be Claude-Agent-SDK-only. The current backend/runtime layer supports multiple paths, including Claude, Codex, Hermes, OpenCode, Gemini, Kiro, Copilot, and LiteLLM/OpenAI/OpenRouter-style completion backends. That said, the Claude / Claude Code path does use the Claude Agent SDK, so Anthropic’s dedicated monthly Agent SDK credit policy can affect users running Ouroboros through that backend.

For lightweight personal usage this may be fine, but heavier automation is where the concern becomes real: ooo auto, repair/evaluation loops, GitHub automation, long-running execution sessions, or recursive agent workflows can consume Agent SDK credits much faster than ordinary chat usage. For those cases, users should probably choose an explicit runtime and billing strategy instead of assuming a Claude subscription provides unlimited agent automation.

There is already active work improving runtime portability and reducing Claude-specific assumptions. In particular:

• feat(codex): install runtime skill capability guide #1028 adds Codex runtime skill capability guide installation.
• feat(runtime): ship skill capability guides for Hermes and Claude #1030 adds Hermes/Claude parity for generated skill capability guides.
• docs(runtime): record skill capability guide coverage #1033 documents remaining runtime coverage and fallback behavior.
• feat(mcp): expose seed generation client gates #1034 exposes MCP client gate metadata so clients can handle workflow gates more consistently.

So I would treat this as a real docs/product concern rather than a blocker for Ouroboros as a whole. Claude remains a supported path, but we should document clearly that Claude-backed runs may consume the dedicated Agent SDK credit bucket, recommend alternate backends for heavy automation, and consider follow-up work such as budget guards, usage warnings, fallback guidance, and graceful pause/resume behavior when quota or credits are exhausted.

[Q00]

@laughinglion Hi thanks for raising this, and thanks @shaun0927 for the thorough reply above. let me add a few notes from the project-lead side.

On the credit math, Max plan users get roughly $200/month of dedicated agent SDK credit (right?). you can run Ouroboros on the claude backend within that envelope - for casual or single seed work, it's workable. but for the broader MCP and harness-engineering eco system, this direction is clearly not a health one.

On Anthropic's recent direction, the UX of claude code wins(e.g. askUserQuestion) are real, but two recent moves give me pause.

1. the update that hides MCP tool responses from the user.
2. this dedicated Agent SDK credit policy

Taken together, the signal is that leaning exclusively on claude code as a harness is getting riskier over time. Diversifying the runtimes you compose with is increasingly the prudent choice.

Why ouroboros is positioned for this. Ouroboros is build as an Agent OS. the agent runtime and handler layers are abstracted so that the same Seed -> Execute -> Evaluate loop can run across very different backends. Today the adapter surface already covers a wide range of tools, and recent PRs have pushed it further:

• goose CLI landed recently as a first-class runtime
• kiro, hermes, codex, opencode, gemini, copilot and LiteLLM, OpenAI, OpenRouter style completion backends all live behind the same adapter contract.

so if the claude credit bucket becomes a real constraint for your workload, you don't have to fork your workflow. you swap the runtime and keep the rest of the pipeline intact. We'll continue to invest in runtime parity precisely so this kind of switch stays cheap. (docs, capability guides, fallback behavior - some of which is already tracked in #1028 #1030 #1033 #1034)

Really appreciate you using and caring about Ouroboros. if you have ideas, especially around budget gurads, quota-aware pause/resume, or better runtime-selection UX, contributions are very welcome!