Cost

Start with the Cost posture verdict: total spend, spend per successful run, outcome coverage, failed/unknown spend, and trace cost coverage. Open Workflows for cost per confirmed successful outcome (CPSO).

Where the spend goes (0:53, narrated)

What you see

/cost is a single route with local tabs — Overview, Workflows, Segments, Coverage & Rates, Infra and Budgets, plus Billed spend when it is available — switched with a ?tab= parameter.

Above them, the Cost & Budget section’s tabs open Cost findings and Infra. The header has Share / PDF, which shares the month’s Executive summary, and Ask Morse, which starts with Ask about this page (see Ask Morse).

Overview

A “Cost posture” verdict strip — total spend, spend per successful run (spend on successful runs ÷ successful runs; not CPSO), outcome coverage, failed/unknown spend, and trace cost coverage — followed by a plain-language “what this is telling you” panel and Top actions by est. dollars: up to five cost actions from your one ranked list — enable prompt caching for a repeated prompt prefix (list-price estimate), or remove unused tool definitions. Each shows its estimated dollars per month, why it fired and a link to the evidence, with Accept and Dismiss. Dismissing an action hides it everywhere (this page, the weekly brief and the agent page) for 30 days. The same actions, plus “fix the top failing error” actions, appear on each agent’s page.

Workflows

Cost per confirmed outcome (CPSO) by workflow, plus an org-wide figure. This is the one canonical definition used everywhere in Morse — the API, the brief, Ask Morse and the MCP tools:

Numerator: all spend of the runs in scope — failed retries and runs with no recorded outcome included.
Unit: the business record (ticket, order, PR) when runs carry a record key, otherwise the run. A ticket handled across five runs is one outcome. The figure always states its unit and how much of it is matched to your records (runs that carry a record key).
Confirmed: only outcomes set by your code, a confirmed classifier, a webhook or a record outcome count. Eval-judged and inferred successes, and runs whose only label is their run status, are listed but not counted.
Window: an outcome belongs to the window its first run started in. A unit whose latest run started within its finality window is “too recent to count” and excluded from both spend and confirmed successes in CPSO. The default finality window is 24 hours.
Thin evidence: with fewer than five confirmed outcomes the figure is ”—” with the next step to take, never a guess or $0.
Workflow: rows group by the workflow you set in trace metadata (for example set_context(workflow="refunds")). Runs without one group under their agent.
Finality per agent: an agent whose outcomes take days to arrive (refunds, tickets) can set a longer finality window, up to 7 days.
Coverage shifts: if the share of runs matched to your records moved more than 15 points since the previous period, the figure is flagged, because the change partly reflects instrumentation.

Under the figure, a basis line states its unit, what was counted and what was left out, for example “Counted per record (ticket, order, PR) · $412.80 over 96 confirmed outcomes · left out: 14 unconfirmed successes, 6 maturing (under 24 h), 3 unpriced runs”. The unit reads Counted per record, Counted per run (no record key on these runs), or per record where a run has one and per run otherwise. Cost per outcome and spend per successful run are different prices: one is per business record with only confirmed outcomes counted, the other per run.

CPSO is correlational: it describes what confirmed outcomes cost, not savings or causes.

An outcome-confirmation prompt sits above the widget for traces still waiting on a labeled result.

Per-agent outcome finality

Agent.outcome_finality_hours sets how long CPSO waits after a unit’s latest run starts before including that unit. It leaves time for outcomes to arrive; it does not itself confirm success. For a record handled by multiple agents, CPSO uses the first run’s agent setting.

Set it with PATCH /api/v1/agents/{id}/outcome-finality, sending {"hours": 72} for a 72-hour window. The allowed range is 1–168 hours (7 days). Send {"hours": null} to clear the override and restore the 24-hour default. The response contains agent_id and hours; hours is null when the override is cleared. Use a full-access personal API key belonging to an owner, admin, or member of the agent’s organization. Read-only keys and viewers cannot change finality.

Evidence ETA

When there is not enough evidence for a verdict, the Evidence ETA panel shows what still needs to arrive: labels, more runs, or baseline history. When available, Already ruled out states the bound the current evidence supports.

