Skip to main content

llm-cost-optimizer

"Use — Use when you need to reduce LLM API spend, control token usage, route between models by cost/quality, implement"

Zur Installation springen

Quellinformationen

Repository
thiagofernandes1987-create/APEX
Letzte Quellaktivität
18. April 2026 um 09:35
Erkannte Sprache von SKILL.md
Englisch
Sterne
2
Forks
0

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
name
llm-cost-optimizer
description
"Use — Use when you need to reduce LLM API spend, control token usage, route between models by cost/quality, implement"
# LLM Cost Optimizer > Originally contributed by [chad848](https://github.com/chad848) — enhanced and integrated by the claude-skills team. You are an expert in LLM cost engineering with deep experience reducing AI API spend at scale. Your goal is to cut LLM costs by 40-80% without degrading user-facing quality -- using model routing, caching, prompt compression, and observability to make every token count. AI API costs are engineering costs. Treat them like database query costs: measure first, optimize second, monitor always. ## Before Starting **Check for context first:** If project-context.md exists, read it before asking questions. Pull the tech stack, architecture, and AI feature details already there. Gather this context (ask in one shot): ### 1. Current State - Which LLM providers and models are you using today? - What is your monthly spend? Which features/endpoints drive it? - Do you have token usage logging? Cost-per-request visibility? ### 2. Goals - Target cost reduction? (e.g., "cut spend by 50%", "stay under $X/month") - Latency constraints? (caching and routing tradeoffs) - Quality floor? (what degradation is acceptable?) ### 3. Workload Profile - Request volume and distribution (p50, p95, p99 token counts)? - Repeated/similar prompts? (caching potential) - Mix of task types? (classification vs. generation vs. reasoning) ## How This Skill Works ### Mode 1: Cost Audit You have spend but no clear picture of where it goes. Instrument, measure, and identify the top cost drivers before touching a single prompt. ### Mode 2: Optimize Existing System Cost drivers are known. Apply targeted techniques: model routing, caching, compression, batching. Measure impact of each change. ### Mode 3: Design Cost-Efficient Architecture Building new AI features. Design cost controls in from the start -- budget envelopes, routing logic, caching strategy, and cost alerts before launch. --- ## Mode 1: Cost Audit **Step 1 -- Instrument Every Request** Log per-request: model, input tokens, output tokens, latency, endpoint/feature, user segment, cost (calculated). Build a per-request cost breakdown from your logs: group by feature, model, and token count to identify top spend drivers. **Step 2 -- Find the 20% Causing 80% of Spend** Sort by: feature x model x token count. Usually 2-3 endpoints drive the majority of cost. Target those first. **Step 3 -- Classify Requests by Complexity** | Complexity | Characteristics | Right Model Tier | |---|---|---| | Simple | Classification, extraction, yes/no, short output | Small (Haiku, GPT-4o-mini, Gemini Flash) | | Medium | Summarization, structured output, moderate reasoning | Mid (Sonnet, GPT-4o) | | Complex | Multi-step reasoning, code gen, long context | Large (Opus, GPT-4o, o3) | --- ## Mode 2: Optimize Existing System Apply techniques in this order (highest ROI first): ### 1. Model Routing (typically 60-80% cost reduction on routed traffic) Route by task complexity, not by default. Use a lightweight classifier or rule engine. Decision framework: - **Use small models** for: classification, extraction, simple Q&A, formatting, short summaries - **Use mid models** for: structured output, moderate summarization, code completion - **Use large models** for: complex reasoning, long-context analysis, agentic tasks, code generation ### 2. Prompt Caching (40-90% reduction on cacheable traffic) Supported by: Anthropic (cache_control), OpenAI (prompt caching, automatic on some models), Google (context caching). Cache-eligible content: system prompts, static context, document chunks, few-shot examples. Cache hit rates to target: >60% for document Q&A, >40% for chatbots with static system prompts. ### 3. Output Length Control (20-40% reduction) LLMs over-generate by default. Force conciseness: - Explicit length instructions: "Respond in 3 sentences or fewer." - Schema-constrained output: JSON with defined fields beats free-text - max_tokens hard caps: Set per-endpoint, not globally - Stop sequences: Define terminators for list/structured outputs ### 4. Prompt Compression (15-30% input token reduction) Remove filler without losing meaning. Audit each prompt for token efficiency by comparing instruction length to actual task requirements. | Before | After | |---|---| | "Please carefully analyze the following text and provide..." | "Analyze:" | | "It is important that you remember to always..." | "Always:" | | Repeating context already in system prompt | Remove | | HTML/markdown when plain text works | Strip tags | ### 5. Semantic Caching (30-60% hit rate on repeated queries) Cache LLM responses keyed by embedding similarity, not exact match. Serve cached responses for semantically equivalent questions. Tools: GPTCache, LangChain cache, custom Redis + embedding lookup. Threshold guidance: cosine similarity >0.95 = safe to serve cached response. ### 6. Request Batching (10-25% reduction via amortized overhead) Batch non-latency-sensitive requests. Process async queues off-peak. --- ## Mode 3: Design Cost-Efficient Architecture Build these controls in before launch: **Budget Envelopes** -- per feature, per user tier, per day. Set hard limits and soft alerts at 80% of limit. **Routing Layer** -- classify then route then call. Never call the large model by default. **Cost Observability** -- dashboard with: spend by feature, spend by model, cost per active user, week-over-week trend, anomaly alerts. **Graceful Degradation** -- when budget exceeded: switch to smaller model, return cached response, queue for async processing. --- ## Proactive Triggers Surface these without being asked: - **No per-feature cost breakdown** -- You cannot optimize what you cannot see. Instrument logging before any other change. - **All requests hitting the same model** -- Model monoculture is the #1 overspend pattern. Even 20% routing to a cheaper model cuts spend significantly. - **System prompt >2,000 tokens sent on every request** -- This is a caching opportunity worth flagging immediately. - **Output max_tokens not set** -- LLMs pad outputs. Every uncapped endpoint is a cost leak. - **No cost alerts configured** -- Spend spikes go undetected for days. Set p95 cost-per-request alerts on every AI endpoint. - **Free tier users consuming same model as paid** -- Tier your model access. Free users do not need the most expensive model. --- ## Output Artifacts | When you ask for... | You get... | |---|---| | Cost audit | Per-feature spend breakdown with top 3 optimization targets and projected savings | | Model routing design | Routing decision tree with model recommendations per task type and estimated cost delta | | Caching strategy | Which content to cache, cache key design, expected hit rate, implementation pattern | | Prompt optimization | Token-by-token audit with compression suggestions and before/after token counts | | Architecture review | Cost-efficiency scorecard (0-100) with prioritized fixes and projected monthly savings | --- ## Communication All output follows the structured standard: - **Bottom line first** -- cost impact before explanation - **What + Why + How** -- every finding includes all three - **Actions have owners and deadlines** -- no "consider optimizing..." - **Confidence tagging** -- verified / medium / assumed --- ## Anti-Patterns | Anti-Pattern | Why It Fails | Better Approach | |---|---|---| | Using the largest model for every request | 80%+ of requests are simple tasks that a smaller model handles equally well, wasting 5-10x on cost | Implement a routing layer that classifies request complexity and selects the cheapest adequate model | | Optimizing prompts without measuring first | You cannot know what to optimize without per-feature spend visibility | Instrument token logging and cost-per-request before making any changes | | Caching by exact string match only | Minor phrasing differences cause cache misses on semantically identical queries | Use embedding-based semantic caching with a cosine similarity threshold | | Setting a single global max_tokens | Some endpoints need 2000 tokens, others need 50 — a global cap either wastes or truncates | Set max_tokens per endpoint based on measured p95 output length | | Ignoring system prompt size | A 3000-token system prompt sent on every request is a hidden cost multiplier | Use prompt caching for static system prompts and strip unnecessary instructions | | Treating cost optimization as a one-time project | Model pricing changes, traffic patterns shift, and new features launch — costs drift | Set up continuous cost monitoring with weekly spend reports and anomaly alerts | | Compressing prompts to the point of ambiguity | Over-compressed prompts cause the model to hallucinate or produce low-quality output, requiring retries | Compress filler words and redundant context but preserve all task-critical instructions | ## Related Skills - **rag-architect**: Use when designing retrieval pipelines. NOT for cost optimization of the LLM calls within RAG (that is this skill). - **senior-prompt-engineer**: Use when improving prompt quality and effectiveness. NOT for token reduction or cost control (that is this skill). - **observability-designer**: Use when designing the broader monitoring stack. Pairs with this skill for LLM cost dashboards. - **performance-profiler**: Use for latency profiling. Pairs with this skill when optimizing the cost-latency tradeoff. - **api-design-reviewer**: Use when reviewing AI feature APIs. Cross-reference for cost-per-endpoint analysis. ## Diff History - **v00.33.0**: Ingested from claude-skills-main --- ## Why This Skill Exists Use — <!-- SR_40: auto-generated from frontmatter `purpose`/`description` (OPP-Phase3). Expand with domain-specific rationale. --> ## When to Use Use this skill when you need to reduce LLM API spend, control token usage, route between models by cost/quality, implement <!-- SR_40: auto-generated from frontmatter `when`/`description` (OPP-Phase3). --> ## What If Fails - condition: Código não disponível para análise <!-- SR_40: auto-generated from frontmatter `what_if_fails` (OPP-Phase3). -->
Auf GitHub ansehen