Price-card comparisons lie by omission: a provider that halves the per-token price and lacks cache discounts can cost more on a cache-heavy coding workload. This skill prices the user's own month of usage, with its real input/output/cache mix, under each candidate. It is read-only on the platform. Locally it writes a trace export while it works and deletes it again, and leaves one report file behind.

Use the CLI for everything: documentation (, ) and platform operations (prompts, scenarios, evaluators, datasets, monitors, traces, analytics). Install it once with , then run the binary directly; an unpinned re-resolves the package from the registry on every run.

Personal coding-agent usage needs ; a team or application project needs on the read commands.

Use to read documentation as Markdown. Some useful entry points:

langwatch docs                                    # Docs index
langwatch docs integration/python/guide           # Python integration
langwatch docs integration/typescript/guide       # TypeScript integration
langwatch docs prompt-management/cli              # Prompts CLI
langwatch scenario-docs                           # Scenario docs index

Discover commands with and . List and get commands accept for machine-readable output. Every list command takes to cap the rows and to read part of the answer. A paginated list answers with an envelope, so count its rows through the row array (), and read how many there are in all at . Bare counts the fields of the envelope, not the rows. Read the docs first instead of guessing SDK APIs or CLI flags.

If no shell is available, fetch the same Markdown over plain HTTP. Append to any docs path (e.g. https://langwatch.ai/docs/integration/python/guide.md). Index: https://langwatch.ai/docs/llms.txt. Scenario index: https://langwatch.ai/scenario/llms.txt

If anything fails or confuses you while following this skill (broken commands, docs that do not match reality, errors you had to work around), ask the user for permission and run with a and (or ) to send it to the LangWatch team, and it directly shapes what gets fixed. No login or API key needed. Nothing is sent without , and prints the exact payload without sending anything. The title, summary and transcript are scrubbed locally first, by pattern: secrets and API keys, plus email addresses, phone numbers, card numbers and public IPv4 addresses. Anything no pattern matches is sent as written, including a contact address passed with . With , always run first and let the user read the payload, because a transcript carries content they never reviewed. explains the options.

Settle two things before running anything, and hold both for the whole analysis.

The window. and both default to the last 7 days, so a report about a month has to state the window itself. Compute one start date and one end date, 30 days back to now unless the user names another window, and pass the same pair to every command.

The scope. covers the whole project and has no origin filter, while takes . Mixing them silently compares application traffic in the totals against coding-agent traffic in the breakdown. When the question is about coding-agent usage, scope the export with and build every priced number from that export. Use the analytics calls only as a project-wide cross-check, and label them that way in the report. When the question is about the whole project, drop and the two agree by construction.

langwatch analytics query --metric total-tokens --group-by metadata.model --format json \
  --start-date <start> --end-date <end>
langwatch analytics query --metric total-cost --group-by metadata.model --format json \
  --start-date <start> --end-date <end>
langwatch trace export --format jsonl --origin coding_agent --limit 20000 \
  --start-date <start> --end-date <end> -o traces.jsonl

caps the whole export, not one page, so a window with more matches than the limit gives a partial file. The command reports both counts when it truncates, for example . Raise until the two agree, or say in the report that the numbers come from a sample of N of M traces. Never present a truncated export as the window's total.

Delete once the analysis is done.

Collect the distinct values from the export and pull the per-call rows, because the cache split lives there:

langwatch session events <sessionId> --format json

Compute, per model: input tokens, output tokens, cache-read tokens, cache-creation tokens, and the totals over the window you exported. The cache-read share is the single most important number of the whole analysis; on coding agents it is often the large majority of all input.

Fetch the candidates' price pages at analysis time and cite them; never price from memory, the numbers churn monthly. For each candidate record: input price, output price, cache-read price, cache-write price (some providers price a write above fresh input, some price it the same, some offer no caching at all), the cache-storage price and its unit if the candidate bills cache residency by time, the default cache lifetime, and the context window.

Cache pricing has three shapes and they do not reprice the same way: a write premium and no storage charge, a storage charge by token-hour with a cheap or free write, or no cache at all. Record which shape each candidate uses, because Step 4 needs it.

Candidates come from the user; when they name none, take the current obvious ones for the workload's model class and say why those.

For each candidate, reprice the same mix:

Write a single self-contained in the project root (inline CSS, no external assets) with:

State the headline numbers directly in the conversation too.