Tracking costs, the three conditions that must all hold
Cost in LangSmith is an AND of three separate things that arrive by three separate mechanisms. Miss any one and you get an empty cell: not a zero, not a warning, not a partial number.
That silence is the whole reason this lesson exists. A system that fails loudly teaches you to debug it. A system that fails blank teaches you to guess.
The three conditions
One: token counts. The run must carry usage_metadata with actual token counts. No tokens, nothing to multiply.
Two: model identity in metadata. The run must carry ls_provider and ls_model_name. This is how LangSmith knows which price to look up. Note the ls_ prefix, because guessing provider and model is the most natural wrong guess in this entire domain.
Three: a matching pricing entry. There must be an entry in the model pricing map that matches by regex against the model name and is active for the run’s date.
Why it is built as three things and not one
Because none of the three can be inferred from the others, and that is not an accident of implementation.
Token counts come from the provider’s response, so they are the provider’s truth. Model identity comes from your instrumentation, and it has to, because the same physical model reached through two different providers costs two different amounts. Pricing comes from a separately maintained map, because prices change on dates and a run from March must be priced at March’s rate.
Fuse any two of those and you break one of those properties. The three way split is what buys you correct historical spend.
Debugging in order
Look at the run. Are there token counts? If not, your instrumentation is not reporting usage and nothing downstream can work.
If yes, look at metadata for ls_provider and ls_model_name. Missing or misspelled is the most common real world cause, and misspelled is worse than missing, because it looks correct.
If both are present and right, the pricing map has no active matching entry for that name at that date. Self hosted and custom models land here constantly, and the fix is a custom pricing entry rather than anything in your code.
Try it yourself
The three part cost checklist
The single most useful card in this module. It is a checklist, so learn it in order, because you will debug it in order.
LangSmith is showing no cost for your runs. Name the three separate conditions that must all hold for a cost to be computed, and say what you see when only two of them hold.
Reveal answer
One, the run carries token counts in usage_metadata. Two, the run carries ls_provider and ls_model_name in its metadata. Three, there is a matching entry in the model pricing map, matched by regex against the model name and active for the run's date. All three are required together, as an AND. If any single one is missing you get no cost at all: not a partial figure, not a zero meaning free, just an empty cell. The failure is silent and gives no hint about which condition broke, which is exactly why you walk it as a checklist rather than staring at it.
The two metadata keys cost needs
Precisely which metadata keys does cost attribution require? The prefix matters.
Show answer
Correct answer: D — ls_provider and ls_model_name
The keys are ls_provider and ls_model_name, with the ls_ prefix. The bare provider and model option is an excellent trap, because that is what almost every other tool in this space calls them and it is exactly what you would guess having never looked. thread_id and session_id are the threading keys from module 0 and have nothing to do with cost, but they read as familiar and correct under time pressure.
Tokens are visible, cost is blank
Your runs clearly show input and output token counts in the UI. The cost column is empty. Diagnose it.
Show answer
Correct answer: A — ls_provider or ls_model_name is missing, or no active pricing entry matches that model and date
Visible tokens prove condition one is satisfied, so the fault is in condition two or three. The plan answer is the tempting distractor because LangSmith genuinely does gate features by plan, Insights is Plus and Enterprise only, so "it must be my plan" is a reasonable reflex that happens to be wrong here. There is no delay based cost computation, so the 24 hour answer is invented outright.
Which failure is hardest to spot
Three teams each have a cost problem. One sent no ls_model_name at all. One sent ls_model_name misspelled. One serves a self hosted model with a name in nobody's pricing map. Which is hardest to diagnose by looking at the run?
Show answer
Correct answer: C — The misspelled key, because the pane shows a plausible looking value that quietly matches nothing
A misspelled value is present, populated, and wrong, so your eye slides over it while the regex match silently fails. The last option is the genuinely tempting one, because the symptom really is identical in all three cases, an empty cost cell. The symptom being identical is not the same as the diagnosis being equally hard: a missing key is visibly absent and a self hosted model is a known category, while a typo is camouflaged. Self hosted models are also perfectly priceable with a custom entry.
Break one condition on paper
No org required. Write this out in a scratch file and reason it through; the point is the ordering of the checks, not the tooling.
- Write down a fake run as three bullet points, one per condition, all satisfied.
- Cross out condition one. Write what the cost column shows, and what the token columns show.
- Restore it, cross out condition two instead. Write what the cost column shows now, and note that the token columns are unchanged.
- Restore it, cross out condition three. Write down the symptom again, then write the one sentence that distinguishes this case from the previous one using only what is visible on the run.