START HERE
How Pathfinder works
Two things, and only two: what happens in what order, and what every word on the site means. Everything else on this site is a screen for one of the five phases below.
End to end
Read left to right. The phases marked you wait for a person; the ones marked Pathfinder run on their own but stop at the gates named underneath.
Connect
You
Register one trust anchor per provider and prove read-only access to it.
Produces A connection, and the accounts enumerated beneath it
Discover
Stages A–CPathfinder
Read the logs, strip personal data, find the applications nobody labelled, and grade how demanding each one's work is.
Produces Applications, workloads, coverage
Gate · Curation — you name and merge what was found
Assess
You
Select a scope from what discovery already found, and set a replay budget priced from observed traffic.
Produces An assessment with an approved cap
Gate · Budget approval
Run
Stages R1–R3Pathfinder
Propose a target configuration, replay real traffic against it, judge the output, and price the result.
Produces Measured evidence, and three costed scenarios
Gate · Replay approval — the only stage that spends money
Report
You
Read what it found. Every figure carries the grade of its weakest input, and everything undetermined is declared rather than dropped.
Produces A report someone who wasn't there can check
Glossary
Every term the site uses, defined once.
Your estate
- Provider
- A system we can read from — a model provider, a gateway, an observability tool or a billing export. Connecting one does not move any traffic through us.
- Connection
- One trust anchor with one provider: the credential or role that lets us read, and the thing we enumerate accounts beneath. You register it once and reuse it.Sometimes called the connector.
- Account
- The unit a provider bills and scopes by. Each provider names it differently — a GCP project, an AWS account, an Azure subscription, a gateway workspace — and one connection may hold many.The naming here is still being settled.
- Application
- A named system of yours that calls models. Discovery finds these; they are almost never labelled in the logs, which is the whole reason a bill reads as one line.
- Workload
- One distinct model-call pattern inside an application, identified by fingerprint. An application usually has several, and they can cost wildly different amounts.
- Dataset
- The window of records a connection actually holds — a date range, a set of models, a row count. Assessments read datasets, not live systems.
The exercise
- Assessment
- The exercise you create. It covers one or more projects, carries a single approved budget across all of them, and belongs to a team.
- Project
- A scoped unit inside an assessment: which accounts, applications and workloads to look at. The money and the governance sit one level up, on the assessment.
- Run configuration
- A schedule attached to an assessment — daily, weekly, monthly or on demand. It is what turns a one-off exercise into a periodic one.
- Run
- One execution of a run configuration, on one date. Runs are kept so you can compare them; a later run does not overwrite an earlier one.
- Snapshot
- The pinned version of a connection's data that an assessment read. It is why a report does not drift when discovery runs again.
- Replay
- Re-running a sample of your real traffic against a proposed configuration and judging the output against the original. It is the only step that produces measured evidence, and the only one that spends money.
How we know
- Measured
- We ran it and observed the result. Only replay produces this.
- Logged
- Your systems recorded it and we read it. Token counts are logged.
- Modelled
- Computed from measured or logged inputs through a stated formula. Cost is modelled — tokens against a price list.
- Assumed
- A default, used because nothing better existed. Assumed figures are labelled everywhere they appear.
- Coverage
- The share of spend we could actually read and attribute. Reported per connection and rolled up spend-weighted — never quietly averaged.
- Unattributed
- Spend we can see on the bill but cannot tie to an owner. Declared as its own figure rather than folded into a percentage.
- Unread
- Spend sitting in accounts nothing is connected to. It appears in no total on the dashboard, and is stated separately so the gap is visible.
What we can read from
Access is read-only in every case. Nothing here can write to your cloud, and no traffic is routed through us.
Model providers
- GV
Google Vertex AI
Request logs and model calls from a GCP project
- AF
Azure AI Foundry
Deployment logs and token usage from an Azure subscription
- BR
AWS Bedrock
Invocation logs from CloudWatch and S3 delivery
- OA
OpenAI
Usage and cost from the organisation usage API
- AN
Anthropicbeta
Usage and cost from the workspace admin API
- DB
Databricksrequestable
Model serving endpoints and inference tables
Gateways & routers
- LL
LiteLLM
Proxy request logs with per-key and per-team tags
- OR
OpenRouter
Generation history across routed upstream models
- PK
Portkeybeta
Gateway traces, retries and fallback attributions
Observability
- LF
Langfuse
Traces that link multi-step agent runs into one unit
- HC
Helicone
Per-request cost, model mix and user attribution
- DD
Datadog LLM Observabilityrequestable
Spans and token metrics from existing APM pipelines
- AM
Azure Monitor
Diagnostic settings and Log Analytics queries
Billing & warehouse
- CB
Cloud Billing export
The invoice of record — makes a baseline LOGGED, not assumed
- BQ
BigQuery
Billing and log sinks already landed in a warehouse
- SF
Snowflakerequestable
Cost and usage tables shared into a Snowflake account