> For the complete documentation index, see [llms.txt](https://docs.tabnine.com/main/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tabnine.com/main/administering-tabnine/managing-your-team/user-management/service-accounts-and-token-limits.md).
# Service Accounts and Token Limits
A Service account is a first-class entity in Tabnine (with its own identity, authentication credentials, and token limits that are all separate from your regular user seats).
#### **When to use a Service Account**
Use a Service Account when you want Tabnine to power automated workflows such as:
* CI/CD pipeline code reviews or test generation
* Automated code refactoring or migration scripts
* Background agent tasks that run outside of an IDE session
* Any programmatic integration where a human is not directly interacting with Tabnine
#### **Token limits by plan tier**
Service Accounts have their own token ceilings, separate from regular users, and significantly higher to accommodate automated workloads:
| Plan tier | Default monthly token limit |
| -------------- | ------------------------------------------- |
| **Business** | 5 billion tokens/month per Service Account |
| **Enterprise** | 50 billion tokens/month per Service Account |
The enforcement and alerting behavior (thresholds at 80% and 100%, soft/hard blocking) follows the same patterns as regular user limits.
#### **Authentication & API keys**
Each Service Account is provisioned with its own API keys that each have these specific properties:
* **Org-scoped:** Each key is tied to a specific organization and account and cannot be used across orgs.
* **Rotatable:** Admins can rotate keys at any time without deleting the Service Account
* **Revocable:** Keys can be revoked immediately if compromised.
* **Audited:** All key lifecycle events (creation, rotation, and revocation) are captured in the audit log.
When a request arrives, Tabnine identifies the entity type (regular user vs. Service Account) from the credentials and routes it to the appropriate token limits and policies. Existing user flows (login, permissions, IDE auth) are completely unaffected.
***
### **Admin UI: Managing Service Accounts**
The Admin UI includes a dedicated section for Service Account management under the **User Management** page. From here, admins can perform all lifecycle operations and monitor usage.
#### **Creating a Service Account**
Navigate to **User Management,** then press the button in the upper-righthand corner **Create Service Account** (this should be blue; if gray, speak to your Admin to enable service accounts for you).
Click **Create Service Account**.
Provide a name for the agent (e.g., "CI Pipeline Backend", "Nightly Refactor Bot").
Configure specific guidelines for the agent. These guidelines are added to the prompt for this account.
Finally, click **Create**. An API key is generated and displayed. Copy the key (***it will not be shown again***).
#### **Editing a Service Account**
1. In the Users list, click the account you want to modify.
2. Update the agent's name, or other settings as needed.
3. Click **Save**.
To rotate or revoke the agent's API key, use the key management controls on the agent detail page.
#### **Deleting a Service Account**
1. In the users list, click the account you want to remove.
2. Click **Delete**. Confirm the action when prompted.
3. The agent's API key is immediately revoked and any in-flight requests will be rejected.
#### **Usage dashboard**
The usage dashboard shows token consumption across your organization, broken down by entity type. Key views include:
* **Per-agent token consumption:** See how many tokens each Service Account has consumed in the current billing period.
* **Usage trends:** Track consumption over time to identify spikes or steady growth.
* **Limit proximity:** See how close each agent (or user) is to their monthly ceiling.
* **Enforcement events:** View a log of any enforcement actions (warnings, soft-blocks, hard-blocks) that were triggered.
* **Org-level breakdown:** Compare regular user vs. Service Account usage at the organization level to understand the balance of human vs. automated consumption.
The dashboard follows existing admin UI design patterns and is accessible to users with the Admin role.
### **Token Limits**
Configurable **monthly token fair-use limit** for regular (human) users are meant to enforce the use of Service Accounts for CI/CD purposes. Together, these features give admins granular control over how tokens are consumed across their organization, by both people and automated agents.
#### **Understanding Entity Types**
Tabnine distinguishes between two types of users in your organization:
* **Regular Users** are human developers who interact with Tabnine through an IDE (VS Code, JetBrains, Eclipse, etc.). Each regular user consumes tokens when they use code completions, chat, and agent features.
* **Service Accounts** are programmatic, non-human entities designed to run Tabnine in CI/CD pipelines, automated workflows, and background jobs. Each Service Account is a distinct billable entity with its own identity, API key, and token budget.
This distinction is important because CI pipelines can consume significantly more tokens than a human developer. Separating the two entity types allows admins to set appropriate limits for each, track usage independently, and ensure that automated workloads don't impact the token budget available to developers.
#### Token Fair-Use Limits for Regular Users
Regular licensed user accounts are intended for human developer activity. To prevent account abuse, token sharing, and the use of personal accounts for large-scale automation, Tabnine applies a monthly fair-use limit of 1 billion tokens to each regular user.
This threshold is intentionally high and is not expected to affect normal human usage. Users who reach it are typically running CI/CD jobs, pull-request automation, bots, or other automated workflows through their regular user account.
When a regular user reaches the monthly fair-use limit, Tabnine blocks additional model interactions for that user until the limit resets.
For automated workflows, use a Service Account rather than a regular user account. Service Accounts are dedicated non-human accounts designed for CI/CD, pull-request automation, bots, and other agent-based workflows. They have their own licenses and capacity tiers, allowing organizations to select the appropriate level of usage without consuming or blocking an individual developer’s account.
After purchasing the required Service Account license, an administrator can create and manage the account from the User Management page.
#### **Usage Tracking**
Token usage data is stored for billing, analytics, and audit purposes. Admins can query usage by organization, entity type (regular user vs. Service Account), individual user, and time range. See the **Usage Dashboard** section below for details on how to view this data in the Admin UI.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.tabnine.com/main/administering-tabnine/managing-your-team/user-management/service-accounts-and-token-limits.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.