mcp-cost-optimizer
MCP Cost Optimizer
See what your LLM calls cost and how much you'd save by switching models β local MCP server, no API keys.
Find overspending in your AI agent's usage records. Compare the cost of every model you're considering. Make decisions with real numbers, not guesses.
π Quick Install
Cursor
Click the button above to install in Cursor with one click, or use this deeplink:
cursor://anysphere.cursor-deeplink/mcp/install?name=cost-optimizer&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIm1jcC1jb3N0LW9wdGltaXplciJdfQ==Claude Code
# Quick install
claude mcp add cost-optimizer -- npx -y mcp-cost-optimizer
# Or via marketplace
/plugin marketplace add petrovicistefan/mcp-cost-optimizer
/plugin install mcp-cost-optimizer@mcp-cost-optimizerVS Code
Or manually add to .vscode/mcp.json:
{
"servers": {
"cost-optimizer": {
"type": "stdio",
"command": "npx",
"args": ["-y", "mcp-cost-optimizer"]
}
}
}Any MCP Client
npx -y mcp-cost-optimizerSee detailed setup instructions for other clients (Windsurf, Cline, Gemini CLI, Zed, Codex CLI).
Related MCP server: token-meter
Table of Contents
Quickstart
Claude Code Plugin
/plugin marketplace add petrovicistefan/mcp-cost-optimizer
/plugin install mcp-cost-optimizer@mcp-cost-optimizerAny MCP Client
Works with Cursor, VS Code, Windsurf, Claude Desktop, Cline, Codex CLI, Zed, and Gemini CLI. Install with one command:
npx -y mcp-cost-optimizerOr add to your MCP config file:
Claude Desktop, Cursor, Windsurf, Cline, Gemini CLI β claude_desktop_config.json, ~/.cursor/mcp.json, ~/.codeium/windsurf/mcp_config.json, Cline MCP settings, ~/.gemini/settings.json:
{
"mcpServers": {
"cost-optimizer": {
"command": "npx",
"args": ["-y", "mcp-cost-optimizer"]
}
}
}VS Code / GitHub Copilot β .vscode/mcp.json:
{
"servers": {
"cost-optimizer": {
"type": "stdio",
"command": "npx",
"args": ["-y", "mcp-cost-optimizer"]
}
}
}Zed β settings.json:
{
"context_servers": {
"cost-optimizer": {
"command": "npx",
"args": ["-y", "mcp-cost-optimizer"]
}
}
}Codex CLI:
codex mcp add cost-optimizer -- npx -y mcp-cost-optimizerβ Support This Project
Found this MCP useful? Star this repository!
A GitHub star helps other developers discover the project and lets you save it for later. Thanks for supporting open source!
Demo

