メニュー
A practical playbook for cutting token and dollar cost in production LLM pipelines without wrecking quality. Use when reducing the token or dollar cost of an LLM pipeline — prompt caching, model tiering, context trimming, or batching.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use before any creative/build work — adding features, building components, new functionality, or changing behavior. Turns a brief or vague idea into an approved design doc through one-question-at-a-time dialogue. Does NOT write code until the design is approved. Output is the design doc; the next step is owned by the caller.
Craft a clear /goal condition for Claude Code's autonomous mode from a rough task description.
Convene an independent cross-model judge — a model of a different family (e.g. Codex/GPT, Gemini, or a Cursor agent pinned to a non-Claude model), whichever CLI is installed — to cross-examine an artifact (a decision, a diff, a document, or a research answer) and adjudicate its findings disbelieve-it-back. This is the cross-model *mechanism*; the caller brings the artifact and its own in-family review. Use via `vet` (code), `research-council` (research), `plan` (a design decision), or directly when you want a second opinion from a model that doesn't share your blind spots. It reviews; it never edits.
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.
Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
| name | llm-cost-optimization |
| description | A practical playbook for cutting token and dollar cost in production LLM pipelines without wrecking quality. Use when reducing the token or dollar cost of an LLM pipeline — prompt caching, model tiering, context trimming, or batching. |
Cut the cost of an LLM pipeline by attacking it in order: measure → cache → tier → trim → batch → cap → verify. Each lever is independent; apply the ones that fit the workload. Do not optimize blind — find the expensive calls first, and prove savings after.
Prices, discounts, and thresholds change. Treat the vendor pricing pages (see References) as the source of truth and read live usage from the API rather than hardcoding fragile numbers.
You cannot optimize what you have not measured. Before changing anything, find where the tokens and dollars actually go.
count_tokens endpoint (POST /v1/messages/count_tokens, returns input_tokens) that accepts the same payload as a real call, including system prompt, tools, images, and PDFs. Use it to size prompts and make routing decisions before paying for a completion.usage: input_tokens, output_tokens, cache_creation_input_tokens, cache_read_input_tokens.usage: prompt_tokens, completion_tokens, and prompt_tokens_details.cached_tokens.extract, summarize, classify) and aggregate. The 20% of call sites driving 80% of spend is where you spend your effort. Cheap, rare calls are not worth optimizing.Do not proceed to optimization until you know which calls cost the most and why.
Caching lets a stable prefix be processed once and reused cheaply on later calls. It pays off when the same large prefix repeats across many requests within the cache lifetime.
How it works (provider-specific):
cache_control: { type: "ephemeral" } (a small number of breakpoints per request). The cached prefix is built in a fixed order: tools → system → messages. A change anywhere invalidates that point and everything after it. There is a short default TTL (refreshed on each hit at no extra cost) and a longer extended-TTL option. Pricing is a multiplier on the base input rate: a cache write costs somewhat more than normal input, a cache read a small fraction of it — so a prefix read repeatedly is dramatically cheaper than re-sending it. There is a per-model minimum cacheable size; below it nothing is cached and no error is raised — check that cache_creation_input_tokens/cache_read_input_tokens are non-zero. Get the current breakpoint limit, TTLs, multipliers, and minimums from the docs.usage.prompt_tokens_details.cached_tokens to confirm hits; see the docs for the current length threshold and discount.Structure prompts to be cacheable:
[ stable system prompt ] ← cache these:
[ few-shot examples ] same on every call
[ large shared context/docs ]
───────────────────────────── ← breakpoint (Anthropic) / boundary
[ per-request variable input ] ← keep volatile content LAST
Put everything stable at the front and everything that changes per request at the back. A single varying byte near the top (a timestamp, a request ID, a user name interpolated into the system prompt) breaks the whole prefix and you pay full price.
When caching pays off: repeated calls sharing a big prefix (same instructions + same large document across many questions; same few-shot block across a batch of extractions). When it does not: one-off calls, prefixes below the minimum size, or prefixes that legitimately change every call. The cache-write surcharge means caching a prefix used only once costs more, not less.
Vercel AI SDK note: with the Anthropic provider, set caching via providerOptions.anthropic.cacheControl: { type: 'ephemeral' } on a message content part (add ttl: '1h' for the extended TTL), and read result.providerMetadata?.anthropic for cacheCreationInputTokens / cacheReadInputTokens. OpenAI caching is automatic and needs no SDK flag.
Frontier models cost several times more per token than small models and are slower. Most production traffic does not need the frontier model. Match model strength to task difficulty.
Never downgrade a model without an eval. Build a held-out set of representative inputs with known-good outputs, measure quality on both tiers, and only downgrade where the cheap tier clears your quality bar. A model swap that saves 60% but silently corrupts 5% of extractions is a regression, not a win.
The cheapest token is the one you never send. Re-sending unchanged bulk every call is the most common avoidable cost.
For work that is not latency-sensitive — bulk extraction, overnight summarization, evals, backfills — use the Batch API.
Batching stacks with caching and tiering: run cheap-tier bulk extraction through the Batch API for compounding savings. Use it for any pipeline stage where a few hours of latency is acceptable. Reserve synchronous calls for user-facing, real-time paths.
Output tokens are billed at a higher rate than input on most models, so shorter outputs save real money and latency.
max_tokens/max_output_tokens to the largest output you actually need. This bounds worst-case cost and stops runaways.An optimization is not done until you have measured it.
usage fields, not estimates.cache_read_input_tokens > 0 on Anthropic; cached_tokens > 0 on OpenAI). A cache you think is working but isn't is a silent non-saving.max_tokens uncapped, allowing runaway generations.