Core concepts

Outcomes

Budget a unit of work, not a request, when one job is several calls.

A spend cap on a key limits a period. An outcome limits a *job*: one support reply, one document summarised, one agent run. however many calls that takes. It is the right ceiling when the thing you sell is a result rather than a token.

Define an outcome

seams outcomes add support-reply --name "Support reply" --limit 0.05

# OUTCOME        DISPLAY NAME    SPEND LIMIT USD  RUNS  SPENT USD
# support-reply  Support reply              0.05  4812      18.40

Attach a run to a call

Put the outcome on the request body. Same outcome_id across several calls is one run; a new id starts another.

cli
curl https://<app>.gw.ourseams.com/v1/chat/completions \
  -H "Authorization: Bearer ak_acme_…" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "acme/smart",
    "messages": [{ "role": "user", "content": "Draft the reply" }],
    "seams": {
      "outcome": "support-reply",
      "outcome_id": "ticket_8842"
    }
  }'

Read runs and archive

seams outcomes runs --outcome support-reply
seams outcomes rm support-reply --yes
StatusMeans
runningCalls are still being attributed to this run
doneThe job finished inside its ceiling
cappedThe ceiling was reached; further calls in this run are refused
failedThe job stopped for a reason that was not money

How it relates to the other ceilings

Three limits can apply to one call, and the tightest wins. None of them replaces the others: a balance is what a customer has, a cap is how fast they may spend it, and an outcome is how much one job may cost.

LimitScopeSet on
Available balanceEverything that end user doesThe balance
Spend capA period, per keykeys.cap
Bundle spend limitA period, per end userbundles.edit
Outcome ceilingOne runoutcomes.add

outcomes.rm archives. Runs already recorded keep pointing at the outcome that produced them, so the history of what a job used to cost stays readable.