Viewing costs, and attributing them to something that matters
You now know how a cost is computed and what stops it computing. This lesson is about reading it, and it is deliberately UI shaped, because Monitor is the most interface heavy domain on the exam and several items expect you to actually go and look.
Three surfaces, three questions
The trace detail view shows cost per run, beside tokens and latency. This is the “where inside this invocation did the money go” screen, and it is where you discover that ninety percent of a trace’s spend is one summarisation step nobody thought about.
The runs table carries cost as a column across whatever population you filtered to. Sort by it and you have your expensive runs. Filter alongside it and you have the thing they share.
Project dashboards aggregate cost over a time range. That is the reporting surface and the one you point at when somebody asks whether the number is moving.
The investigation always runs downward through those, and the report always runs upward.
The root run is a rollup
A chain run that orchestrates three model calls has no tokens of its own. The figure on it is the sum of the priced runs beneath it.
That has one consequence worth internalising: an unpriced run in the middle of a trace makes the total quietly too low, not obviously broken. There is no error, no warning, and no gap in the tree. If a total looks cheaper than you expected, check whether every llm run underneath it actually carries a price before you congratulate yourself on the optimisation.
Attribution is a metadata problem, not a cost problem
Every genuinely useful cost question is a breakdown question. What does this customer cost. What does this feature cost. Did the new model version cost more per conversation than the old one.
None of those are answerable from a cost number. They are answerable from a cost number grouped by a field, and you can only group by a field somebody attached at trace time.
What is structural and what is durable
The exact column names, panel positions and chart labels move between LangSmith releases, so treat the layout above as a structural description rather than a set of memorised labels. What is durable is the shape: per run detail, filterable table, aggregated dashboard, and one identifier vocabulary threading through all three.
Try it yourself
Where a trace's total cost comes from
A trace has one root chain run, two tool runs, and three llm runs. The root run shows a cost. The root run never called a model itself.
Show answer
Correct answer: A — It is a rollup, the sum of the costs of the priced descendant runs beneath it
Cost is computed per run where the three conditions hold, and the root shows the rollup. The estimate answer is the plausible one, because a project default rate sounds like a sensible product decision and other tools do exactly that, but LangSmith prices each run from its own model identity rather than from a project setting. That is precisely why one unpriced model in the middle of a trace produces a total that is quietly too low rather than an error.
The three surfaces cost shows up on
This is a navigation card rather than a facts card. Knowing which screen answers which question is worth more on the day than any single number.
Name the three surfaces where cost appears in LangSmith, and say what question each one is the right tool for.
Reveal answer
One, the trace detail view, which shows cost per run alongside tokens and latency. That answers "where inside this one invocation did the money go". Two, the runs table, where cost is a column you can sort and filter across a filtered population. That answers "which runs are expensive, and what do they have in common". Three, project dashboards and monitoring charts, which aggregate cost over a time range. That answers "what is this app costing me, and is the number moving". You go downward through those three when investigating and upward when reporting.
Which customer is costing you money
Finance asks what your three largest enterprise customers each cost to serve last month. Traces exist for the whole period and every run is correctly priced.
Show answer
Correct answer: C — Filter or group the runs by a customer identifier in metadata, if one was attached at trace time
Cost attribution is a filtering problem, and you can only filter on what somebody attached at trace time. The Insights answer is the sharp distractor because Insights does produce categories with counts, which feels like a breakdown, but it clusters on the semantic content of traces rather than on cost, and it is capped and sampled. The uncomfortable part of this question is the conditional: if nobody attached a customer field, the answer is that last month is unattributable and you fix it going forward.
Two minutes, docs open, find custom model pricing
A self hosted model shows tokens and no cost. You have already confirmed ls_provider and ls_model_name are present and spelled correctly. You need the page that tells you how to add a price for it.
Show answer
Correct answer: D — The LangSmith administration and settings docs, under model pricing configuration
A custom price is a workspace configuration, not a code change, so it lives in the settings and administration pages rather than in any SDK reference. The usage_metadata option is the tempting one because token reporting is genuinely an SDK concern and you have just been reading about it, but you have already established tokens are arriving. Recognising which condition you have ruled out tells you which section of the docs to open, and that is the whole skill in an open book exam.
Get to a cost number in thirty seconds
You get a provisioned LangSmith org shortly before the exam, and smith.langchain.com stays open during it. Rehearse the route, not the screenshot. Offline, write the route down as a sequence of screens and check it against the real thing when you next have signal.
From the org home you can reach a single run's cost, then the same project's aggregate cost over a chosen time range, without guessing or backtracking. If a question asks where you would find something, going and finding it beats remembering it.