> ## Documentation Index > Fetch the complete documentation index at: https://docs.weaveos.com/llms.txt > Use this file to discover all available pages before exploring further. # Link Claude and Codex subscriptions > Enroll Claude and ChatGPT subscriptions so Weave Router can use them across your coding-agent requests Weave Router can keep an encrypted pool of Claude and Codex subscription accounts for each subscriber (the person who enrolled them). Enrolled accounts serve eligible requests on their included plan capacity. Each subscription belongs to a verified user. Router tries your own subscriptions first, then subscriptions registered by other active members of your organization when sharing is enabled. Sharing defaults on for existing and new organizations; an admin can turn it off while leaving personal subscriptions available. Borrowing capacity grants no permission to manage someone else’s subscription and does not spend the owner’s Weave allowance or prepaid balance. An enrolling key is audit metadata, not a capacity boundary. Existing keys continue to work. An admin can assign a user owner to an older unassigned account without replacing the key, reconnecting OAuth, or changing the account’s tokens. Managed subscription pools are a deployment setting, not an organization setting. They are always enabled for the hosted router at `router.workweave.ai`, so there is no pool-enable switch in organization or router settings. The organization settings link redirects to the hosted router settings surface by design; that page manages keys and routing, not the deployment feature flag. On a self-hosted router, set `ROUTER_SUBSCRIPTION_POOLS_ENABLED=true` on the deployment if the commands below report that pools are disabled. ## What you need * Your own personal Weave Router key (`rk_…`). Get one through [Router onboarding](https://router.workweave.ai/start/install), which also establishes your verified Router user identity. Organization keys issued from router settings belong to no user, so enrollment with them fails with `subscription_owner_unavailable`. * A Claude Pro, Max, or Team seat for Claude enrollment, or a ChatGPT Plus, Pro, or Business seat for Codex enrollment. * Node.js 18 or later, OpenSSL, and `bash` (Git Bash or WSL on Windows). If `jq` is missing, the command downloads it on supported platforms. Keys can retain separate request attribution and spend limits without partitioning subscription capacity. Registered accounts are identified by their user owner and organization registrations, and remain available after enrollment-key rotation or deletion. Personal account management remains owner-only; organization admins can assign legacy unowned accounts. ## Enroll an account Set the router key in your shell without pasting it into chat or committing it to a repository: ```bash theme={null} export WEAVE_ROUTER_KEY='rk_…' ``` Run the enrollment command for each subscription you want to add: ```bash theme={null} npx @weave-os/router login claude npx @weave-os/router login codex ``` Claude opens a browser authorization flow and asks you to paste the returned code. Codex opens its device flow and prints a short code to enter. The router stores an encrypted refresh token, not the provider password. For a non-default deployment, pass its base URL explicitly: ```bash theme={null} npx @weave-os/router login claude --base-url https://router.example.com ``` ### Team plans Each member enrolls their own seat with their own personal key. On the Claude consent screen, pick the Team organization. Seats are identified by the provider user and organization, so every member of one Team plan is a separate account owned by that member. The router always tries your own seat first. While [subscription sharing](#how-routing-and-billing-work) is on, it can also serve your request from a teammate's seat when yours is busy or out of quota, and theirs from yours. To keep each person's usage on their own seat, an admin turns off **Share Claude and Codex subscriptions** in the engineers card of [router settings](https://app.workweave.ai/organization/settings/weave-router). Members who don't enroll still use their own seat through [subscription pass-through](/router/authentication#subscription-pass-through): the router forwards their Claude Code or Codex login upstream. ## Check account health List the subscriptions you own. Keys authenticate requests; rotating or deleting an enrollment key does not remove registered capacity: ```bash theme={null} npx @weave-os/router accounts list --claude ``` Each row shows the provider, an external account identifier, and one of these states: | State | Meaning | | - | - | | `enabled` / `ready` | The router can lease this account. | | `enabled` / `cooldown` | The provider reported temporary quota exhaustion; the router will retry it after the cooldown. | | `disabled` | An administrator disabled the account or the provider rejected its credentials. | `status` checks connectivity, client configuration, and account health in one command: ```bash theme={null} npx @weave-os/router status --claude ``` For Claude Code, `/status` must show the router base URL. The routed model in the status line or `✦ Weave Router → …` marker confirms that the request went through Weave. ## Verify both providers Run a short request in Claude Code or Codex, then force one model from each native subscription family. In Claude Code, run: ```text theme={null} /force-model gpt-5.6-sol ``` Send a short prompt, then run: ```text theme={null} /force-model claude-opus-5 ``` Send another short prompt. In Codex, use the installed Weave Router skills: ```text theme={null} $force-model gpt-5.6-sol ``` Send a short prompt, then run: ```text theme={null} $force-model claude-opus-5 ``` Send another short prompt. Use `npx @weave-os/router models --claude` or `npx @weave-os/router models --codex` to see the model IDs currently available to each installation. The router report will show the served model and subscription-covered cost after ingestion. ## How routing and billing work * Claude subscription accounts are used for Anthropic Claude models. * Codex subscription accounts are used for the native Codex model family. * A model outside the matching subscription family uses Weave credits, your configured provider key, or an eligible fallback. * Subscription-covered actions debit `$0` from Weave credits. Their token usage can still appear in usage and routing reports. * Router tries your personal subscriptions, then subscriptions owned by other active members of your organization. Organization sharing is on by default and an admin can turn it off without disabling your personal subscriptions. * For automatic routing, a suitable subscription-covered alternative may be chosen within the existing quality, tool and context requirements. Explicit models stay fixed. * Authorized API capacity serves a request only when no enrolled subscription can serve its model, or after every eligible one is out of included quota. Busy seats, credential errors, and the 10-second rotation budget running out return an error instead of buying API. Accounts known to be in paid extra usage are skipped. Turn off extra usage at the provider if you need a strict guarantee, because the router cannot see an account cross into it until the response comes back. * Boost follows the same selection policy as default stable routing; Max continues to ignore linked subscriptions. ## Disable or remove an account Use the account identifier shown by `accounts list`: ```bash theme={null} npx @weave-os/router accounts disable --claude npx @weave-os/router accounts remove --claude ``` Only the owner can disable or remove a personal account. Disabling takes an account out of serving. Remove an account when you want to delete its encrypted refresh token; re-enroll the subscription to add it again. ## Troubleshooting The deployment has not enabled managed pools. This only happens on self-hosted routers: set `ROUTER_SUBSCRIPTION_POOLS_ENABLED=true` on the deployment, or use the normal subscription pass-through described in [router authentication](/router/authentication). Every registered subscription belongs to a verified user. Older accounts without an owner are visible to organization admins under registered subscriptions. An admin can assign an active member with a verified Router identity while preserving the account and its existing credentials. No replacement key or OAuth reconnect is needed. A cooldown means the provider recently returned a quota response. Leave the account enrolled; the router will make it available after the reported reset time. A disabled account needs re-enrollment after a credential rejection. Confirm that the account is listed as `enabled` and `ready`, that the selected model belongs to the matching provider family, and that the client is using your organization’s router base URL. Enrollment keys do not partition capacity. Start a fresh client session after changing its router configuration. Refresh tokens are encrypted at rest and owned by a verified user. Organization registrations let other active members borrow serving capacity when sharing is enabled, without granting account-management rights or spending the owner’s Weave balance. Unassigned legacy accounts remain unavailable until an admin assigns an owner. Never put a refresh token or router key in source control or support messages. See [router authentication](/router/authentication) for the distinction between router keys, direct subscription pass-through, and provider keys. ### Measuring included subscription coverage Coverage counts each admitted main inference request targeting an OpenAI or Anthropic family once. Failed requests stay in the denominator, including a request refused before provider dispatch because no authorized capacity can serve it. The upstream winner is authoritative when present; an exported routing decision represents a request that has no upstream span. Webhook redelivery and decision/upstream pairs do not add requests. Successful included subscription wins form the numerator; paid extra usage never does. Missing winning-credential attribution is counted separately, including decision-only failures. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.