This skill answers one question with the user's own data: at what context size do their coding-agent sessions become a bad deal? Long context is not free even when it fits the window: every cache rebuild re-bills the whole context at write rates, compactions burn turns, and models degrade before their window ends. The sweet spot is where those costs start outrunning the value of the carried context. 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.

Coding-agent sessions live in the user's personal LangWatch workspace by default. signs this machine in; add on the read commands when the sessions live in a team project instead.

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.

Pick one window and use it everywhere, because defaults to the last 7 days. Compute a start and an end date once (30 days back to now is a good default) and pass both:

langwatch trace export --origin coding_agent --format jsonl --limit 20000 \
  --start-date <start> --end-date <end> -o coding-traces.jsonl

caps the whole export, not one page, so a window with more matches than the limit gives a partial file and the sessions it drops are the ones missing from the buckets. The command reports both counts when it truncates, for example . Raise until the two agree, or say in the report that the buckets come from a sample of N of M traces.

Report the window you used in the report, and delete once the analysis is done.

Each trace carries (the session id) and (which agent). Collect the distinct session ids, then for each session with enough turns to mean anything (5 or more model calls):

langwatch session events <sessionId> --format json

The events are the raw material: every model call with its input, output, cache-read and cache-creation tokens, its cost, its model, plus explicit and events.

Write a small local script (python3 or jq) over the events. Per session, compute:

Then aggregate across sessions: bucket by peak-context share (for example under 25%, 25 to 50%, 50 to 75%, over 75% of the window) and compare cost per call, rebuild rate and compaction rate between buckets. The sweet spot is the highest bucket where those three stay flat.

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

Also state the top finding directly in the conversation, leading with the number. The LangWatch session detail shows the same cache-health stats per session (), so name it as the place to watch the habit change.