Skip to main content
Every request is attributed to a project and a workload.
A project is a product surface. A workload is one stable call site within it, and it is the unit the product actually operates on: capture is toggled per workload, sampling is set per workload, and routes attach to workloads.

Declaring scope

Two optional headers. Both have defaults, so an unscoped request still works.
string
default:"default"
Project slug. Must match ^[a-z0-9-]{1,63}$: lowercase letters, digits and hyphens.
string
default:"main"
Workload name. Must match ^[a-z0-9_-]{1,63}$: lowercase letters, digits, hyphens and underscores.
Both are provisioned on first use. There is no create call to make before you can send traffic.

task is the same thing

The body field task is honoured as an alias for the workload name:
task and workload are the same idea, the name of the repeated job. The header wins when both are present, because it needs no body parse.
Use whichever fits your client. task is easier from an SDK that makes custom headers awkward; the header is easier when you already set headers per call site and do not want to touch the request body.

Reading it back

Every response echoes the scope it was attributed to:
Log both. If they come back default and main when you expected otherwise, the header was dropped or the task field was stripped by your SDK before it reached us.

Naming

The rules that matter are not the character class. Name the call site, not the implementation. draft-reply survives a prompt rewrite and a model swap. gpt4-draft-v3 does not, and when it changes you lose the history attached to it. Keep the name stable. It is the join key for captures, cost and routing. Renaming starts the history over. One workload per thing that can be correct or incorrect in one way. If you cannot say in a sentence what a right answer looks like, the workload is too broad.
Classifying an intent, fetching an account, drafting a reply and checking tone have different inputs, different failure modes and very different costs. Bundled, they average out and the cheap parts subsidise the expensive ones invisibly. Split them into one workload each, inside one project.
Splitting per tenant fragments the capture corpus, so no workload accumulates enough history to earn a cheaper route. Keep one workload and separate tenants with the standard user field.

Capture

Capture is a per-workload setting, with a sample rate. Turning it off stops the recording for that workload without touching routing or your integration.
A capture toggle can take up to 60 seconds to reach the gateway, because the setting is cached on the request path. Treat it as a recording switch, not as an instant privacy control.

What gets captured

The fields recorded per request, and what they are used for.