Insights

Checks on how your keys or your organization use Dispatch, what to do about each finding, and where Token Optimization is saving money

Overview and Cost Reporting tell you what Dispatch is costing. Insights tells you what's worth doing about it. Dispatch runs a set of checks over the last 30 days of traffic, such as keys with no spending cap, keys nobody uses, spend with no tag, or agents resending large amounts of command output. It then lists what needs doing, most urgent first, with the next step for each and a button to the page that fixes it.

Insights answers for whoever is reading it. A Dispatch Admin sees checks across the whole organization. A Dispatch User sees checks on the keys they own.

A to-do list that pays for itself: Insights flags that your developers' agents are resending test runs and diffs on every turn, names the keys doing it, and estimates what that text cost to send. One switch in Guardrails turns on Token Optimization, and the coverage map on this page shows those keys' days filling in as tokens come off.

How Insights Differs by Role

	Dispatch User	Dispatch Admin
Page description	"Checks on how your keys use Dispatch over the last 30 days"	"Checks on how the organization uses Dispatch over the last 30 days"
Checks run	Checks about your own keys	Every check, including organization-wide ones
For the record tab	—	✓
Token Optimization coverage	Your keys	Every key, with an Open guardrails button

Organization-wide checks, such as the organization's spend limit or spend concentration, aren't run for a Dispatch User at all. They're about the organization rather than anyone's own keys, and only a Dispatch Admin can act on them.

Running the Checks

The checks run when you open the page. The header shows when they were last run, such as "Checked 3 minutes ago". Click Run again to rerun them, for example after changing a setting.

The Summary

Four tiles sit across the top.

Tile	What it shows
Needs attention	Findings to act on. Click to show only these, and click again to show everything
Worth reviewing	Findings to look at when you can. Click to filter the same way
Could save	The estimated total across findings that carry a dollar figure, over the window. Only findings that could be priced are counted, and it shows a dash when nothing could be
Checks passed	How many checks passed out of how many ran, and how many couldn't be checked yet

Below the tiles, category chips (All, then a chip per category, such as Spending controls or Wasted spend) narrow the list to one category. Each chip shows how many of that category's findings are on the to-do list.

The To-Do List

To do lists every finding that needs action, sorted by severity and then by potential saving, so the most urgent finding is at the top and opens automatically. Each row shows:

• The finding, in a sentence, such as "Some keys are not being used"

• Its category and severity, and how many people or keys are affected

• The Potential saving on the right, where one could be priced

Severity is always written out as well as shown in colour: Needs attention, Worth reviewing or Informational.

Click a row to open it.

1

Read what was found A short explanation of the finding, with the figures behind it.

2

Read what to do What to do gives the next step.

3

See who's affected The people or keys behind the finding, with a note on each. The first five are shown, and Show all lists the rest. Where a name is a link, click it to open that key or person on the API Keys page.

4

Act on it Use the button to the page that fixes it, or Copy for your developers to copy the finding, the next step and the affected list as plain text for a chat or ticket.

Where the fix belongs in your developers' code, such as trimming long prompts, there's no page button, and Copy for your developers covers it.

Passed and Not Yet Checked

Under the list, Passed collects the checks that found nothing wrong. Some passes are also status reports, such as which keys a setting covers, and open like a finding so you can read the list.

Could not be checked yet collects checks that couldn't run, each with the reason. These aren't passes. A check that couldn't read what it needs says "Nothing is implied either way". Often the remedy is time: some checks need a minimum amount of history before they can say anything.

The Checks

Each check has a short name, which is what you see when it passes or can't run. When it finds something, the finding is written as a sentence instead.

Spending Controls

Check	Finds	Who gets it	Button
Spending caps	Key owners who can spend without a limit	Everyone	Open API keys
Remaining allowance	Key owners close to their spending cap	Everyone	Open API keys
Requests refused by a spending limit	Requests turned away because a limit was reached	Everyone	Open API keys
Organization spend limit	No overall spend limit for the organization	Admins	Open budget
Budget pace	Budgets on course to run out at the current rate	Admins	Open budget
Unusual days	Recent days that cost far more than usual	Admins	Open Cost Reporting

Key Security

Check	Finds	Who gets it	Button
Keys returning to use	A key that had gone quiet for a long time being used again	Everyone	Open API keys

Wasted Spend

Check	Finds	Who gets it	Button
Repeated prompt text	Paying to send the same text over and over	Admins	—
Tier choice	Traffic that may be running on a dearer tier than it needs	Admins	Open Models
Requests for tiers you do not have	Requests turned away for naming a tier your organization doesn't have	Admins	Open Models
Rejected requests	Requests that couldn't be read at all	Admins	—
Abandoned answers	Answers cut off before they finished	Admins	—
Prompt size against answer size	Very long prompts for very short answers	Admins	—
Command output	Agents sending a lot of command output, such as test runs and diffs	Everyone	Open guardrails
Bulk data from tools	Tools returning large lists of records	Everyone	Open guardrails
Tool list size	Every request carrying a long list of tool descriptions	Everyone	—