The date is an estimate range, labeled “Estimate: likely between … and …”, based on recent run or label arrivals. If the app cannot project a date, it shows Can’t estimate a date yet and the reason. With no outcome labels arriving, more traffic alone does not resolve a label-dependent verdict.

The panel links to the next action, such as linking a record key, sending outcomes by key, or viewing runs. When the total is greater than zero, its coverage bar shows N of M runs labeled. For CPSO, those counts represent confirmed successful units and total eligible units, which can be records rather than individual runs.

Segments

Cost by any custom dimension you already tag — customer, feature, team, plan — behind a pill-strip key selector and a breakdown table of cost, coverage, and trace count per value.

Segments are empty until your code calls set_context() once; the empty state prints the exact line to add rather than hiding the capability.

Coverage & Rates

Two trust signals, kept on separate surfaces on purpose: catalog pricing coverage (the share of your org’s cost-bearing models with a known rate) and a pricing provenance panel showing which models are priced, where each rate came from, and how fresh it is.

Trace cost coverage vs. catalog pricing coverage

This tab’s catalog score is a different number from the “Trace cost coverage” stat on the Overview verdict strip — the Overview figure is how much of one trace’s LLM spend is priced; this tab’s figure is how much of your whole model catalog has a known rate. Neither is shown as a fabricated 0% when there is nothing to divide by — both resolve to an honest empty state instead.

Infra

Fleet infrastructure cost — an “Exact cloud bill” card when provider-billed data exists, successful/failed/idle spend split, an Infra cost per successful run stat (not CPSO), and a per-resource breakdown — with its own 24h/3d/7d window toggle.

Billed spend

Upload a provider bill export and Morse compares what your traces say you spent with what you were billed. All spend puts traced, billed and untraced spend in one view.

Coding agents

Coding agents are agents too, but they don’t send traces. Upload one of these exports and the Coding agents section shows what they cost:

Claude Code usage: cost per user, per day and per model.
Cursor usage: usage events per user, plus the seat fee.
GitHub Copilot seats: seat assignments and the date each seat was last active.

Seat fees are spread evenly across the days of the month: monthly price ÷ days in the month. The list price is used unless you enter a seat price when you upload. The section shows total spend, cost per active user, spend by tool (usage vs seats) and the top users by cost.

A seat is idle when it was paid for on 14 or more days of the window and had no activity. Any idle seat raises a verdict such as “2 of 10 paid seats were idle for the last 30 days — $38/month.” Cursor’s export only lists members with activity, so idle Cursor seats can’t be detected.

This spend has no traces, so it is kept out of traced-vs-billed coverage and out of “other cloud.”

How it prices spend

Every dollar in this screen is priced through one precedence chain: provider-reported pricing first, then a catalog rate (a list price, an estimated rate from a public price list, or a rate you configured yourself), and only when neither applies is a span unpriced.

Unpriced spans are excluded from totals, never averaged in at an assumed rate — this is enforced in the cost engine, not just a UI filter: estimated costs are walled out of both total spend and CPSO’s numerator by construction.

How to use it

Select Share / PDF to send the month’s Executive summary as a PDF or a read-only link.
Switch tabs to move between the spend verdict, per-workflow CPSO, custom segments, trust signals, and infra.
Filter by time window (7/14/30d), agent, or model — the filter bar applies across tabs.
On Segments, pick a key to see cost, coverage, and trace count broken down by its values. Export downloads that breakdown as CSV or JSON.
On Coverage & Rates, check pricing provenance before trusting a number you’re about to budget against.

Before you have data

Missing or zero figures here mean “nothing measured,” never “nothing spent” — the screen never fabricates a cost from request counts times an assumed rate.

No spend yet: totals, CPSO, and coverage scores show ”—” rather than $0 or 0%.
No outcomes confirmed for a workflow: its CPSO shows ”—”, not a misleadingly low cost.
No custom metadata keys yet: Segments shows the set_context() snippet instead of an empty table.

Traces — the individual runs this screen’s spend is aggregated from.
Agents — per-agent cost, rolled up the same way.