Settings

Settings is the Manage entry point for organization and user configuration.

In the App IA, this page lives under Account.

It is not one single resource. It is the shell that groups the configuration pages for general org settings, members, workspaces, secrets, chat models, and billing.

How settings maps to the app

Section	Route role in the app	Primary operator question	Deep-dive page
General	org identity and top-level configuration	how should this organization appear and who can manage it?	Organizations
Members	membership and role management	who belongs here and what can they manage?	Organizations
Workspaces	workspace creation and sharing	where should work happen and who gets access?	Workspaces
Secrets	personal provider credentials	which keys do I want available for my runs and evaluations?	Secrets
Chat Models	chat UI model availability	which inference models should appear in my assistant picker?	Chat Models
Billing	SaaS credits and payment controls	how do we pay for usage and keep workloads running?	Credits

What lives in settings

Section	What it controls
General	organization display name, description, URL key visibility, and max-member visibility
Members	organization membership, invitations, and permission management
Workspaces	workspace creation, sharing, and per-workspace access management
Secrets	provider API keys and custom environment variables
Chat Models	which models appear in your chat interface and whether required keys are present
Billing	credits, auto-refill, transactions, and usage in SaaS mode

The settings shell also surfaces an invite banner when an organization appears to be solo and the current user can manage members. In the app, that banner uses the Invite Team action to send you directly into membership management.

Common operator tasks

If you need to…	Go to	Why
rename the org or review org-level limits	General	this is the top-level org metadata surface
invite coworkers and adjust roles	Members	org membership and permission changes happen here
create a shared delivery area for a team or engagement	Workspaces	workspace creation and access live here
add your own provider key for future runs	Secrets	secrets are user-owned even though they are managed from settings
decide which chat models appear in your chat UI	Chat Models	this is a user preference surface, not the artifact registry
configure payment methods, auto-refill, or usage guardrails	Billing	this is the SaaS billing and credits surface

Important distinctions

Settings versus platform resources

Settings is the place where operators configure the platform. It is not where they execute work.

• Use registry pages such as Capabilities, Datasets, and Models when you are browsing shared artifacts.
• Use execution pages such as Evaluations or Runtimes when you are running work.
• Use settings when you are changing who can use the platform, what credentials exist, or what defaults appear in the UI.

Chat models versus model artifacts

Chat Models inside settings is about which inference models appear in your chat UI and whether the required provider keys are configured.

That is different from Models, which is the registry for stored versioned model artifacts.

Note

If a user says “models” ambiguously, clarify whether they mean chat inference models or stored model artifacts.

Section-by-section workflows

General

Use General when you are changing organization identity and operator-facing defaults.

• update the display name and descriptive metadata people see in the app
• review the stable organization key used in URLs and API paths
• review organization-level limits that affect collaboration and membership growth
• note that the current app exposes the key for reference, but does not let you rename it here
• treat this as the top-level org control surface, not a place to manage projects or runtime state

Members

Use Members when you are changing who belongs to the organization and what they can do.

• invite teammates by email and manage pending invitations
• change organization roles when responsibilities change
• remove members who should no longer have access
• expect the UI to encourage invites when the org looks like a solo workspace and the current user can manage membership

Workspaces

Use Workspaces when you are deciding where work should live and who can collaborate on it.

• create a workspace for a client, team, or engagement
• grant direct user access or share through teams
• use default workspaces for private individual work and shared workspaces for collaborative work
• in SaaS mode, expect plan checks around workspace creation and updates

Secrets

Use Secrets when you are storing credentials that you personally want to inject into runs.

• add provider keys with canonical preset names such as OPENAI_API_KEY
• rotate or delete credentials without exposing plaintext values in API responses
• remember that secrets remain user-owned, even though settings is where they are managed
• choose secret_ids when you start a runtime or create an evaluation because settings does not automatically inject every saved secret everywhere

Chat Models

Use Chat Models when you are curating the model picker in the interactive assistant UI.

• enable or disable which chat models appear for you in the assistant picker
• verify that the required provider keys are present for the selected models
• treat this as a user preference surface backed by saved model preferences, not as an org-wide registry or policy control
• keep this separate from Models, which stores versioned model artifacts for reuse and comparison

Billing

Use Billing when you are managing credits-backed usage in SaaS deployments.

• review the current balance, warning state, and transaction history
• configure auto-refill thresholds and monthly caps
• inspect saved payment method details
• follow the Enterprise link when the deployment uses invoicing or custom reporting instead of credits-backed self-serve billing

Permissions and deployment behavior

• Organization owners can edit general settings and membership-related configuration.
• Secrets remain user-owned even though the settings shell is where they are managed.
• Billing only appears when credits are enabled for the deployment.
• Enterprise messaging is surfaced from the billing section because billing behavior differs by deployment mode.

Permission guide

Section	Scope	Safe default assumption
General	organization	org-admin action
Members	organization	org-admin action with invite and role management
Workspaces	organization plus workspace access	org-level creation plus workspace-sharing controls
Secrets	user	each user manages their own credentials
Chat Models	user	treat as a per-user model-picker preference, not a registry write
Billing	organization, SaaS only	owner-level billing action

SaaS versus Enterprise

Deployment mode	What to expect in settings
SaaS	Billing is visible, credits are active, and auto-refill or payment-method workflows may appear
Enterprise	credits-backed billing is disabled and the billing surface does not act as the primary cost-control plane

What agents should assume

• Settings is a grouping surface, not one API object.
• Different sections have different permission checks.
• Chat Models and registry Models are separate concepts.
• Chat Models is user-scoped even though it is presented inside the settings shell.
• Billing visibility depends on deployment configuration, so do not assume it exists everywhere.
• Settings tells you where configuration is managed, but execution-time choices such as secret_ids still happen when a runtime or evaluation is created.