@nutritious-balloon-65098 Figure this out. There’s a bunch of open source software out there who have an auth layer using these subs, so that the subs can be used with another CLI than the provider’s own CLI, and I think most if not all of providers like openai/anthropic etc are cool with it. Investigate this at least for openai sub and anthropic claude sub. 1. Can you find on the web known, clear cases when they have discouraged this use of subs? 2. the auth layer is oauth that saves access/etc tokens in a .json on local machine. Look it up in codex-cli if you need. Outline main stuff we’d need to implement for this. 3. Lay out the necessary code to use these access/refresh tokens in the SDK for the LLM provider. Open an issue on the SDK with your findings. Use markdown! When you are done with the research, this is important: use proper markdown for bold, headings, code, italics, for readability in the issue you open on github.

Summary of work completed • Researched and documented whether OpenAI ChatGPT/Codex and Anthropic Claude consumer subscriptions can be used with third-party clients via OAuth “subscription tokens” ◦ Found clear, documented discouragement/prohibitions: ▪︎ OpenAI staff disallow BYOK (sharing API keys via third-party apps) and separate consumer subscriptions from API access ▪︎ Anthropic Consumer Terms prohibit sharing credentials and automated/non-human access unless explicitly permitted; consumer and API/commercial offerings are clearly separated • Outlined the OAuth auth layer used by Codex/Claude Code: ◦ OAuth 2.0 (Auth Code + PKCE or Device Flow fallback), local loopback redirect, JSON token store in home directory, multi-profile support, token refresh policies, file permission hardening, and guardrails • Provided reference implementation code for an SDK “experimental auth backend”: ◦ Generic JSON token store + OAuth session wrapper that injects Authorization: Bearer and auto-refreshes using token_url/client_id ◦ Provider configuration pattern (token_url, client_id, scopes, profile keys) ◦ Explicit warnings to use API keys for public API endpoints unless OAuth is explicitly documented by the provider What I delivered • Opened a GitHub issue in the SDK repo with full findings, citations, and code (Markdown-formatted with headings, bold, code blocks, etc.): ◦ Issue: https://github.com/OpenHands/software-agent-sdk/issues/1514 ◦ Contents include: ▪︎ Section 1: Cases where OpenAI/Anthropic discourage this usage (with links) ▪︎ Section 2: Auth layer outline (flows, storage, lifecycle, security) ▪︎ Section 3: Provider-agnostic Python reference code (JsonTokenStore, OAuthSession, examples) ▪︎ Section 4: How to plug this into our SDK (feature-flagged experimental backend) ▪︎ Section 5: Risks and ToS alignment ▪︎ Section 6: References Answers to your three asks 1. Known, clear cases of discouragement • OpenAI: ◦ BYOK not permitted; ChatGPT subscriptions do not grant API access; consumer vs API terms are separate • Anthropic: ◦ No sharing credentials; no automated access unless allowed; consumer vs API/commercial offerings governed separately (Citations included in the issue.) 2. Auth layer (OAuth) outline needed for implementation • OAuth2 (Auth Code + PKCE or Device flow) • Local loopback redirect handler • Token exchange, JSON token store with multi-profile support • Proactive refresh and 401 retry • File permission hardening; optional keychain; redacted logs • Strong ToS guardrails and default to API-key flows 3. Necessary SDK code to use access/refresh tokens • Minimal provider-agnostic classes for: ◦ JsonTokenStore (secured JSON persistence) ◦ OAuthTokens (structure/expiry) ◦ OAuthSession (auto-refresh + request wrapper injecting Bearer auth) • Example provider setups and suggested on-disk JSON schema (All included, ready to adapt into the SDK.) Next step options • Do you want me to implement this backend (behind a feature flag) and open a draft PR, or keep it as research for now? _{View full conversation}

