Presets

Presets are reusable configurations that help teams standardize prompts, model preferences, and routing defaults. They are managed in the Phaseo dashboard and can be shared across a team.

Quick start

Create a preset

Open Dashboard -> Settings -> Presets and create a preset with a clear slug, such as release-summary. Add only the defaults that should be shared across callers.

Reference the preset in a request

Keep the caller focused on the user input while the preset supplies stable prompt, parameter, and routing defaults.

curl https://api.phaseo.app/v1/responses \
  -H "Authorization: Bearer $PHASEO_API_KEY" \
  -H "Content-Type: application/json" \
	  -d '{
	    "model": "@release-summary",
	    "input": "Generate a release summary for the last 24 hours."
	  }'

import Phaseo from "@phaseo/sdk";

const client = new Phaseo({ apiKey: process.env.PHASEO_API_KEY! });

const response = await client.generateResponse({
	  model: "@release-summary",
	  input: "Generate a release summary for the last 24 hours.",
});

from phaseo import Phaseo

client = Phaseo(api_key="YOUR_API_KEY")

response = client.generate_response({
	    "model": "@release-summary",
	    "input": "Generate a release summary for the last 24 hours.",
})

Check the routing result

Open the request in Gateway -> Usage to confirm which defaults were applied and which provider served it.

What a preset can include

A system prompt to prepend to every request.
Allowed models or model families.
Provider allow/ignore lists for routing preferences.
Default parameters (temperature, top_p, max_tokens, and similar settings).
Optional reasoning defaults for supported models.

Preset names are prefixed with @ to keep them easy to recognize. Invoke a preset only through the request’s model field. Phaseo does not expose a separate preset request field.

Private and workspace presets use @{slug} and resolve inside the API key’s workspace.
Public presets use @{username}/{slug} and can resolve from any workspace. For example, @octavia/release-summary.

Public publishing requires an enabled public profile and username. Public slug conflicts are scoped to that publisher, so two publishers may use the same slug without ambiguity. Usernames are globally unique. Slugs are normalised to lower case and support letters, numbers, hyphens, underscores, periods, and colons.

Versions and marketplace forks

Saving changes updates a private draft. Use Publish new version when those changes are ready; Phaseo creates an immutable numbered release while retaining every earlier version for review. Preset owners can choose how release labels are displayed:

Sequential: v1, v2, v3.
Semantic Versioning: explicit SemVer labels such as 1.2.0, 2.0.0-beta.1, or 1.4.2+build.7.
Date versioning: YYYY.MM.DD, with a numeric suffix when multiple releases are published on the same date, such as 2026.08.02.2.

Phaseo maintains a separate monotonic release number internally, so chronology, upstream comparisons, and lineage remain deterministic regardless of the selected public label format. Marketplace copies remain pinned to the exact upstream version they copied. When the publisher releases an update, the copied preset shows an update notice. Applying it updates the copy’s draft only, so the workspace owner can review and explicitly publish it without an upstream author changing production behaviour. Phaseo retains both the immediate source and the complete ancestry of every fork. Marketplace pages can therefore distinguish direct forks from all descendants, even when a preset has been copied and republished several times.

How preset merging works

When a request resolves with a preset in gateway context, the preset is applied before provider routing:

Default parameters only fill fields that are missing in the request body. They do not overwrite values already provided by the caller.
If the request already has a system message, the preset prompt is prepended. If the request uses an Anthropic-style system field, the preset prompt is prepended there instead.
Provider allow/ignore lists are applied before provider selection, so they narrow the fallback pool instead of acting as a cosmetic label.
Requests outside the preset’s allowed model list are rejected early instead of being silently rerouted.

This makes presets the main public surface for reusable request defaults and lightweight compatibility transforms without forcing every caller to duplicate the same prompt or parameter logic.

Current public preset surface

The dashboard preset flow is intentionally scoped to a stable, explicit subset of request shaping:

system prompt injection
model allowlists
provider allow/ignore routing constraints
decoding and generation defaults
reasoning defaults

If you need more complex caller-specific transforms, keep them in one application boundary layer and let presets carry the reusable team-wide defaults.

Manage presets

Create and manage presets in Dashboard -> Settings -> Presets. Use separate slugs when workflows need meaningfully different prompt, routing, or caching behavior.

When to use presets

Standardize system prompts across multiple services.
Constrain routing to approved providers for compliance.
Keep default parameters consistent across environments.
Give migration projects one durable place to carry prompt, routing, and parameter defaults while the application code stays mostly unchanged.

Overview

Models & Routing

Features

Integrations

Workspace & Access

Reliability & Operations

Platform & Research

Migration Guides

Community

Quick start

What a preset can include

Versions and marketplace forks

How preset merging works

Current public preset surface

Manage presets

When to use presets

​Quick start

​What a preset can include

​Versions and marketplace forks

​How preset merging works

​Current public preset surface

​Manage presets

​When to use presets

​Related guides

Quick start

What a preset can include

Versions and marketplace forks

How preset merging works

Current public preset surface

Manage presets

When to use presets

Related guides