The problem
The API tells me how often each Pickaxe runs but not what it costs. pickaxe_get returns usestotal and usestoday, and deployment_list returns totalUses per deployment. Both count runs. Neither says how many credits or tokens those runs consumed.
Run counts alone rank tools badly. One run of a short chat tool can cost a few hundred credits, while one run of a whole-manuscript analysis or an image tool can cost tens of thousands. A tool can be tenth by runs and first by spend.
The per-user counters do not fill the gap either. A user record reports total credits used across every tool, with no split by Pickaxe.
Why history is not the answer
Message Insights and the history endpoints do carry per-run cost. But a workspace on maximum privacy keeps no history, by design, and that is the right setting for tools that read users’ unpublished work. Those workspaces have no way to see cost by tool at all.
An aggregate counter reveals no content. It is the same kind of number as usestotal, so it fits a maximum-privacy workspace without weakening it.
What I am asking for
In order of value. Any one of them helps.
1. Credit counters next to the run counters
Add creditstotal and creditstoday to pickaxe_get, alongside usestotal and usestoday. Add totalCredits to each deployment in deployment_list, next to totalUses. Lifetime totals are enough, because a daily reader can difference them.
2. Token counts, if credits are hard
Input and output tokens per Pickaxe would also work, since credits follow from tokens and the model. Credits are better, because they include action and image costs and whichever model actually answered when the fallback model steps in.
3. A dated usage endpoint
Credits and runs per Pickaxe per day for a date range. This saves every builder from polling counters daily and storing the differences.
How I would use it
I build a dashboard that reads these counters once a day. With credits per tool I could:
- See which tools carry the cost, so model and prompt work goes where it pays.
- Spot a tool whose cost per run jumps after a model or prompt change.
- Set per-tool limits and pricing tiers from real spend instead of guesses.
The workaround today
I multiply each tool’s runs by the credits one run cost when I measured it on a test copy. That estimate misses everything that makes real use expensive: follow-up messages in the same session, large uploads, retries, and fallback-model runs. It also goes stale every time a model or prompt changes. The platform already meters every credit, so the real number is one field away.