Skip to main content
Glama

aiworkhub_task_cost_ledger

Read-only

Summarize repository-bound AI task costs and cache usage by provider, model, day, runner, and topic, with bounded rows and optional task-level detail.

Instructions

READ-ONLY: bounded cost summary, with opt-in detailed dimensions.

Default mode retains cost/cache truth plus provider, model and day aggregates, and stays bounded as usage history grows. by_model, cost_per_accepted_outcome.routes and model_outcomes.models each return at most _COST_LEDGER_SUMMARY_TOP_N rows. by_day is bounded as two independent groups -- up to _COST_LEDGER_SUMMARY_TOP_N most-recent dated buckets beside up to _COST_LEDGER_SUMMARY_TOP_N undated ones -- so its exact ceiling is 2 * _COST_LEDGER_SUMMARY_TOP_N rows, not N; undated spend is retained rather than made to compete with real days for one shared bound. Every bounded dimension carries explicit total_count/ returned_count/truncated/ranked_by metadata under summary_row_bounds, so no row is dropped silently. The two model-keyed dimensions rank by observed dollars rather than tokens; a bucket whose provider reported no price ranks on its activity instead of being cut as though it were free, and a partially priced bucket ranks in both orders so one cheap priced record cannot hide the magnitude whose dollars are still unknown. Per-runner and per-topic maps are available with full=true; task rows remain independently opt-in through include_tasks.

Kept rows are also narrower than full=true. Each kept model's cost_per_accepted_outcome.routes adapter folds its family/risk partitions into one total row, re-derived from summed counters so an UNKNOWN partition keeps it UNKNOWN; the fold is receipted under summary_row_bounds. by_day rows keep records, total_tokens, cost_usd, cost_unknown_records and cache_hit_ratio. full=true returns both exactly as built.

The repository binding is what makes those aggregates answerable. build_cost_ledger reads canonical usage events only when it is given a root; without one it parses the human-readable usage report, whose lines carry no model, provider or timestamp, so every dimension this docstring promises collapsed to unknown. Measured 2026-09-02 on this repository: unbound 590 rows / 1 model / 1 provider / 1 day / 0 usage-observed / 0 cache-observed / 0 routes; bound 3,509 rows / 28 models / 8 providers / 36 days / 2,267 usage-observed / 1,869 cache-observed / 13 routes. Every other caller (dashboard, manager tools, evidence instruments) already passed a root; this tool -- the manager's own cost surface -- did not, so routing by cost and difficulty had no measurement to steer by (NF-2026-00542).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aiworkhub_task_cost_ledger"
  }
}

Input Schema

NameRequiredDescriptionDefault
fullNoReturn the full snapshot exactly as built, including the per-runner and per-topic maps, instead of the bounded summary; default false.
topicNoOnly count usage for this topic; omit for all topics.
runnerNoOnly count usage by this runner; omit for all runners.
statusNoOnly count usage recorded with this task status; omit for all statuses.
include_tasksNoInclude one row per task as well as the aggregates; default false.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.12.67
    • addedInput schema / properties / full / description
      Added value: +"Return the full snapshot exactly as built, including the per-runner and per-topic maps, instead of the bounded summary; default false."
    • addedInput schema / properties / include_tasks / description
      Added value: +"Include one row per task as well as the aggregates; default false."
    • addedInput schema / properties / runner / description
      Added value: +"Only count usage by this runner; omit for all runners."
    • addedInput schema / properties / status / description
      Added value: +"Only count usage recorded with this task status; omit for all statuses."
    • addedInput schema / properties / topic / description
      Added value: +"Only count usage for this topic; omit for all topics."
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations supply readOnlyHint/openWorldHint, and the description still adds substantial non-obvious behavior: per-dimension row ceilings, the doubled ``by_day`` bound, explicit total_count/returned_count/truncated/ranked_by metadata under summary_row_bounds, dollars-vs-tokens ranking with unknown-price handling, and the repository-binding caveat. These are exactly the traits an agent cannot get from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first paragraph is well front-loaded, but the text balloons into internal implementation minutiae and then a full incident retrospective ('Measured 2026-09-02 ... NF-2026-00542') that an invoking agent cannot act on. Roughly half the content is changelog rather than invocation guidance, diluting the actionable signal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the description nonetheless covers bounds, truncation receipting, ranking rules, and filter-driven narrowing. Nothing needed to call it correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and each parameter is documented, so the baseline is 3. The description goes beyond that by explaining what ``full=true`` actually returns versus the folded/narrowed bounded rows, giving a real behavioral distinction between the two modes of the same flag.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+mode: 'READ-ONLY: bounded cost summary, with opt-in detailed dimensions.' That is far more precise than the tool name alone. It does not name a sibling (e.g. aiworkhub_task_usage_report) to distinguish itself, which keeps it at 4.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the default bounded mode versus opting into detail via ``full=true`` and ``include_tasks``, and tells the agent that per-runner/per-topic maps require full=true. What's missing is any comparison to the adjacent cost/usage tools in the sibling list, so the agent must infer which surface to pick.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools