> ## Documentation Index > Fetch the complete documentation index at: https://docs.reactor.inc/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > To build and serve your own model, start at /deploy/development/quickstart and /deploy/development/overview. Deploying is the default path: reactor init scaffolds a workspace, reactor auth login authenticates, and reactor model deploy registers the model, publishes the release with the weights/ folder, and activates it on Reactor's GPUs, in one command from that workspace. Docker must be running, because the publish step builds the image locally. Bump model.version in reactor.yaml before redeploying a change, because a release that already has an image is reactivated as it is. Deployment access is granted per account, so contact team@reactor.inc if a deploy is refused. Every key in reactor.yaml is documented at /deploy/platform/reactor-yaml. Model code imports reactor_runtime; Python client code imports reactor_sdk. The runtime overview explains the model interface. Running the model on your own machine with reactor run is optional and needs a GPU you attach with --gpus; /deploy/development/local-testing covers that loop and pairs a complete brightness model with a Python client test in a separate brightness-test workspace. > Reactor hosts multiple models, each with its own connect slug (modelName) and command/event schema. The video model catalog — slug, typed SDK package, and links to its schema — is at /model-api-reference/overview. Robotics policy documentation starts at /robotics/overview; X-WAM observations, actions, and client integration are under /robotics/xwam/; Cosmos3 Nano Policy DROID is under /robotics/cosmos/nano-policy-droid/. Some models expose one slug per experience (e.g. HappyOyster); always take the slug from the model's own pages, never guess it. > Fastest path to a working app: `npx create-reactor-app my-app --model=` scaffolds a complete app with secure auth wired up. Typed TypeScript SDKs are published as @reactor-models/; Python uses the base reactor-sdk package. > Auth: exchange an API key (rk_...) for a JWT via POST https://api.reactor.inc/tokens from your server. Never put the API key in client-side code. > Append .md to any docs URL for clean Markdown. Search these docs via the MCP server at https://docs.reactor.inc/mcp. # API Keys and Billing > Create API keys for a team and pay for the sessions they start An API key belongs to one account. Reactor bills a session to the account whose key started the session. Switch the dashboard to the team before you create a key. The team then pays for all that the key does. ## API keys per team Reactor binds each API key to one account at creation. The binding never changes. A key from your personal account cannot start sessions on the balance of a team. A team key cannot spend from your personal account. **1. Switch to the team** Open the account menu and select the team under **Switch account**. A key can carry only the roles you hold in that team. The SDKs and the CLI need the developer role. **2. Create the key** Open the **[API Keys](https://reactor.inc/account/api-keys)** page and create a new key. The dialog names the account that owns the key. To create a key for another account, switch to that account first. **3. Copy and store the key** The key starts with `rk_`, like each other key. Store the key with the other secrets of your team. Do not commit the key to source control. The **API Keys** page lists every key you own, from your personal account and from each team. Each row names the account that owns the key. Only **Create key** follows the account you selected. A team key stops working in two cases: * The person who created the key leaves the team, or an admin removes that person. * Reactor deactivates the team. The keys from your personal account and from your other teams continue to work. > [!TIP] > > Name each key after the thing that uses it, for example `Production` or `CI`. When a member leaves > and their keys stop, the team can then see what will break. ### The CLI `reactor auth login` creates a key in the same way. The approval page in your browser asks which account the login is for. The page lists each account you belong to. You can select only an account where you hold the developer role. The CLI binds the new key to the account you select. See [Log in to a team](https://docs.reactor.inc/deploy/platform/authentication.md#log-in-to-a-team). ## Billing per team Each team has its own balance, payment method, and invoices. These are separate from the personal account of each member. Switch to the team to see them on the **[Billing](https://reactor.inc/account/billing)** page. * A session that a team key started draws from the balance of the team. Reactor never bills the member who created the key. * Account admins and billing admins buy credits for the team and manage its payment method. Developers can see the balance but cannot add to it. * The **Usage** page shows the sessions of the account you selected. The usage of a team is one view. Your personal usage is another view. The prices, the meter, and the rules to add funds are the same for each account. See [Pricing & Billing](https://docs.reactor.inc/resources/billing.md). Session quotas also apply per account. See [Rate limits](https://docs.reactor.inc/resources/rate-limits.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.