Skip to content

Control Center

The Control Center (admin sidebar → Usage & Control) is where you “govern credit spend, model defaults, and build-mode access across your organization.” It has five tabs — Overview, Allocations, Build access, Automation, and Models & effort.

Every edit autosaves. The header shows “✓ Changes save automatically” and a permanently-disabled Saved button — there is nothing to click to commit a change. Reach any tab from the tab bar; a Usage report button in the header jumps to the Usage page. What credits are and what happens at depletion is covered in Credits and AI spend.

Read-only. This tab tells you, at a glance, how the credit pool is doing this period.

  • A This period band: the credit pool’s used / total, credits remaining, days until reset, and a mode pill — Standard mode (green) or Reduced mode (purple). If there’s no funded pool, it notes “figures reflect period-to-date spend only.”
  • A Pool consumption meter with markers for your thresholds (set on the Automation tab). The fill turns amber past the highest warning, purple past the downshift, and red at 100%.
  • A Spend response strip: whether the Standard model set or the Reduced models are running now.
  • Usage by role (each role’s share of credits used) and Near their limit (individuals approaching their own cap).

Set a monthly credit allocation per user. The subtitle states the rule: “Roles override the org default; individual exceptions override the role.” Allocations fold in one direction — org default → role → individual.

The Allocations tab: org default, per-role rows, and the individual exceptions table Allocations: the org default, per-role overrides, and named individual exceptions.

  1. Set the Org default — the cap for “everyone without an override.” It’s one of three kinds: Limited (with a credit amount), Unlimited, or Blocked.
  2. Override per role in the role table. Reset to org default clears a role’s row.
  3. Add a person-level exception with Add exception — a Person, a monthly allocation, and a mandatory Reason (“shown in the table, for audit”).

The caps are per-capita: each person is measured against their own monthly spend, not a shared bucket. When someone passes a Limited cap, their next prompt is refused with “You have reached your monthly credit allocation. Contact an administrator to raise your limit.” Admins are exempt from Limited caps but not from Blocked. Allocations gate interactive chat only — automations, saved agents, and workflows are never blocked by them.

The subtitle explains why this tab matters: “Build mode unlocks creating and editing workflows, skills, and data apps — the most credit-intensive work. Choose which roles can enter it, then make individual exceptions.”

The Build access tab: per-role toggle cards and individual exceptions Build access: toggle it per role, then add per-person exceptions.

  • Each role has a toggle card — Can enter build mode or Build mode off. Super Admin is pinned on and User Read-Only is pinned off (“Policy locked for this role”).
  • Add a per-person exception with Add build-mode exception — a Person, an Allow / Block choice, and a Reason.

A blocked user never sees the Build option on the start screen, and if they try to reach it another way the server refuses with “Build mode is disabled for your account. Contact an administrator to request access.” The three modes are explained in Standard, Deep analysis, and Build.

This tab is called Automation but has nothing to do with the Automations feature (triggers and actions) — it’s purely about spend thresholds. Set thresholds that fire at a percentage of the credit pool. The subtitle: “Add a threshold, pick what it does, and set the pool % it fires at. Stack as many warnings as you like — and exactly one downshift.” There are three rule types:

  • Org warning — “Email super admins and admins that the pool is running down.”
  • User warning — “Show an in-app banner to every user that credits are running low.”
  • User downshift — “Switch all agents to the Reduced models set to protect the remaining pool.” You can have exactly one of these.

Each rule has a pool-% value, an Enabled / Off toggle, a “Triggered” badge when the live usage crosses it, and edit / remove controls. Add one with the composer: “When the pool reaches [N]% do [type].” Thresholds must be between 1 and 100%.

Models & effort — model and effort defaults

Section titled “Models & effort — model and effort defaults”

Two sets of defaults per agent mode. The subtitle: “Two sets of defaults per agent mode. The standard set runs normally; the reduced set takes over when a downshift threshold in Automation is reached.”

  • A comparison table with Standard and Reduced models columns and two rows: Analyst mode (“Q&A, exploration, reading data”) and Builder mode (“Creating & editing artifacts”) — the two mode lanes. Each cell picks a model and an effort level.
  • The model catalog: Kimi 2.6 (“Fast, low-cost reasoning” — offered only outside EU data residency), Haiku (“Fast, lightweight queries”), Sonnet (“Balanced everyday analysis”), and Opus (“Deepest reasoning”).

Below the table, Let users choose their own effort governs the in-chat model + effort picker: “When allowed, a user can raise or lower effort per chat — within their allocation. Suspended automatically once a downshift triggers.” It has an organization-wide toggle, per-role overrides (Allowed / Denied / Inherit org), and individual overrides — “Individual rules win over role and org settings.” The picker only appears once the organization’s wallet has been funded, and it disappears for everyone while a downshift is active.