Connect a Personal Subscription Credential

TL;DR

Connect a subscription Credential when you run Zozo on your own repositories and budget. After validation, set its Intake and Dispatch model and effort in the same Credentials row before assigning it to work.

If you're running the harness against your own repositories on your own money, as a solo tenant, a personal subscription credential is the path we recommend: your hosted Plan fee already covers its inference, where a vendor api_key would meter usage on top of it. If instead you're running this unattended on behalf of a client you separately invoice, an api_key stays the sanctioned default for that path. Either kind works for either kind of tenant. This is guidance about cost, never a gate: nothing about your Plan restricts which Credential kind you can add.

Auth & Consent explains why a personal subscription Credential (an OAuth token or an uploaded auth file) needs an explicit, recorded consent step, how your vendor's terms apply, and why a vendor api_key never needs that step. This page is the "how" for the subscription path. Connecting a Credential only proves a Provider works; it doesn't say which Provider your Projects and sessions actually use; see Understanding Credentials for that.

Every Credential has its own name rather than being implied by its Provider. Setup's first step uses the same form as the Dashboard's Credentials page; use Setup while onboarding, or follow the steps below when you skipped it or are adding or rotating a Credential on an existing Stack. The Credentials page lists every Credential you've provisioned (name, Provider, kind, health). A Credential's consent, once recorded, is tied to its name: deleting the Credential deletes the consent with it, and reconnecting under a fresh name starts the consent step over rather than inheriting it.

Steps

1. In Setup, stay on Credential; Connect a Runtime. If you are doing it by hand, open Credentials in your Dashboard (#/auth) instead.
2. In the Add a Credential form, name the Credential (e.g. personal-claude), choose its Provider (Claude or Codex), then choose its kind; the subscription kind, not API key:
   • Claude: Subscription (OAuth token). Run claude setup-token where you're already logged into Claude Code. It prints a long-lived token starting with sk-ant-oat01-.
   • Codex: Subscription (auth.json). Run codex login on your own machine to authorize in a browser, then upload the resulting ~/.codex/auth.json file. Choosing the subscription kind is what makes the next step appear at all; a vendor api_key Credential skips it entirely.
3. Read and check the disclosure that appears. It confirms that your subscription is governed by your agreement with its vendor and that Zozo may disable subscription Credentials if the vendor asks it to. The Add Credential button stays disabled until you do.
4. Paste the token (or choose the file) and click Add Credential.

What happens next

Saving blocks for a few seconds; your Stack validates the credential by actually exercising the Runtime with it, never assuming it's valid just because you provided one. On success, the new row appears in the Credentials list with a health badge reading authenticated and its consent recorded with a timestamp, so you won't be asked to re-consent the next time you rotate the same Credential (re-enter its own name in the Add form to overwrite it in place, rather than creating a second Credential). On failure, nothing is added and an error message explains why.

Set Model and Effort

In the new Credential's row, click Tune runtime to open its Runtime tuning panel. Set Model and Effort independently for Intake + Wayfinder and Dispatch, then click Save tuning. The model field suggests known model IDs but accepts any Runtime-native ID.

Blank fields use the Provider's default. Saving tuning is independent from provisioning: it doesn't replace the secret, repeat the consent flow, or change the Credential's recorded health. New Threads use the saved values, while existing Threads keep the tuning they already selected.

Related

• Auth & Consent; why this consent step exists and what it does and doesn't cover.
• Quickstart; where this Credential fits into Setup and the complete path to a dispatching Project.
• Reconnect after a credential alert; what to do if this credential later stops working.
• Understanding Credentials; once a Provider is connected, how a Project actually runs on it: the primary Credential, the optional fallback, and which named Credential a Project's Threads on that Provider actually bill to once more than one exists.