Semantr reads the Bedrock invocation logs you already have, groups the invocations back into conversations, and works out what kinds of work your organisation is actually doing with AI.
curl -LsSf https://semantr.com/install.sh | sh
Then run semantr. It finds your invocation logs on AWS, prices the run, and analyses them.
$ semantr semantr: looking for your invocation logs found invocation logs at s3://acme-bedrock-logs/AWSLogs/ (ap-southeast-2) Semantr will read those logs, rebuild the conversations, and name the kinds of work it finds. Continue? [Y/n] y sessionise 2,761 invocations → 1,007 conversations discover 221 distinct prompts → 21 named use cases aggregate $2,145.30 total spend analysed report semantr-report.html
Sign in once, with Google, so we can fund the model that names what it finds. Your account also keeps history, trends and shareable links.
Every discovered use case, named from its own contents, with its own spend, conversations and cost improvements attached.
Example report output:
| Use case | Tags | Conv | Spend |
|---|---|---|---|
| Customer Support Responses | non-coding repeatable | 206 | $1,204.60 |
| Invoice Data Extraction | non-coding repeatable | 238 | $58.30 |
| Pull Request Review | coding repeatable | 131 | $14.90 |
| Churn Analysis Queries | coding experimental | 44 | $616.40 |
| Database Script Development | coding experimental | 34 | $18.20 |
Every use case is tagged coding vs non-coding, and repeatable vs experimental. That shows you, at a glance, how much of your spend is automation running in production and how much is people still trying things out.
Model right-sizing, prompt caching, retry loops, untagged spend: each with the annual saving worked out, so it is a decision rather than a suggestion.
Cost dashboards report spend by team, key and model. That's accounting, not what the money bought.
"$40k on Bedrock last quarter" is a number, not an answer. Spend by API key does not tell anyone whether the money bought customer support or someone's side project.
Every team knows what they built. No one knows what the other eleven teams built, and the list nobody maintains is always out of date.
Classifying every invocation with an LLM costs tens of thousands of dollars at real volume. Which is why nobody does it, and why nobody knows.
Three steps, from raw logs to named use cases.
Bedrock logs are stateless: twenty records for one conversation. Each invocation names the one before it, so rebuilding them is exact, not guessed.
2,761 invocations → 1,007 conversations
Similar conversations are grouped and named from their own contents. No fixed taxonomy, so no other bucket: the categories come from what you're actually doing.
1,007 conversations → 221 distinct prompts → 21 named use cases
Spend and cost improvements roll up against each use case, per conversation, not per request.
$2,145.30 across 21 use cases · analysis cost $0.03
Security & privacy
Every design decision below follows from one rule: what you analyse never has to leave the machine it runs on.
Naming is the only step that calls a model, and it only ever sees prompt snippets, capped at 600 characters. Point --classifier-model at your own provider and that path is never touched.
Every run keeps its aggregates: counts, cost, and the names it discovered. Prompt text is stripped before anything is sent.
The CLI, the pipeline and the report are Apache 2.0. Run the whole thing yourself and nothing has to leave your account.
One run tells you what your organisation is using AI for right now. Signed in, every run adds to that picture instead of replacing it.
Run it again next month and see exactly what moved: use cases that appeared, spend that shifted between teams, adoption that grew or quietly stalled.
Runs are kept against your organisation, not against whoever happened to run the CLI. The picture survives someone leaving the team, and a shared link stays live for whoever needs it next.