Read where the money went and how the requests ended
The four tabs of the overview page — spend, accuracy of the estimates, models and providers — and the analytics of one flow.
3 min read
The console counts what your requests spent and how they ended in two places: the overview page, for the whole project, and the Analytics tab of each flow. This page says what each of them shows and how its numbers are counted.
The overview page
Overview is the first page of the console. It shows the project chosen in the header over one period: 7, 14 or 30 days, or the dates you set under From and To. The period holds for every tab of the page.
| Tab | What it shows |
|---|---|
| Overview | The total spend, the calls to providers, the budget still available and the number of flows that are published and not archived; the spend over time, day by day or as a running total; and how the requests of your flows ended |
| Spend | The total spend, what the cache saved and the spend that was prevented; the spend of each day; the spend broken down by model or by connection |
| Accuracy | How close the estimates came to what the calls cost: whether they lean high or low, the mean error per request, the error by day and the error of each operation |
| Models & Providers | Each model or each connection with its requests, the share that succeeded, the latency and the cost. A row opens what the model was called through, or what was called through the connection |
Until the owner of a new organization finishes the setup, it opens again each time they sign in to the console.
How the numbers are counted
Total spend is the cost of every attempt at a provider in the period, a retry included.
Saved by cache, estimated is what the requests a cache answered would have cost at their estimate. Nothing was charged for them.
Prevented spend is the estimate of the requests that were refused before a provider was called. A refused request has no cost of its own, so its estimate is counted.
Accuracy compares the hold of each call with what the ledger settled for it. Its history appears after two days of activity.
Request health compares the share of the requests that succeeded with the period of the same length just before, in percentage points.
The analytics of a flow
Open the flow, then its Analytics tab. It shows the last 24 hours, 7 days or 30 days of that flow alone.
| Part | What it shows |
|---|---|
| The four figures | The requests, the cost, the average latency with its p95, and the share of the requests answered from the cache |
| Outcomes | How many executions completed, were rejected or failed, and how many took a fallback |
| Request paths | The paths through the flow the requests took, the most frequent first: how the executions of each path ended, the nodes it went through and how many requests took it |
| Cost breakdown | How the cost divides between the models, and between the connections — each with the pool its calls went through |
| Savings | The spend that budgets and policies prevented, and what the cache saved. Both amounts are estimates |
The numbers of a flow are counted over whole hours that have closed: the hour in progress is not counted, and the hour that has just ended joins a few minutes after it closes. The cost comes after the calls are settled, so the newest hours fill in later. The p95 of the latency is read over the last 500 executions of the flow, whatever the period.
Requests and a count of Outcomes open the Executions tab with the executions they counted. A row of Request paths opens the executions that took exactly that path and ended that way, in the same period — Inspect an execution.
Where to go next
Operations, authorizations and the ledger — each operation behind the figures.
Inspect an execution — one run of a flow, node by node.
Budgets — the limits behind the available budget.
Provider pools — the connections the spend went through.