The last three only appear when Dispatch has measured requests that use tools.

Unused Keys

Check	Finds	Who gets it	Button
Key owners who have stopped	Key owners with working keys who have stopped using Dispatch	Everyone	Open API keys
Unused keys	Keys that made no requests in the window	Everyone	Open API keys
Keys per owner	Key owners holding an unusual number of keys	Everyone	Open API keys
Spend concentration	Most of the organization's spend going through a single key	Admins	Open Cost Reporting

Compliance

Check	Finds	Who gets it	Button
Content policy coverage	Keys that run without a content policy	Everyone	Open guardrails
Requests blocked by a content policy	Requests a content policy refused	Everyone	Open guardrails

Cost Allocation

Check	Finds	Who gets it	Button
Tag coverage	Spend on keys with no tag	Everyone	Open API keys

Open budget and Open guardrails go to Billing & Budget and Guardrails. Open Cost Reporting opens the Spend by person, by week report. See Cost Reporting.

Token Optimization

Token Optimization shortens what your team's agents and apps send to the model, before it's sent. It covers two kinds of content:

• Command output that can be shortened without losing anything, such as a test run where every test passed, a diff, a search or a file listing

• JSON tool results, re-sent in a compact layout that keeps every value

Failures and errors are always sent in full, and file contents are never changed. Anything Dispatch can't shorten safely goes through exactly as it arrived.

Turning It On

Token Optimization is off until a Dispatch Admin turns it on. The organization's setting is the On for this organization switch on the Token Optimization card in Organization › Guardrails. Each guardrail can then Inherit organization setting, or be set to On or Off for the people under it. A change applies within a minute. See Guardrails.

The Command output and Bulk data from tools checks suggest turning it on when your keys send a lot of either. Once Token Optimization is on anywhere in the organization, the Command output check becomes a status report instead, saying "Token Optimization is on for … of … keys" and listing what each key saved.

How the Saving Is Measured

Each request's saving is priced as it happens, at what the removed tokens would have cost on the model that answered it. Where part of the prompt was served from cache, that part is priced at the cheaper cached rate. You'll find the total under Total savings and What Dispatch saved on Overview, and as Saved by Token Optimization in Cost Reporting.

Token Optimization Coverage

Below the to-do list, Token Optimization coverage shows which keys it reaches and what it did, day by day. It appears once there's traffic to show.

The header sums it up: whether it's On for every key, Off for every key or On for some of them, and once anything has been shortened, how many tokens were removed over the last 30 days and what they were worth.

Each row is one key, labelled with its owner and the key's name, and the tool that uses it where Dispatch recognizes it (for example Coding agent or App). Each square is one day:

Square	Meaning
Coloured	Tokens were removed that day. The colour shows what was shortened (Command output compression, Tool result compression or Other compression), and darker means more tokens removed
Grey	On for this key, but nothing was shortened that day
Outline only	Off for this key

Hover a square for that day's figures. On the right of each row:

• Keys it's on for show the tokens removed and what they were worth, or Nothing shortened yet, with why it's on: On, or On via guardrail '…'

• Keys it's off for show why, such as Off: organization default is off or Off: guardrail '…' turns it off, and how much command output and tool results that key sent which Token Optimization could have shortened

Keys it's on for come first, ordered by what they saved, then the rest by what they could have saved. Ten rows show at first, and Show all reveals up to 40. Any keys beyond that are counted as "quieter keys not drawn". Dispatch Admins can click Open guardrails to change the setting.

For the Record (Dispatch Admins)

The For the record tab isn't a list of things to fix. It's evidence you can forward when someone asks what your AI vendor stores or what your content policy covers.

Panel	What it shows
What we store	That Dispatch doesn't store the text of prompts or answers, doesn't store client IP addresses or anything derived from them, and keeps API keys only as a one-way digest that can't be read back
Content policy coverage	How many key owners send their requests under a content policy, each policy that's in use and what it checks for, and that matching requests are refused inside Dispatch before they're sent to any model provider
Where requests ran	A note that Dispatch doesn't record the region each request was processed in, so it doesn't report one

To control where requests may be processed, see Data Residency.

About the Dollar Figures

Every dollar figure on Insights is in the same terms as Total cost on Overview and Spend in Cost Reporting. Could save and each finding's Potential saving are estimates over the window, and for some findings, such as Command output, the figure is what that content cost to send.

Forecasts, Savings and Habits

Some related views live on other pages:

View	Where
The next 30 days, the spend forecast	Overview
What Dispatch saved, day by day	Overview
Your habits and Habits across the organization	Overview
Intelligence vs. Price, comparing tiers with well-known models	Models

Next Steps

Goal	Documentation
Turn on Token Optimization or add a content policy	Guardrails
Set spending caps and fix unused keys	API Keys
Set the organization's spend limit	Billing & Budget
Tag keys so spend can be allocated	Tags
Dig into a finding with your own breakdown	Cost Reporting
See the forecast and savings over time	Overview