Skip to main content
Workspace-level configuration covers the things that apply to the entire workspace and every project inside it: the workspace profile, default LLM models, integrations, team membership, the Workspace Library, and context parameter definitions. Project-specific configuration (workflows, agents, repositories, project vault, project permissions) lives inside each project under Project Settings. This page covers the workspace Settings page. For review and audit workflows, see Audit Trail to understand workspace activity, filtering, event details, and redaction behavior.

​
Settings

The Settings page (Account → Settings in the sidebar) contains the workspace profile and the workspace-wide defaults that projects inherit. All fields are saved together when you click Save Changes.

Open the workspace

From the global workspace switcher, choose the workspace you want to configure.

Open Settings

Click Settings in the workspace sidebar. The current workspace settings are displayed.

Update settings

Update any of the fields. See the sections below for details on each field.

Save changes

Click Save Changes. A confirmation message appears when your changes are saved successfully.

​
Workspace Name

The workspace name identifies your workspace throughout the application. It appears in workspace switchers, breadcrumbs, and other UI elements.
  • Required: Yes

​
Timezone

The timezone selector determines when scheduled workflows execute. The field displays a curated list of major world timezones, sorted by UTC offset and showing current offset information (e.g., “(UTC-8) America Los Angeles (PST)”).
  • Default: UTC
  • Description: Timezone used for scheduled workflows. All workflows will run according to this timezone.
The timezone options automatically account for daylight saving time changes and are sorted from west to east by UTC offset.

​
Default LLM Model

The Default LLM Model selector sets the main workspace default. Workflows and agents inherit it when their higher-priority model settings use the default model placeholder.
  • Default: Falls back to the system default if not set
  • Description: Default model used by agents in this workspace when no other model is specified
The selector displays active models from LLM Models. Inactive models remain visible on the LLM Models management page, but they do not appear in the Default LLM Model picker. For steps that use the Overcut engine, model resolution can continue from this setting to the system default. The Claude engine has a separate workspace default and cannot use a system model as a fallback.
Leave workflow and agent model pickers at their default model placeholder when you want them to inherit workspace settings. A specific selection overrides the applicable workspace default.

​
How existing vs. new workflows behave

  • Existing workflows keep their current model selections. Steps that use the default model placeholder inherit the saved workspace value on their next execution.
  • New workflows and newly created agents start with the default model placeholder. For the Overcut engine, an execution can use the system default until you set a main workspace default.
  • No retroactive edits occur. Changing a workspace default does not rewrite workflow or agent definitions.

​
Default Claude Engine Model

The Default Claude Engine Model selector sets a workspace default only for steps that use the Claude engine. It does not change Default LLM Model or the default used by the Overcut engine. The selector includes active Anthropic and AWS Bedrock models from the current workspace. You can clear the selection. When it is clear, a Claude-engine step can continue to the main Default LLM Model, but only if that model is compatible with the Claude engine. See LLM Models for supported providers, credential options, and engine compatibility.

​
Model resolution order

A Claude-engine step checks these sources in order and uses the first configured model: A default model placeholder is skipped so the next source can provide a model. The first resolved model must be active, owned by the current workspace, non-system, and provided by Anthropic or AWS Bedrock. If it does not meet these requirements, or if no model is configured, the step fails. The Claude engine does not continue to a system default. This differs from the Overcut engine cascade, which can use its system default after the main workspace default. See LLM Models for the Overcut engine order.

​
Auto-Improve Workflows

The Auto-Improve Workflows toggle controls whether workflows in the workspace can use self-improvement features. Turn it on when you want workflow dashboards to expose the Self-Improvement panel and let each workflow run retrospective analysis.
  • Description: Enables automatic retrospective analysis of workflow runs to generate improvement suggestions
This workspace setting is a prerequisite for workflow-level self-improvement. If the toggle is off, workflow dashboards show a prompt directing you to enable it here first. Once enabled, each workflow dashboard exposes a Self-Improvement panel where you configure retrospective cadence, sample size, and view retrospective activity.
See Workflow Self-Improvement for the full walkthrough on configuring cadence, sample size, validation limits, and viewing retrospective results.

​
Where credentials live

There is no workspace-wide secret store. Credentials live in three places, by what they are for:
  • LLM provider keys (Anthropic, AWS Bedrock, OpenAI, and others) are configured on each model under LLM Models. See LLM Models.
  • Secrets that several projects share, such as a Sentry token used by a shared MCP server, live in the Library Vault of the Workspace Library.
  • Secrets used by one project live in that project’s Project Vault.
If LLM Models lists a Claude (migrated) Anthropic model, Overcut created it from the workspace-wide Claude API key that older workspaces stored and set it as the workspace Default Claude Engine Model. It needs no action.

​
Custom Events

Custom Events is a workspace-level surface for defining your own event types that any third-party system can fire via a public webhook URL. Each event has a unique URL, an optional Bearer or custom-header secret, and an allowlist controlling which projects can react to it. Open it from the workspace sidebar under Custom Events. The page lists every event defined in the workspace, with filters for category, scope, and search. Four permissions, all workspace-scoped and granted to workspace admins by default: Holding customEvent.edit lets a user add any project in the workspace to an event’s allowlist. Project admins cannot add their own project to an event’s allowlist on their own. For setup, auth modes, and recipes for common SDLC tools, see Custom Events (Integrations). For the dispatcher contract, see the Custom Events API reference.