Skip to main content
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, 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:
Run the enrollment command for each subscription you want to add:
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:

​
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 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. Members who don’t enroll still use their own seat through 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:
Each row shows the provider, an external account identifier, and one of these states: status checks connectivity, client configuration, and account health in one command:
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:
Send a short prompt, then run:
Send another short prompt. In Codex, use the installed Weave Router skills:
Send a short prompt, then run:
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:
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.
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 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.
Last modified on October 17, 2026