Analyzing LLM usage across multiple models with custom pricing rates
Why MCP Cost Optimizer?
You're running AI agents. You have usage logs. You're wondering:
How much did that cost? Analyze normalized usage records and see total cost, per-model breakdown, and which models lack pricing data.
What if I switched models? Compare migration scenarios: keep your token counts, change the model, see estimated savings (or extra cost).
Am I repeating the same requests? Identify conditional response-cache opportunities when you supply request hashes.
MCP Cost Optimizer is:
Local-first: No API keys, no accounts, no outbound requests. Your usage data stays on your machine.
Provider-agnostic: Bring your own pricing tables. Works with any LLM provider.
Transparent: All calculations are deterministic. No hidden assumptions, no magic. You supply the prices, you get exact estimates.
Example Prompts
Once installed, try asking your AI agent:
"Analyze these normalized usage records with my supplied rates. Identify unknown models and repeated requests, then compare a cheaper model. Explain assumptions and do not change production routing."
"I have 50,000 requests across gpt-4o and claude-sonnet-4.5. Estimate the cost with these rates, then show me the savings if I switched to gpt-4o-mini for half of them."
"Compare my current model usage to claude-haiku-3-5. What would I save per month if I migrated?"
Tools
The server exposes three MCP tools for cost analysis:
Tool | Description | Inputs | Output |
| Estimate one LLM request from supplied per-million token rates. Input tokens include cached tokens. |
| Single-request cost estimate with currency and pricing date |
| Analyze normalized LLM usage; report costs, unknown models and conditional response-cache opportunities. No network or file access. |
| Aggregate analysis: total cost, per-model breakdown, unknown models, duplicate request opportunities, token totals |
| Compare a target model with known-price baseline. Scenario only; requires quality evaluation and does not change routing. |
| Migration scenario: what you'd spend with a different model, keeping the same token counts (requires quality evaluation separately) |
All tools:
Accept structured JSON arguments
Return formatted text + structured JSON
Read-only and idempotent (safe to call repeatedly)
No network requests or file access
Importing Usage Data
The hook is weak because the tools require normalized usage records. Here's how to get them.
Expected Input Format
Each usage record must include:
{
"model": "gpt-4o",
"inputTokens": 1000,
"outputTokens": 50,
"cachedInputTokens": 0,
"requestHash": "optional-unique-identifier"
}Rules:
model: Exact model name (must match your rates file)inputTokens: Total input tokens, including cached tokensoutputTokens: Total output tokenscachedInputTokens: (Optional) Prompt cache hits (must be β€inputTokens)requestHash: (Optional) Unique identifier for the entire request (tenant, model params, system context, tool state, freshness) β used to identify conditional response-cache opportunities
Important: OpenAI's prompt_tokens and Anthropic's separate cache fields are not accepted directly. You must normalize them first.
Example: OpenAI Usage Export
If you export usage from OpenAI's dashboard, you might get CSV with columns like model, prompt_tokens, completion_tokens, cached_tokens.
Transform to normalized format:
// Example transformation (Node.js)
const fs = require('fs');
const Papa = require('papaparse'); // npm install papaparse
const csv = fs.readFileSync('openai-usage-export.csv', 'utf8');
const parsed = Papa.parse(csv, { header: true, dynamicTyping: true });
const normalized = parsed.data.map(row => ({
model: row.model,
inputTokens: row.prompt_tokens, // OpenAI prompt_tokens = total input
outputTokens: row.completion_tokens,
cachedInputTokens: row.cached_tokens || 0,
requestHash: row.request_id // if available
}));
fs.writeFileSync('normalized-usage.jsonl', normalized.map(r => JSON.stringify(r)).join('\n'));Then supply normalized-usage.jsonl to your agent along with your rates file.
Example: Anthropic Usage Export
Anthropic's usage exports include separate fields for input_tokens, cache_creation_input_tokens, cache_read_input_tokens, and output_tokens.
Transform to normalized format:
// Anthropic β normalized format
const normalized = anthropicUsage.map(row => ({
model: row.model,
inputTokens: row.input_tokens + row.cache_creation_input_tokens + row.cache_read_input_tokens,
outputTokens: row.output_tokens,
cachedInputTokens: row.cache_read_input_tokens,
requestHash: row.request_id // if available
}));Note: Cache-write pricing is separate from normal input pricing. This MVP does not support differential cache-write rates. If you supply cachedInputPerMillion in your rates file, it applies to cache reads only.
Rates File Format
Supply your own pricing table as JSON:
{
"currency": "USD",
"asOf": "2026-10-19",
"models": {
"gpt-4o": {
"inputPerMillion": 2.5,
"outputPerMillion": 10.0,
"cachedInputPerMillion": 1.25
},
"claude-sonnet-4.5": {
"inputPerMillion": 3.0,
"outputPerMillion": 15.0
}
}
}currency: Three-letter code (e.g.,"USD","EUR")asOf: (Optional) Date when prices were verifiedmodels: Keyed by exact model nameinputPerMillion: Price per million input tokensoutputPerMillion: Price per million output tokenscachedInputPerMillion: (Optional) Price per million cached input tokens (defaults toinputPerMillionif omitted)
All models in the rates file must use the same currency. Unknown models are excluded from totals and marked as incomplete.
See examples/rates.json for a demo file (fictional prices).
Use Cases
1. AI Agent Cost Audit
You've run Claude Code or Cursor for a month. You have session logs. You want to know:
Total spend per model
Which models lacked pricing data
Where you can save by switching models
Workflow: Export your usage, normalize it, supply it to your agent with this MCP server installed. Ask: "Analyze my usage and compare it to a cheaper model."
2. Model Migration Planning
You're considering migrating from gpt-4o to gpt-4o-mini for some workloads.
Workflow: Use compare_llm_models to estimate savings. Keep in mind: the tool assumes token counts stay the same. You must separately evaluate quality, context window, and latency.
3. Response Cache Opportunity Detection
You supply requestHash for each request (a hash of tenant, model params, system context, tool state, freshness requirements).
Workflow: The analyze_llm_usage tool identifies duplicate hashes and reports upper-bound savings if you implemented conditional response caching. This is not provider prompt cachingβit's request-level deduplication.
4. Individual Developer / Freelancer
You're working across multiple clients. You want to track LLM costs per project.
Workflow: Keep separate usage logs per project. Analyze each independently. Sum totals for invoicing.
5. Team / Enterprise
Your team shares an API key. You want to attribute costs per engineer or per feature.
Workflow: Tag usage records with engineer/feature identifiers. Analyze subsets. (Future: hosted path with budgets and alerts.)
Privacy & Security
No telemetry: Zero outbound requests from the local MCP server or CLI.
No credentials: The server never asks for or stores API keys.
No file writes: MCP tools accept structured data only; they do not read or write files.
CLI sandboxing: The CLI reads JSON/JSONL files only under its current directory, resolves symlinks, and rejects paths outside that root. Files are checked for regular-file type and size (β€20 MiB) before reading. JSONL is parsed incrementally and capped at 100,000 records.
Safe arithmetic: Aggregated token counts reject unsafe integer totals. Cost calculations reject infinite results.
Comparison
Tool | Focus | Local | Import Format | Model Comparison | Cache Opportunities | MCP Server |
Cost analysis & model-switch scenarios | β | Normalized JSON | β | β (request-level) | β | |
Agent work intelligence & cost dashboard | β | Claude Code/Codex logs | β | β | β (Python dashboard) | |
Menu-bar dashboard for Claude CLI | β | Claude CLI logs | β | β | β (macOS/Windows app) | |
Real-time terminal monitoring | β | Provider APIs + session files | β | β (provider cache %) | β (TUI) | |
Terminal dashboard with budgets & forecasts | β | Log file / stdin | β | β | β (Rust TUI) |
What sets MCP Cost Optimizer apart:
MCP-native: Works with any MCP client (Claude Code, Cursor, VS Code, Windsurf, Cline, Zed, Claude Desktop, Gemini CLI, Codex CLI).
Model comparison: Estimate savings (or extra cost) for migration scenarios.
Request-level cache detection: Identify duplicate requests when you supply hashes.
Provider-agnostic: Bring your own pricing tables (OpenAI, Anthropic, Gemini, Llama, Mistral, etc.).
Transparent: All calculations are deterministic. No guesswork, no hidden assumptions.
Limitations
This is an MVP (v0.1.2). Here's what it doesn't do yet:
Cache-write pricing: Separate cache-write rates are not supported. Only cache-read pricing is configurable via
cachedInputPerMillion.Reasoning tokens: Extended reasoning tokens (e.g., OpenAI o1/o3 series) are not separately priced in this version.
Automatic pricing updates: You must maintain your own rates file. The tool does not fetch live pricing from providers.
Invoice reconciliation: Estimates are based on your supplied prices, not provider invoices. Currency conversion and taxes are not included.
Quality evaluation: Model comparisons assume token counts stay the same. You must separately evaluate quality, tokenizer differences, context window, tool support, and latency.
Automatic routing: The tool provides estimates only. It does not change your application's model selection.
Free and Pro
Local MCP/CLI: Free forever. Works offline. No accounts, no API keys, no quotas.
Hosted path (future): For teams that want centralized quotas, budgets, and alerts, a hosted HTTP path with control-plane integration is planned. Pricing TBD.
Roadmap
Provider adapters for automatic normalization (OpenAI, Anthropic, Gemini, Bedrock)
Cache-write and reasoning token accounting
Verified versioned pricing catalog
Project budgets and alerts
Quality-gated model evaluation
Hosted reporting dashboard
Validate these features with real usage before adding automatic optimizations.
Contributing
Contributions welcome! See CONTRIBUTING.md (if exists) or open an issue.
Before contributing:
Run
npm testandnpm run checkto verify your changes.Follow the existing code style (zero external dependencies in core.js, ESM modules, node:test for tests).
Add tests for new features.
License
MIT License - see LICENSE file for details.
Copyright Β© 2026 Stefan Petrovici
Free to use, modify, and distribute. No warranty provided.
More MCP Servers by the Author
Part of the petrovicistefan MCP suite β local-first guardrails for AI coding agents.
Server | Purpose | Link |
π‘οΈ MCP Security Guard | Detect tool poisoning, rug pulls, prompt injection in MCP servers | |
π° MCP Cost Optimizer | Analyze LLM costs and model-switch savings | |
ποΈ MCP Database Doctor | Diagnose schema issues, slow queries, missing indexes | |
π¦ MCP Dependency Doctor | Find outdated packages, CVEs, license conflicts | |
π MCP SEO Auditor | Local SEO checks for meta tags, schema, performance | |
π MCP API Guardian | Validate OpenAPI specs, detect breaking changes | |
πͺ MCP Marketplace | Browse and discover the full suite |
Found this useful? β Star this repo to help others discover it!
Available Tools
3 toolsanalyze_llm_usageBRead-onlyIdempotent
Analyze normalized LLM usage; report costs, unknown models and conditional response-cache opportunities. No network or file access.
| Name | Required | Description | Default |
|---|---|---|---|
| rates | Yes | ||
| records | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by saying it reports unknown models and conditional response-cache opportunities, and by stating 'No network or file access.' It still does not explain error behavior or how unknown models are handled beyond being reported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no wasted words. The main purpose is front-loaded, followed by the report contents and no-I/O constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with a deeply nested input schema, 0% schema description coverage, and no output schema. The description briefly mentions return contents but does not explain the input structure or enough semantics for records and rates. It is too thin for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the input schema is a nested object with required records and rates plus detailed subfields. The description only vaguely gestures at 'normalized LLM usage' and 'costs' without explaining what records, rates, currency, asOf, requestHash, or cachedInputTokens mean. The schema has to carry nearly all parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: analyze normalized LLM usage. It also names the report contents (costs, unknown models, response-cache opportunities), which helps distinguish it from a simple cost-estimation sibling. However, it does not explicitly contrast itself with estimate_llm_cost or compare_llm_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is for analyzing normalized usage records with rates, but it gives no explicit when-to-use guidance. There is no mention of prerequisites, exclusions, or when an agent should choose this tool over estimate_llm_cost or compare_llm_models.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_llm_modelsCRead-onlyIdempotent
Compare a target model with known-price baseline. Scenario only; requires quality evaluation and does not change routing.
| Name | Required | Description | Default |
|---|---|---|---|
| rates | Yes | ||
| records | Yes | ||
| targetModel | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds the meaningful behavioral point that this is a simulation/scenario with no routing side effects and that quality evaluation is out of scope, but it never says what the caller gets back or what constraints apply to the comparison.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and followed by the scope caveat. Nothing is padded, though the second sentence's "requires quality evaluation" phrasing is more confusing than economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested schema at 0% description coverage, a 100k-item array, no output schema, and three mandatory inputs, two sentences are far too thin. The agent cannot tell what shape of records to supply or what the comparison surfaces.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across three required parameters, one of which is a deeply nested rates object and another a records array of up to 100,000 items. The description only obliquely gestures at targetModel and rates ("known-price baseline"); the records parameter, including inputTokens/outputTokens/cachedInputTokens and requestHash, is completely unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Compare a target model with known-price baseline" gives a verb and a resource, but the object of the comparison is ambiguous: cost? quality? throughput? The mention of "requires quality evaluation" muddies rather than clarifies. Sibling names (estimate_llm_cost, analyze_llm_usage) are never referenced, so the agent must infer the boundary itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Scenario only" and "does not change routing" imply when this tool is appropriate (what-if analysis rather than live actuals), which is genuine usage guidance. However, no alternative is named explicitly, and the agent is left to guess that estimate_llm_cost is the non-scenario counterpart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_llm_costBRead-onlyIdempotent
Estimate one LLM request from supplied per-million token rates. Input tokens include cached tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| rates | Yes | ||
| record | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds useful calculation context by stating rates are supplied per-million tokens and that input tokens include cached tokens, but it does not explain how cached rates are applied, rounding, or what the estimate returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and followed by the key costing caveat. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested rates object, a nested record object, no output schema, and no schema descriptions. The description is too sparse to fully explain the required nested structure, currency, model-rate mapping, or the expected return, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies per-million rates and cached-token inclusion, but leaves key nested semantics undocumented: rates.models keyed by model, currency format, asOf, requestHash, and outputTokens.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Estimate one LLM request' cost from supplied token rates. It is clear what the tool does, though it does not explicitly distinguish itself from siblings analyze_llm_usage and compare_llm_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus the sibling tools, nor any when-not conditions. The phrase 'one LLM request' implies single-request estimation rather than bulk analysis, but that is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.2- First observed
analyze_llm_usage - First observed
compare_llm_models - First observed
estimate_llm_cost
TDQS
Scored across 3 tools
Each tool targets a different scope: single-request estimation, aggregate usage analysis, and model comparison. They all relate to cost, but the descriptions make the boundaries clear enough for an agent to select correctly.
All three names follow the same verb_llm_noun pattern: estimate_llm_cost, analyze_llm_usage, compare_llm_models. The convention is predictable and consistent.
Three tools are well-scoped for a narrow cost-analysis server, and each serves a distinct purpose. No unnecessary tools are present.
The surface covers estimation, usage analysis, and model comparison, but an optimizer would benefit from a recommendation or pricing-catalog operation. As named, it analyzes costs rather than completing an optimization lifecycle.
Maintenance
Related MCP Connectors
Exact Claude API cost calc with real cache economics, plus a tiktoken-misuse scanner.
LLM API prices and AI agent cost estimates, verified daily. Read-only cost lookup tools.
Find AI model pricing, estimate token costs and compare offers. No API key required.
Track API spend, credit balances and runway across OpenAI, Anthropic, OpenRouter and 25 more.
Related MCP Servers
- AlicenseAqualityBmaintenanceScan codebases for LLM API calls and estimate monthly costs. Compare costs between git refs to catch cost regressions during code review.24MIT
- AlicenseAqualityBmaintenanceLocal-first dashboard + MCP server that parses Claude Code and Codex JSONL files into a SQLite cost / token tracker. Per-MCP and per-tool breakdown, session drill-down, dedup by request_id; never talks to vendor APIs5130 npm1MIT
- AlicenseAqualityBmaintenanceA local-first, multi-provider cost meter for LLM usage, exposed as MCP tools. Captures every call into a local SQLite ledger and lets any coding agent query spend, compare providers, and get recommendations β no cloud, no account. First-class support for Chinese providers (Qwen, DeepSeek) alongside Anthropic and OpenAI.76MIT
- AlicenseAqualityAmaintenanceToken usage and estimated cost for Claude Code, Codex, Cursor and 20 more AI coding agents, read locally from their session files. No API key, no telemetry.221AGPL 3.0