---
title: Keys, credit and costs
description: Give each app, course and chat page a key paid the way you intend, and know who pays for every request.
updated: 2026-10-29
---

> All VIABLE docs, for people and their agents: https://developers.viablelab.org/llms.txt

# Keys, credit and costs

Give each piece of work its own key, set its limits, and know who pays. The project's owner pays for every request.

## API keys

An API key, made in [Operate → API keys](/dashboard/keys), is how code calls VIABLE.

- A **service key** belongs to the project and keeps working when people leave. Only the owner makes one. Use it for apps, courses and chat pages.
- A **personal key** belongs to the member who made it. It stops if they are paused, leave or become a viewer.

Choose **Create key** (editors see **Create personal key**), set its **Scopes**, **Limits** and **Model access**, and keep the secret on your server. Before someone leaves, the owner can choose **Make service key** on their key.

- **Scopes:** courses and chat pages need **Run agents** (`agents:execute`).
- **Limits:** **Requests per minute**, **Daily tokens** and **Monthly cost (USD)**, all optional.
- **Model access:** with **Selected models only**, allow every model the key's agents use.

Pausing a key can be undone; revoking can't.

## A course's or chat page's key

- **A course:** its **Settings → The AI → The AI key: who pays for the course's AI**. **AI messages per learner per day** can cap each learner.
- **A chat page:** the agent's **Chat page → Key & limits → Runs on**.

Use a service key, one per course or chat page, so **Usage** shows what each costs.

> [!WARNING]
> A whole class shares the course's key. A low daily token limit can stop the AI for all 30 learners mid-lesson.

## Provider keys and key pools

Under [Account → Billing → Provider keys](/dashboard/provider-keys), add your own keys for OpenAI, Google Gemini, UF NaviGator or another OpenAI-compatible endpoint. Requests then bill your provider, not VIABLE credits, with no code changes. Keys for one provider form a **key pool**: when one runs out or is rejected, the next takes over. A lab can pool its grant keys.

## Credit and who pays

[Account → Billing → Credits](/dashboard/credits) shows one balance. Every project you own draws from it, whichever member's key made the request.

| Request | Paid by |
| --- | --- |
| A catalog model whose provider has a pool set to **Every … model request** | That pool |
| A catalog model with no such pool | The owner's VIABLE credits |
| A model called as `@name/<model>` | That pool |
| A pool with no key available | An error, or credits if the pool chose **Use VIABLE credits** |

The project's **Overview** shows the result under **How this project is billed**.

Costs are estimated from listed model prices; an agent run costs the sum of its model calls. When credit runs out, requests fail with 429 `account_credit_exceeded`, but provider-key requests keep working.

::: cards
- [Request logs and usage](/docs/project/logs-and-usage): see what each key spent.
- [Members and roles](/docs/project/members-and-roles): decide who can make keys.
:::