Skip to main content
Control which AI models your organization can use, which API keys those calls run on, and where those calls are sent. Both pages require the Admin or Security organization role (role matrix), and every change is written to the audit log.
Enterprise OAuth client configurations (Snowflake, Databricks, Okta, NetSuite, and so on) live on a separate page: OAuth Configuration.

​
Models

The Models page has three tabs: Restrictions, Presets, and Fallbacks.

​
Restrictions

Turn on Model access control with the “restrict models?” toggle, then pick an access mode:
  • Allow Only Selected — members can use only the models you check. Best for a fixed, approved set.
  • Block Selected — members can use every model except the ones you check. Best for general access with a few exclusions.
Restrictions tab with a restrict models toggle, Allow Only Selected and Block Selected access modes, and models grouped by provider with allowed and denied counts
Models are grouped by provider with running allowed and denied counts. You can select or clear a whole provider at once, or search for a specific model.
Restrictions set the organization-wide ceiling. To narrow access further, give each Custom Role its own model allow-list. A role can only allow models already permitted org-wide, and role-restricted models are hidden from the agent model picker for those members.

​
Auto (the model router)

Auto lets Gumloop pick which model runs each agent message. It does not bypass this page:
  • Restrictions and role allow-lists are enforced on the routing decision, the model Auto runs, any mid-run escalation, and fallbacks. A blocked model is skipped in favor of a permitted one.
  • If a member has no permitted model left, the run fails with a model-restricted error rather than using a disallowed model. The Fallback Model is checked against your restrictions too.
  • Auto appears in the model list like any other model, so you can block it. Agents already saved on Auto then run on a normal model with no routing.
  • Auto is never a Preset target and never a fallback — those always name a specific model.

​
Models with 30-day data retention

Every model Gumloop serves runs under Zero Data Retention except Anthropic’s Claude Fable family, where Anthropic keeps prompts and outputs for 30 days to check for misuse, then deletes them. Anthropic does not train on that data, and no other model is affected. These models are therefore off for the whole organization until an admin turns on Allow non-zero data retention models on the Models page. Enabling it is an explicit acknowledgement that Gumloop’s zero data retention commitment does not apply to those models; the acknowledgement is stored with the administrator’s name and date, and enabling and revoking are both audit-logged.
Revoking makes these models unavailable to everyone immediately. Agents set to a Claude Fable model fail until they’re switched to another model.
Even when allowed, Claude Fable models are never selected on a member’s behalf — they’re excluded from the Recommended and Smartest presets, from Auto, and from fallbacks. See Models with 30-day data retention.

​
Presets

Agents pick a model through two presets, Recommended (best balance of speed, quality, and cost) and Smartest (maximum intelligence for complex tasks). Point each preset at the model your organization prefers and members see your choice in the agent model picker instead of the Gumloop default.
Presets tab showing the Recommended and Smartest presets, each mapped to a model

​
Fallbacks

When an agent or flow references a model that is now restricted, Gumloop uses a fallback instead of failing.
Fallbacks tab with a Fallback Model selector and an Image Generation Fallback Model selector
  • Fallback Model — used when a restricted model is referenced.
  • Image Generation Fallback Model — used when the selected image model is restricted.

​
API Keys & Proxies

Add one API key per provider for the whole organization, and optionally route that provider’s calls through your own proxy. Organization keys override team and personal credentials for every member, so usage, billing, and access control stay in one place.

​
Supported providers

Every provider key earns the same BYOK credit discount, and only for the models that provider serves. A Fireworks key does not cover GPT-OSS 120B, Gemma 4 26B, or GLM-5.3-Flash, which Gumloop serves elsewhere.

​
Configure a provider

Open API Keys & Proxies and click Add credential on a provider (or Edit on one you already configured) to open the setup sheet.
Configure AI provider sheet with an Anthropic API key field, a Configure proxy toggle, a proxy URL field, and empty custom headers and model name mapping sections

Enter the API key

The key is required. It is stored encrypted and applies to every member of the organization.

Turn on Configure proxy (optional)

Enter a base URL only, such as https://gateway.example.com. It replaces the provider’s default endpoint and must be reachable from Gumloop’s infrastructure.
A proxy only takes effect when a key exists for that provider — the organization key, or the member’s own. Requests through your proxy skip Gumloop’s shared AI response cache, so every call reaches your infrastructure.

Add custom headers and model mappings (optional)

Both appear once the proxy toggle is on. See below.

Run the tests, then save

Continue to the test step and save the configuration.

​
Custom headers

Add any headers your gateway needs, such as a gateway key or a cost-attribution header. Type @ in a value (or drag a badge into it) to insert a placeholder that Gumloop substitutes per request.
Custom headers row with a header name field and a value field showing insertable placeholder badges for API key, user email, user ID, organization ID, agent ID, session ID, flow ID, and run ID, above a model name mapping row
Available placeholders: API key, User email, User ID, Organization ID, Agent ID, Session ID, Flow ID, and Run ID.
Headers Gumloop sets itself can’t be overridden, header names must be unique, and values can’t contain line breaks — the sheet flags all three before you continue.

​
Model name mapping

If your proxy uses its own model identifiers, map each Gumloop model to the name your proxy expects. Pick the model from the picker, then type the target name. The mapped name is used only on the wire; credits and usage are still tracked under the Gumloop model.

​
Test configuration

Before saving, Gumloop tests the configuration with real requests. Every active model is selected by default; narrow the list with the Models to test picker.
Test configuration step with a Models to test picker showing five selected Claude models and collapsed check rows for Agent chats, Agent tool calls, Token counting, and Workflow nodes, above a Run tests button
Each model is checked on four paths — Agent chats, Agent tool calls, Token counting, and Workflow nodes — because a gateway can serve chat completions and still not serve the others. Expand a row to see the per-model result, including the provider’s error text (with secrets stripped) when a check fails. When every check passes, the button becomes Save. If some fail, you can Retry or use Save anyways in the overflow menu — which will affect every agent and flow in the organization using that provider.

​
What happens on a run

  1. Model selection — restrictions and role allow-lists decide which models are available; a restricted reference uses the fallback model.
  2. Credential resolution — the organization key wins over team and personal credentials.
  3. Routing — the provider’s proxy URL, custom headers, and model name mapping are applied.
  4. Execution — the request goes to your proxy, or directly to the provider if none is configured.

AI Models

Available models, presets, Auto, and BYOK

Custom Roles

Per-role model allow-lists and permissions

Audit Logging

Review administrative changes