Flow
Before trusting the faster cost query
1Inputs swapped, matching kept
The matching step stayed the same, so number changes trace to the views.
2Strict builds
A leftover view should stop the migration, not slip through.
3Organization check on each side
Each side of a session join checks the organization.
4Every token type compared
The drift check covers all token types, though a mismatch still only warns.
The dashboard's per-tool cost chart did too much work on every row. It read every log event in the time range, dug the cost and token counts out of a text map, turned each one into a number, and only then dropped the rows it didn't need.
Two kinds of events
A tool run has a tool name but no cost. A model reply has a cost but no tool. To guess what a tool cost, the query matches each reply to the tool runs just before it in the same session. That matching was fine. The heavy part was the one big pass that fed it.
Narrow views, same matching
I already had prebuilt views of that log table with clean number columns: one for tool runs, one for model replies. Now each side of the match reads its own view, with its own time range, its own organization filter and one cheap check. The matching step didn't change, so any change in the numbers comes from the inputs.
I'd bet it's faster, since the parsing now happens once when data comes in. I didn't time it.
The migration that could skip its own job
The query needs the views to match their current definitions. The migration drops every view, then builds each one again. Each build said "if not exists". If a drop ever missed a view, that line would skip the build, report success, and leave the old view in place.
With a plain create, a leftover view makes the statement fail instead of being skipped.
Nothing shows that actually happened. I still made every build a plain create, so a leftover view stops the migration loudly.
A join with no organization filter
The example query in my developer doc joined tool runs to replies by session, with no organization filter at all. If two organizations ever shared a session ID, their spend could mix. Both sides now filter by organization, in the doc and in the real query.
A check that only warns
A SQL test compares two of the views for the last little while. I added three more token types to what it compares, since they cost different amounts. But a mismatch only prints a warning, the summary skips it, and it never checks the views against the raw events.