TokenJam Verbosity
Some answers run long for the work they did. This finds the outliers — you decide if they're waste.
Flag sessions whose output runs long for the work they did.
$ tj optimize verbosity Examined 247 sessions across 18 task-shape cohorts (last 30d)… High-verbosity candidates (showing top 5 of 14): • Cohort "edit_file → run_tests": median output 620 tokens (31 sessions share this task shape) • 1 session ran 1,840 output tokens — 2.97× the cohort median (over-baseline: 1,220 tokens; output:input ratio 4.1, descriptive) • Suggested max_tokens cap: 620 (the cohort baseline, advisory) Estimated recoverable: ~$18/mo (soft upper bound, output-priced) across 14 flagged sessions — before you measure, treat this as $0. ⚠ Output length is not waste. A terse answer can drop information the task needed. This is a candidate to review, never a claim you are wasting tokens. Run `tj optimize --validate` to measure a brevity constraint on your own calls before applying it.
The problem
The other analyzers look at input and model choice. Verbosity is the one that looks at output: sessions burning tokens on answers that run long relative to the work they actually did.
But output length is not proof of waste. A terse answer can drop information the task needed, and "too verbose" is task-dependent. So Verbosity is the weakest-grounded analyzer, and it is treated that way: it flags a session only when its output is a clear outlier against other sessions doing the same shape of work, then surfaces a brevity remedy for you to measure before you touch anything.
How it differs
Verbosity is not Trim.
Trim looks at the input side: low-significance tokens in your captured system prompts, which you pay for on every call. Verbosity looks at the output side: individual sessions whose generated answer runs long against a like-for-like baseline. Trim shrinks what goes in; Verbosity questions what comes out.
How it works
Group sessions into cohorts by task-shape signature: the (tool_name, arg_shape) sequence, the same signature the Script analyzer uses. A cohort only counts if at least 5 sessions share the signature — fewer than that and its median is noise, so the cohort is skipped.
For each real cohort, take the median output tokens as the baseline. Flag any session whose output exceeds 2.0× that cohort median. The output:input ratio is carried as a descriptive field only — it never flags a session on its own, because a legitimately long answer to a short prompt is not waste. Recoverable is the over-baseline output summed across flagged sessions, priced at output rates: a soft upper bound, not a measured saving.
What you do with it
Recommendations land in your existing tools: the terminal, an MCP-capable agent, or an exportable config.
- CLI
tj optimize verbosity - Remedy
suggested max_tokens cap + brevity snippetadvisory strings only — you apply and measure them; the analyzer never edits a prompt or caps a call
- MCP
surfaces in get_optimize_report