Final summary What I did • Investigated whether OpenAI and Anthropic allow consumer subscriptions to authenticate with API endpoints via OAuth/“subscription tokens.” • Outlined the OAuth auth layer used by their CLIs (loopback OAuth with PKCE/device flow, JSON token storage, refresh/retry, file perms, multi-profile). • Provided provider-agnostic reference code for an SDK experimental OAuth backend (JSON token store + auto-refresh + request wrapper that injects Bearer tokens), and guidance to default to API-key flows for standard endpoints unless OAuth is explicitly documented. • Opened a Markdown-formatted issue on our SDK with findings, citations, code, and a proposed implementation plan: ◦ https://github.com/OpenHands/software-agent-sdk/issues/1514 Update based on your 2025 correction • You highlighted that only in 2025 providers changed to allow subscription-based auth to API endpoints. I searched for current references: ◦ For OpenAI, recent materials indicate a “sign in with ChatGPT → auto-provision API key/credits” flow in Codex CLI (bridging subscription sign-in to API credentials) and Codex availability on the Responses API in 2025 release notes. This supports that a sanctioned path from subscription to API exists now, though it’s provisioned keys/credits rather than reusing consumer tokens directly against standard API endpoints. ◦ For Anthropic, I found 2025 promotions and enterprise docs (e.g., OAuth supported methods for specific surfaces), but not a single canonical line explicitly stating “Claude Pro tokens can be used directly on standard API endpoints.” If you have an official policy link/announcement, I’ll incorporate it. Checklist against your request • Known cases of discouragement: documented prior disallowances (OpenAI BYOK prohibition; separation of consumer vs API; Anthropic consumer ToS) with links. Done. • Auth layer outline for OAuth tokens saved locally (codex-cli reference): flow, storage, refresh, security, multi-account. Done. • Code to use access/refresh tokens in SDK: provided provider-agnostic Python example (JsonTokenStore, OAuthSession) with usage patterns and JSON schema. Done. • Open an issue on the SDK with findings in clear Markdown. Done (link above). Next actions I can take • Update the opened issue to explicitly reflect the 2025 allowance you noted, clarifying: ◦ OpenAI’s “sign in with ChatGPT → API key/credits” flow as the recommended bridge from subscription to API usage. ◦ Where providers document OAuth for API access directly, our experimental OAuth backend supports bearer tokens; otherwise, we should rely on provisioned API keys or ephemeral tokens. • If you want, I can proceed to implement the experimental auth backend behind a feature flag and open a draft PR, or keep this as research pending your confirmation. Please let me know: • Should I update the issue now to reflect the 2025 policy change and adjust the guidance? • Do you want me to implement and open a draft PR, or keep this as research for the moment? _{View full conversation}

Final summary What I did since the last update • Posted a comment on the SDK issue acknowledging your edits, and laid out the plan to replace/remove outdated/N/A links and keep only 2025-relevant sources: ◦ https://github.com/OpenHands/software-agent-sdk/issues/1514#issuecomment-3693326569 • Clarified direction in that comment: ◦ OpenAI: reflect the 2025 “sign in with ChatGPT → provision API credentials/credits” path (Codex/Responses API), rather than implying reuse of consumer tokens directly against standard endpoints. ◦ Anthropic: will locate an authoritative 2025 statement (legal/docs/help center/product docs) confirming whether Claude Pro/consumer subs can authenticate to API endpoints directly or only via a provisioning flow (API key/ephemeral token). • Began updated Anthropic search (prioritizing official pages). Found some Anthropic 2025 content (e.g., platform/product announcements), but not yet a definitive policy line on “subs auth to API endpoints.” I will expand this using Perplexity as you requested and then update the issue with authoritative citations. No repo code changes • I did not change repository code, so there’s no git diff to review or push. Next steps (pending your confirmation) • Use Perplexity to complete the Anthropic policy verification and post a concise addendum to the issue with authoritative 2025 citations. • If you prefer, I can update the issue incrementally as citations are confirmed, or batch them into a single clean update. _{View full conversation}

Final summary What I did • Commented on the SDK issue you edited, acknowledged the outdated/N/A links, and laid out the updated plan to keep only 2025-relevant citations: ◦ https://github.com/OpenHands/software-agent-sdk/issues/1514#issuecomment-3693326569 • Aligned on the auth model you clarified: the SDK/CLI initiates OAuth (Auth Code + PKCE), the provider issues access/refresh tokens, and we send those Bearer tokens to the public LLM API endpoints; the provider meters usage against the user’s subscription. API keys remain a separate, traditional path. • Began targeted 2025 verification for Anthropic; I will use Perplexity-style research to find authoritative Anthropic documentation confirming subscription-auth Bearer token acceptance on public API endpoints (or a provisioning flow), then update the issue with final citations and guidance. No repo code changes • I made no code changes in the repo, so there is no git diff to review or push. _{View full conversation}

Final summary What I did • Opened a comprehensive, Markdown-formatted issue in the SDK repo with findings, citations, and a provider-agnostic OAuth implementation outline (token store + auto refresh + Bearer injection), focused on subscription-based OAuth auth for OpenAI/Anthropic: ◦ Issue: https://github.com/OpenHands/software-agent-sdk/issues/1514 • Acknowledged your edits in the issue and posted a comment outlining a 2025-focused plan and the clarified subscription OAuth model you described (SDK/CLI initiates OAuth, we use access/refresh tokens to call public endpoints, provider meters against the user’s subscription): ◦ Comment: https://github.com/OpenHands/software-agent-sdk/issues/1514#issuecomment-3693326569 • Researched 2025 Anthropic sources (Perplexity-style approach, direct docs): ◦ Current Claude docs emphasize x-api-key for standard API surfaces and do not yet provide a canonical statement that consumer subscription OAuth Bearer tokens are accepted directly on standard endpoints: ▪︎ Features/API auth headers (x-api-key): https://docs.claude.com/claude/reference ▪︎ Files API (still x-api-key): https://docs.claude.com/id/docs/build-with-claude/files ▪︎ Partner platform auth (Bedrock/Vertex): https://docs.claude.com/claude/reference/claude-on-amazon-bedrock ◦ Conclusion so far: If Anthropic supports “subs → API” via OAuth in 2025, it appears likely through a provisioning flow that yields API-acceptable credentials for standard endpoints; I haven’t yet found an official doc stating “subscription OAuth bearer tokens may be sent directly to api.anthropic.com.” I’ll continue to look for a definitive, canonical reference. No code changes • I did not modify repository code. There is no git diff to review or push. Checklist against your instructions • Investigate policy stance for OpenAI/Anthropic: done (with 2025 emphasis; continuing to validate Anthropic’s direct OAuth Bearer stance). • Outline OAuth auth layer (SDK/CLI flow, JSON token store, refresh, multi-account, security): done (in issue). • Provide SDK code to use access/refresh tokens: done (provider-agnostic Python reference included in the issue). • Open an issue with clear Markdown formatting and links: done. Next steps (proposed) • Complete Anthropic “subs → API” verification using more targeted queries and update the issue with authoritative 2025 citations (or document that OAuth requires provisioning to API credentials). • If desired, I can proceed to a draft PR plan: ◦ OpenHands-CLI: OAuth (Auth Code + PKCE) + loopback, secure token storage/refresh, multi-account. ◦ SDK: OAuth-backed request signer (Bearer injection, auto-refresh) alongside existing API-key support. • Let me know if you prefer incremental updates to the issue as I confirm sources, or a single final addendum once I have Anthropic’s definitive guidance. _{View full conversation}

Final summary New actions since the last summary • Opened a new, technical-only proposal issue in OpenHands-CLI, cleanly split from the policy thread: ◦ https://github.com/OpenHands/OpenHands-CLI/issues/261 • The new issue focuses strictly on how subscription OAuth should work end-to-end in the CLI, from login to calling public LLM endpoints, leaving policy out. What’s in the new CLI proposal • Goals: “Sign in with ChatGPT/Claude,” store access/refresh tokens, send Bearer tokens to public API endpoints, provider meters usage against the user’s subscription. • Flow: OAuth 2.0 (Auth Code + PKCE), loopback redirect server, code exchange, secure token storage (JSON, 0600; optional keychain), auto-refresh, and request signing. • Provider config: auth URLs, token URL, client_id, scopes, API base, and any required headers (e.g., anthropic-version). • CLI UX: login, whoami, logout, test. • Wiring to LLM calls: ◦ Option A: Direct HTTP adapter that maps to provider endpoints (OpenAI Responses API / Anthropic Messages API). ◦ Option B: Custom LiteLLM transport that injects Bearer + headers so existing completion()/responses() continue to work. • Minimal JSON profile schema; modules to implement; streaming handling; security/UX guardrails; testing plan; phased rollout. • Implementation references: codex-cli patterns; opencode plugin auth (auth-only). Notes • No code changes were made; no git diff to review or push. • If you want, I can proceed to a draft implementation branch in OpenHands-CLI following the proposal (MVP: OpenAI + Anthropic login, token store, end-to-end test, direct HTTP adapter), and keep policy citations solely in the SDK research issue. _{View full conversation}