Setting a Cost Ceiling per Claim, per Case, or per Workflow Run

What a ceiling means for a unit of work

A cost ceiling is a decision made while work is running, not a figure reconciled afterward. For each claim, case, or workflow run, it states how much model and tool activity the work is permitted to consume, and what happens when that allowance is used up. A billing report tells you what a run consumed. A ceiling determines whether the next call is allowed to happen.

The first design decision is the unit. A claim, a case, and a workflow run are business or application concepts, and a single claim may involve several runs. Decide which one the ceiling attaches to, and make sure the calling application can name it. Provider-level quotas are typically scoped to an account, key, or project, so on their own they cannot say which claim consumed what, and they cannot stop one run while leaving others untouched.

The second decision is the failure you are bounding. Retry loops, an agent that fans out into many sub-calls, and a tool invoked repeatedly with slightly different inputs all produce unbounded activity inside a single unit of work. The ceiling should be written against those behaviors, not only against an average expected cost.

Choosing the metrics that express the ceiling

No single metric describes a ceiling well. Tokens bound size, call counts bound loops, and rate bounds speed. Most teams combine two or three. The useful question for each metric is whether it can be judged at a single interaction or only by accumulating across a run, because that determines where it can be enforced.

• Input tokens: Checkable per interaction against a cap on prompt size. Catches runaway context growth. A per-call cap does not stop many moderate calls.
• Output tokens: Checkable per interaction as a maximum completion length. Limits verbose or repetitive generation, but a tight cap can truncate legitimate output.
• Model calls: A count across the run. Directly bounds loops and fan-out, but needs a counter that persists across interactions.
• Tool calls: Can be judged per call by tool type and parameters, and counted across the run. Useful for tools with side effects or external cost.
• Retries: A count of repeated attempts for the same step. Bounds retry storms, but the application must define what counts as the same step.
• Request rate and concurrency: Evaluated over a time window. Limits bursts and parallel fan-out, but does not cap the total for a run that proceeds slowly.

Mapping metrics to enforcement actions

Each threshold needs an action, and the actions should escalate in severity. A common pattern sets a soft threshold, at which the interaction is still allowed but is slowed or flagged, and a hard threshold, at which it is stopped or sent to a person. Write both into policy so the behavior at the limit is a design choice, not an incident response.

Interaction-level enforcement covers the checks that can be made on one call: prompt and completion size, which tool is being invoked and with what parameters, and request rate within a window. A per-unit ceiling is approximated by deriving per-interaction limits from it. If a run is allowed 20 model calls and 200,000 tokens, per-call caps and rate limits keep any single interaction and any short burst within a fraction of that total.

• Allow: The interaction is within all limits and proceeds. The decision is still recorded.
• Rate limit: Calls are slowed or queued when a burst or concurrency threshold is crossed. Suited to fan-out and retry storms.
• Block: The interaction or tool call is refused when a hard limit applies, such as a disallowed tool or an oversized request.
• Escalate for human approval: The call is held until a named approver decides. Use it for high-consequence tool calls or when the application reports that a run has reached its spend threshold.

What the calling application must track

The boundary needs to be stated plainly. Enforcement in the execution path sees individual interactions and tool calls. It does not, by itself, know that fifteen separate calls belong to one claim, and it does not provide transaction-level governance across tasks or agents. The cumulative part of a per-unit ceiling therefore belongs to the calling application.

In practice the application owns four things. It assigns the claim, case, or run identifier when work begins. It attaches that identifier to every model and tool call it makes, so each interaction can be tied to the unit of work afterward. It keeps running totals of calls, tokens, retries, and tool invocations for that identifier. And it decides what to do when a total approaches the ceiling: stop issuing calls, switch to a cheaper path, or request human approval before continuing.

This split has a failure mode worth designing against. If the application's counter is lost, reset by a restart, or never updated on a failed call, the cumulative ceiling silently stops applying. Keep counters in durable storage, count attempts and not only successes, and keep per-interaction limits in place as a backstop that does not depend on application state.

Evidence that the ceiling was in force

A reviewer asking whether a limit existed will want more than a configuration screenshot. Specify the evidence up front, in four parts.

First, the policy itself: the unit of work, the metrics, the thresholds, the action at each threshold, and who may approve an escalation, with a version and effective date. Second, a record of each enforcement decision at the interaction or tool-call level, showing what was evaluated, which limit applied, and whether the call was allowed, rate limited, blocked, or escalated. Third, the application's own record of the identifier and running totals, which joins those decisions to a claim, case, or run. Fourth, for escalations, the approver, the decision, and the time.

Keep the ownership of each part clear. Interaction-level decisions come from enforcement. The correlation to a business unit of work comes from the application. Retention and residency of these records should be set deliberately, since a ceiling that cannot be shown to have been applied years later offers limited assurance.

How execution-path enforcement supports the pattern

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers. Limits are enforced at runtime, not reviewed after the fact: an interaction or tool call can be allowed, rate limited, blocked, or escalated for human approval before it proceeds. Its scope is individual interactions and tool calls. It does not provide business transaction identity or end-to-end tracing of agentic workflows, so the per-claim or per-run identifier and cumulative counts remain with the calling application, as described above.

Each enforcement decision produces audit-ready evidence, mapped to frameworks including NAIC, NYDFS, the EU AI Act, and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency. For a platform team, that means the interaction-level half of the ceiling and its decision records come from one place, while the application supplies the unit-of-work context.