Compare LLM API and cloud compute pricing, estimate workload costs, pick a model within budget.
Scored across 5 tools
Four of the five tools concern LLM pricing, and at a glance compare-llm-models, compare-models-side-by-side, estimate-llm-cost, and recommend-llm-model could be confused. However, each description gives explicit routing cues (browse the field vs. weigh named models vs. exact token counts vs. get a pick), which resolves most ambiguity. Only minor boundary confusion remains.
All names use consistent kebab-case with a leading verb (compare-, estimate-, recommend-) followed by a clear noun phrase. The convention is predictable throughout with no mixed styles or casing.
Five tools is well-scoped for a pricing/comparison server, with each tool earning its place by covering a distinct query pattern. Nothing feels redundant or padded.
The LLM side is thoroughly covered (browse, side-by-side, exact costing, recommendation). The compute side, by contrast, gets only a single compare-compute-pricing tool with no cost-estimation or recommendation counterpart, a notable asymmetry agents must work around by reading the raw table.
Compare cloud compute instance pricing across AWS, Azure, GCP, DigitalOcean, OCI, OVH, and Alibaba. Filter by region, provider, vCPUs, memory, category, processor, or use case. All prices are Linux on-demand list prices in USD. Not every price column is live: provenance.priceTypes says which of each provider's price columns come from a live API, which are static constants, and which are unavailable, and provenance.staticPriceColumns lists the non-live ones outright. When you report a savings plan or reserved rate that appears there, say that it is a static estimate. IMPORTANT: Report all prices EXACTLY as returned. Do NOT add commentary or recommendations beyond the data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max instances to return (default: 20) | |
| region | No | Pricing region: us-east, us-west, europe, asia-pacific. Default: us-east | |
| sortBy | No | Sort by: price, vcpus, memory, pricePerVCPU. Default: price | |
| useCase | No | Use case. Must be one of these exactly (case-insensitive): Web App, Database, HPC, ML & AI, Dev/Test, Big Data. Any other string returns zero matches rather than an error. | |
| category | No | Instance category. Must be one of these exactly (case-insensitive): General Purpose, Compute Optimized, Memory Optimized, Storage Optimized, GPU / Accelerated, Burstable. Any other string returns zero matches rather than an error. | |
| maxVCPUs | No | Maximum number of vCPUs | |
| minVCPUs | No | Minimum number of vCPUs | |
| provider | No | Cloud provider. Must be one of these exactly (case-insensitive): AWS, Azure, GCP, DigitalOcean, OCI, OVH, Alibaba. Any other string returns zero matches rather than an error. | |
| maxMemory | No | Maximum memory in GiB | |
| minMemory | No | Minimum memory in GiB | |
| processor | No | Processor. Matched by exact equality (case-insensitive), so a partial value like 'H100' returns nothing. Known values: Intel, AMD, Graviton, Ampere, NVIDIA A100, NVIDIA H100, NVIDIA L4, NVIDIA T4, NVIDIA V100, NVIDIA Other. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| source | Yes | |
| instances | Yes | |
| provenance | No | |
| catalogSize | Yes | |
| matchingCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds critical behavioral details: provenance of price columns, static estimates, and the instruction to avoid commentary. This goes beyond annotations.
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 concise (6 sentences) and well-structured, front-loading the main purpose and then providing important caveats. Every sentence earns its place.
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?
Given the tool has 11 parameters with full schema descriptions and an output schema, the description provides sufficient context: scope, filtering, provenance handling, and exact reporting instructions. It is complete for agent use.
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 coverage is 100%, so parameters are already described. The description adds value by clarifying exact matching behavior for useCase, category, and processor, and noting defaults for region and sortBy.
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 clearly states the tool compares cloud compute instance pricing across multiple providers and lists them. It distinguishes from sibling tools (e.g., compare-llm-models) which are about LLM models, not compute pricing.
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 specifies when to use the tool (comparing compute pricing) and gives behavioral instructions (report prices exactly, mention static estimates). It does not explicitly exclude cases like Windows or spot pricing, but the context of 'Linux on-demand list prices' is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse and filter the whole LLM catalogue and get back a ranked table: price, quality (ELO), efficiency and capabilities. Use this when the user wants to SEE THE FIELD — 'show me models under $1/1M', 'which providers have vision models', 'list open-weight models above ELO 1300'. For a single PICK under a budget use recommend-llm-model; to weigh 2-4 NAMED models against each other use compare-models-side-by-side. Prices come from optimtoken.optimnow.io where reachable; the response's provenance says which tier served them and whether they are vendor-verified. Filter by provider, price tier (category), openness, capability, price range, or minimum ELO score. Optionally enrich with business metrics for a use case. Price tier and openness are independent: a model can be Frontier-priced and open-weight at once. Reports both list-price cost and the optimized cost achievable with prompt caching and the batch API. IMPORTANT: Report all prices, costs, and scores EXACTLY as returned. Do NOT add commentary, opinions, or recommendations beyond what the data shows. Present the results as a table and let the user draw conclusions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max models to return (default: 15) | |
| minElo | No | Minimum Chatbot Arena ELO score. Typical range 1000-1500; ~1400 is roughly frontier-class. Models with no ELO score never satisfy this. | |
| category | No | Price tier, matched by exact equality (case-insensitive): Frontier, Mid-tier, Budget, Image. This is cost only — self-hostability is the separate `openness` axis. | |
| openness | No | Filter by self-hostability, derived from the licence: Open source, Open weights, Proprietary, Unknown | |
| provider | No | Filter by provider name (e.g. 'OpenAI', 'Anthropic', 'Google') | |
| capability | No | Capability, matched by exact equality (case-insensitive): Text, Vision, Reasoning, Agents, Image Gen, Audio. Any other string returns zero matches. There is no Code capability: for what coding costs, use useCasePreset codingTask. | |
| volumePreset | No | Monthly request volume: 10k, 100k, or 1m. Default: 100k | |
| maxInputPrice | No | Max input price per 1M tokens in USD | |
| useCasePreset | No | Workload shape, which sets tokens per request: supportTicket (1.5k in / 500 out), knowledgeQA (2k / 800), meetingSummary (10k / 1.2k, batch-eligible), marketingContent (2.5k / 1.8k), codingTask (3k / 2k), invoiceProcessing (1.5k / 600, batch-eligible), callSummary (2k / 700, batch-eligible), agentWorkflow (6k / 3k). Default: supportTicket | |
| maxOutputPrice | No | Max output price per 1M tokens in USD |
| Name | Required | Description |
|---|---|---|
| error | No | |
| models | Yes | |
| source | Yes | |
| eloAsOf | Yes | |
| dataAsOf | No | |
| provenance | No | |
| catalogSize | Yes | |
| finopsBadge | No | |
| volumeLabel | Yes | |
| useCaseLabel | Yes | |
| matchingCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, openWorld), but the description adds real behavioral context beyond them: the price source (opttoken.optimnow.io), the `provenance` field indicating which tier served prices and whether they are vendor-verified, and that both list-price and optimized costs (prompt caching, batch API) are reported. It also sets an output constraint — report figures exactly, no added recommendations — which materially shapes agent behavior.
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?
Front-loaded with the core action and routing rules, then background detail; the use of caps and examples keeps it scannable. It is somewhat long and repeats the category/openness independence point that the schema also makes, so it falls short of perfectly 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?
An output schema exists, so return values need not be spelled out, and the description still notes the `provenance` field and the table shape. With 10 optional parameters, rich enums, and full schema coverage, nothing an agent needs to call this correctly is missing.
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 coverage is 100%, so the baseline is 3, but the description adds value by clarifying that price tier and openness are independent axes (a model can be Frontier-priced and open-weight simultaneously) and by enumerating the filter dimensions (provider, price tier, openness, capability, price range, min ELO). It doesn't add much on the preset enums, which the schema already details thoroughly.
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?
Opens with a specific verb+resource ('Browse and filter the whole LLM catalogue') and states exactly what comes back (ranked table with price, ELO, efficiency, capabilities). It also names the two sibling tools it is not (recommend-llm-model for a single pick, compare-models-side-by-side for 2-4 named models), so an agent can route without opening any schema.
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?
Gives explicit when-to-use conditions with concrete user phrasings ('show me models under $1/1M', 'which providers have vision models'), plus explicit alternatives and the conditions that select them. The boundary between this tool and recommend-llm-model / compare-models-side-by-side is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2-4 named LLM models against all 8 use-case profiles at a chosen monthly volume, showing list and optimized cost for each. Use when the user names specific models to weigh against each other, rather than filtering the whole catalogue. If they also supply their own token counts, or a volume outside 10k/100k/1m, use estimate-llm-cost instead. Every name is resolved against the catalogue and the result is reported: a name that matched nothing, matched several models, or duplicated an earlier pick is stated explicitly. IMPORTANT: Report all prices and costs EXACTLY as returned, and repeat any name-resolution warning to the user — a missing column is not the same as a model that costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| models | Yes | 2-4 model names to compare, e.g. ['GPT-4o', 'Claude Opus 5', 'Gemini 3.1 Pro'] | |
| volumePreset | No | Monthly request volume: 10k, 100k, or 1m. Default: 100k |
| Name | Required | Description |
|---|---|---|
| error | No | |
| models | Yes | |
| source | Yes | |
| volume | Yes | |
| eloAsOf | Yes | |
| dataAsOf | No | |
| provenance | No | |
| resolution | Yes | |
| volumeLabel | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint), the description adds critical behavior: name resolution reporting, exact price reproduction, warning propagation, and distinguishing missing columns from zero-cost models. No contradictions found.
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 efficient with three sentences plus an IMPORTANT instruction. It is front-loaded with the primary purpose and uses a natural flow. Slightly more structured (e.g., bullet points) could improve readability, but it is well within acceptable bounds.
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?
Given that an output schema exists (so return values are covered), the description covers purpose, usage boundaries, resolution behavior, and important agent instructions. No obvious gaps for the tool's complexity level.
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 100% already. The description adds meaningful context about model resolution behavior and volume presets, but does not significantly deepen parameter explanations since the schema already defines them well.
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 clearly states the tool compares 2-4 named LLM models against all 8 use-case profiles at a chosen monthly volume. It distinguishes itself from siblings by explicitly contrasting with filtering the whole catalogue and referencing estimate-llm-cost as an alternative.
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?
Explicitly says when to use ('when the user names specific models to weigh against each other') and when not to use ('if they also supply their own token counts, or a volume outside 10k/100k/1m, use estimate-llm-cost'). Provides clear decision boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cost a workload with EXACT numbers the caller supplies: arbitrary token counts per request and any monthly volume, not just the 10k/100k/1m presets the other cost tools use. Use this for 'about 800 in and 200 out, 4 million calls a month', or to price one named model across every use-case profile. To compare 2-4 named models like for like at a preset volume, use compare-models-side-by-side instead. Provide a model name to get detailed cost breakdowns, or compare costs across all use case presets. Each figure comes twice: list price, and the optimized price achievable with prompt caching and the batch API. IMPORTANT: Report all cost figures EXACTLY as returned. Do NOT add commentary or recommendations beyond the data.
| Name | Required | Description | Default |
|---|---|---|---|
| modelName | No | Model name, e.g. 'GPT-4o'. A partial name matches up to 5 models and ALL of them are costed. If omitted, the first 8 catalogue entries are used — that is catalogue order, not a quality ranking. | |
| monthlyVolume | No | Exact monthly request count, any integer (default 100,000). This tool does not take the 10k/100k/1m presets the other cost tools use. | |
| useCasePreset | No | Workload shape, which sets tokens per request: supportTicket (1.5k in / 500 out), knowledgeQA (2k / 800), meetingSummary (10k / 1.2k, batch-eligible), marketingContent (2.5k / 1.8k), codingTask (3k / 2k), invoiceProcessing (1.5k / 600, batch-eligible), callSummary (2k / 700, batch-eligible), agentWorkflow (6k / 3k). Default: every preset. | |
| customInputTokens | No | Custom input tokens per request. Must be supplied TOGETHER with customOutputTokens — either alone is ignored and the preset is used. A custom shape assumes no cacheable prefix and no batch eligibility, so its optimized cost equals its list cost. | |
| customOutputTokens | No | Custom output tokens per request. Must be supplied TOGETHER with customInputTokens — either alone is ignored and the preset is used. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| source | Yes | |
| volume | Yes | |
| eloAsOf | Yes | |
| dataAsOf | No | |
| modelCosts | Yes | |
| provenance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavioral traits beyond annotations: output includes both list and optimized prices, and instructions to report figures exactly as returned without adding commentary. No contradiction with annotations (readOnlyHint: true, destructiveHint: false).
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?
Well-structured and front-loaded: begins with the core purpose, then usage guidance, then parameter details. Every sentence adds value without redundancy. Length is appropriate for the complexity.
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?
Given the output schema exists, the description covers purpose, usage guidelines, parameter semantics, and behavioral instructions comprehensively. It leaves no gaps for an agent to misinterpret how to invoke the tool correctly.
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?
Adds significant meaning beyond the schema: explains that custom tokens must be supplied together, custom shape assumes no cacheable prefix or batch eligibility, modelName partial matching matches up to 5 models, monthlyVolume default is 100k and doesn't use presets, and useCasePreset defaults to every preset. Schema coverage is 100%, but description compensates with essential context.
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 clearly states the tool's purpose: costing workloads with exact token counts and monthly volume, distinguishing itself from sibling tools that use preset volumes. It uses specific verbs like 'cost' and 'price' and explicitly names the alternative compare-models-side-by-side.
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?
Provides explicit guidance on when to use this tool (exact numbers, custom tokens) and when to use a sibling (compare-models-side-by-side for comparing models at preset volumes). It also explains how to use it with model names or across presets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pick a model. Returns a ranked top 3 for one workload under optional constraints, each with a per-constraint satisfied/violated breakdown as the evidence. Use this when the user wants an ANSWER rather than a table — 'what should I use for support tickets under $500 a month'. To browse or filter the whole catalogue instead, use compare-llm-models. Constraints: (monthly budget, minimum ELO, required capability, self-hostability). Returns a top 3 as structured facts — efficiency rank, ELO, list and optimized cost, FinOps flag, volatility, and a per-constraint satisfied/violated breakdown. When nothing satisfies every constraint the query is reported as over-constrained and the nearest misses are returned instead, each carrying the constraint it failed. IMPORTANT: Report the returned facts EXACTLY. The ranking is already computed — do not re-rank, and do not present a near miss as if it satisfied the constraints.
| Name | Required | Description | Default |
|---|---|---|---|
| minElo | No | Minimum Chatbot Arena ELO score. Typical range 1000-1500; ~1400 is roughly frontier-class. Models with no ELO score never satisfy this. | |
| openness | No | Require a self-hostability bucket, derived from the licence: Open source, Open weights, Proprietary, Unknown | |
| volumePreset | No | Monthly request volume: 10k, 100k, or 1m. Default: 100k | |
| useCasePreset | Yes | Workload shape, which sets tokens per request: supportTicket (1.5k in / 500 out), knowledgeQA (2k / 800), meetingSummary (10k / 1.2k, batch-eligible), marketingContent (2.5k / 1.8k), codingTask (3k / 2k), invoiceProcessing (1.5k / 600, batch-eligible), callSummary (2k / 700, batch-eligible), agentWorkflow (6k / 3k). | |
| maxMonthlyBudget | No | Maximum monthly budget in USD at the given volume. Tested against the LIST-price monthly cost, not the caching/batch-optimized cost. | |
| requiredCapability | No | Capability the model must have: Text, Vision, Reasoning, Agents, Image Gen, Audio. There is no Code capability: for coding, pass useCasePreset codingTask. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| source | Yes | |
| volume | Yes | |
| eloAsOf | Yes | |
| dataAsOf | No | |
| nearMisses | Yes | |
| provenance | No | |
| catalogSize | Yes | |
| rankedCount | Yes | |
| volumeLabel | Yes | |
| useCaseLabel | Yes | |
| candidateCount | Yes | |
| overConstrained | Yes | |
| recommendations | Yes | |
| roiCalculatorUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, it discloses non-obvious behavior: the top-3 ranking with per-constraint satisfied/violated evidence, the over-constrained fallback that returns nearest misses each carrying the failed constraint, and an explicit instruction not to re-rank or misrepresent near misses. This edge-case and output-integrity context is exactly what annotations cannot convey.
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?
Front-loaded with the core answer-tool framing and routing rule, and the IMPORTANT reporting caveat is well placed at the end. Minor waste: the top-3 plus per-constraint breakdown is stated twice (opening sentence and the 'Returns a top 3 as structured facts' sentence).
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 6-parameter tool with an output schema, the description covers routing, constraint semantics, the over-constrained failure mode, and how to report results. The output schema handles field-level returns, so nothing an agent needs to call or interpret this correctly is missing.
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 100%, so the schema already documents every parameter including enum semantics and ELO ranges. The description restates the constraint set (budget, ELO, capability, self-hostability) and adds a '$500 a month' illustration but no syntax or format detail beyond the schema, so the baseline 3 applies.
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+resource ('Pick a model... returns a ranked top 3 for one workload') and explicitly distinguishes itself from the sibling compare-llm-models ('To browse or filter the whole catalogue instead, use compare-llm-models'). An agent can route between the two without opening either schema.
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?
Gives an explicit when-to-use rule ('when the user wants an ANSWER rather than a table') with a concrete example query, and names the alternative tool plus the condition that selects it. Nothing 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare-llm-models1 field changedInput schema / properties / capability / descriptionPrevious value: -"Capability, matched by exact equality (case-insensitive): Text, Vision, Code, Reasoning, Agents, Image Gen, Audio. Any other string returns zero matches."New value: +"Capability, matched by exact equality (case-insensitive): Text, Vision, Reasoning, Agents, Image Gen, Audio. Any other string returns zero matches. There is no Code capability: for what coding costs, use useCasePreset codingTask."recommend-llm-model1 field changedInput schema / properties / requiredCapability / descriptionPrevious value: -"Capability the model must have: Text, Vision, Code, Reasoning, Agents, Image Gen, Audio"New value: +"Capability the model must have: Text, Vision, Reasoning, Agents, Image Gen, Audio. There is no Code capability: for coding, pass useCasePreset codingTask."compare-compute-pricing4 fields changedInput schema / properties / category / descriptionPrevious value: -"Instance category: General Purpose, Compute Optimized, Memory Optimized, Storage Optimized, GPU / Accelerated, Burstable"New value: +"Instance category. Must be one of these exactly (case-insensitive): General Purpose, Compute Optimized, Memory Optimized, Storage Optimized, GPU / Accelerated, Burstable. Any other string returns zero matches rather than an error."Input schema / properties / processor / descriptionPrevious value: -"Processor filter: Intel, AMD, Graviton, Ampere, NVIDIA A100, NVIDIA H100, etc."New value: +"Processor. Matched by exact equality (case-insensitive), so a partial value like 'H100' returns nothing. Known values: Intel, AMD, Graviton, Ampere, NVIDIA A100, NVIDIA H100, NVIDIA L4, NVIDIA T4, NVIDIA V100, NVIDIA Other."Input schema / properties / provider / descriptionPrevious value: -"Cloud provider: AWS, Azure, GCP, DigitalOcean, OCI, OVH, Alibaba"New value: +"Cloud provider. Must be one of these exactly (case-insensitive): AWS, Azure, GCP, DigitalOcean, OCI, OVH, Alibaba. Any other string returns zero matches rather than an error."Input schema / properties / useCase / descriptionPrevious value: -"Use case filter: Web App, Database, HPC, ML & AI, Dev/Test, Big Data"New value: +"Use case. Must be one of these exactly (case-insensitive): Web App, Database, HPC, ML & AI, Dev/Test, Big Data. Any other string returns zero matches rather than an error."compare-llm-models10 fields changedInput schema / properties / capability / descriptionPrevious value: -"Filter by capability: Text, Vision, Code, Reasoning, Agents, Image Gen, Audio"New value: +"Capability, matched by exact equality (case-insensitive): Text, Vision, Code, Reasoning, Agents, Image Gen, Audio. Any other string returns zero matches."Input schema / properties / category / descriptionPrevious value: -"Filter by price tier: Frontier, Mid-tier, Budget, Image"New value: +"Price tier, matched by exact equality (case-insensitive): Frontier, Mid-tier, Budget, Image. This is cost only — self-hostability is the separate `openness` axis."Input schema / properties / minElo / descriptionPrevious value: -"Minimum ELO score (quality benchmark from Chatbot Arena)"New value: +"Minimum Chatbot Arena ELO score. Typical range 1000-1500; ~1400 is roughly frontier-class. Models with no ELO score never satisfy this."Input schema / properties / minElo / exclusiveMinimumAdded value: +0Input schema / properties / useCasePreset / descriptionPrevious value: -"Use case for cost estimation. Default: supportTicket"New value: +"Workload shape, which sets tokens per request: supportTicket (1.5k in / 500 out), knowledgeQA (2k / 800), meetingSummary (10k / 1.2k, batch-eligible), marketingContent (2.5k / 1.8k), codingTask (3k / 2k), invoiceProcessing (1.5k / 600, batch-eligible), callSummary (2k / 700, batch-eligible), agentWorkflow (6k / 3k). Default: supportTicket"Output schema / properties / models / items / properties / batchAppliedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / models / items / properties / batchEligibleAdded value: +{
+ "type": "boolean"
+}Output schema / properties / models / items / properties / cacheAppliedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / models / items / properties / cacheEligibleAdded value: +{
+ "type": "boolean"
+}Output schema / properties / models / items / requiredPrevious value: -[
- "provider",
- "model",
- "inputPricePer1M",
- "outputPricePer1M",
- "contextWindow",
- "category",
- "capabilities",
- "openness",
- "efficiencyScore",
- "useCaseCost",
- "optimizedUseCaseCost",
- "monthlyBudget",
- "optimizedMonthlyBudget",
- "volatilityRisk",
- "isFinOpsFriendly"
-]New value: +[
+ "provider",
+ "model",
+ "inputPricePer1M",
+ "outputPricePer1M",
+ "contextWindow",
+ "category",
+ "capabilities",
+ "openness",
+ "efficiencyScore",
+ "useCaseCost",
+ "optimizedUseCaseCost",
+ "monthlyBudget",
+ "optimizedMonthlyBudget",
+ "volatilityRisk",
+ "isFinOpsFriendly",
+ "batchEligible",
+ "cacheEligible",
+ "batchApplied",
+ "cacheApplied"
+]compare-models-side-by-sideestimate-llm-cost11 fields changedInput schema / properties / customInputTokens / descriptionPrevious value: -"Custom input tokens per request (overrides preset)"New value: +"Custom input tokens per request. Must be supplied TOGETHER with customOutputTokens — either alone is ignored and the preset is used. A custom shape assumes no cacheable prefix and no batch eligibility, so its optimized cost equals its list cost."Input schema / properties / customOutputTokens / descriptionPrevious value: -"Custom output tokens per request (overrides preset)"New value: +"Custom output tokens per request. Must be supplied TOGETHER with customInputTokens — either alone is ignored and the preset is used."Input schema / properties / modelName / descriptionPrevious value: -"Model name to estimate costs for (e.g. 'GPT-4o', 'Claude Sonnet 4'). If omitted, shows top models."New value: +"Model name, e.g. 'GPT-4o'. A partial name matches up to 5 models and ALL of them are costed. If omitted, the first 8 catalogue entries are used — that is catalogue order, not a quality ranking."Input schema / properties / monthlyVolume / descriptionPrevious value: -"Custom monthly volume (default: 100,000)"New value: +"Exact monthly request count, any integer (default 100,000). This tool does not take the 10k/100k/1m presets the other cost tools use."Input schema / properties / useCasePreset / descriptionPrevious value: -"Use case preset. Default: all presets."New value: +"Workload shape, which sets tokens per request: supportTicket (1.5k in / 500 out), knowledgeQA (2k / 800), meetingSummary (10k / 1.2k, batch-eligible), marketingContent (2.5k / 1.8k), codingTask (3k / 2k), invoiceProcessing (1.5k / 600, batch-eligible), callSummary (2k / 700, batch-eligible), agentWorkflow (6k / 3k). Default: every preset."Output schema / properties / modelCosts / items / properties / costs / items / properties / batchAppliedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / modelCosts / items / properties / costs / items / properties / batchEligibleAdded value: +{
+ "type": "boolean"
+}Output schema / properties / modelCosts / items / properties / costs / items / properties / cacheAppliedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / modelCosts / items / properties / costs / items / properties / cacheEligibleAdded value: +{
+ "type": "boolean"
+}Output schema / properties / modelCosts / items / properties / costs / items / properties / savingsPctAdded value: +{
+ "type": "number"
+}Output schema / properties / modelCosts / items / properties / costs / items / requiredPrevious value: -[
- "useCase",
- "inputTokens",
- "outputTokens",
- "perRequest",
- "monthly",
- "perRequestOptimized",
- "monthlyOptimized"
-]New value: +[
+ "useCase",
+ "inputTokens",
+ "outputTokens",
+ "perRequest",
+ "monthly",
+ "perRequestOptimized",
+ "monthlyOptimized",
+ "savingsPct",
+ "batchEligible",
+ "cacheEligible",
+ "batchApplied",
+ "cacheApplied"
+]recommend-llm-modelcompare-compute-pricing5 fields changedInput schema / properties / regionAdded value: +{
+ "description": "Pricing region: us-east, us-west, europe, asia-pacific. Default: us-east",
+ "enum": [
+ "us-east",
+ "us-west",
+ "europe",
+ "asia-pacific"
+ ],
+ "type": "string"
+}Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / properties / provenanceAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "catalogTotal": {
+ "type": "number"
+ },
+ "catalogueIsSubset": {
+ "type": "boolean"
+ },
+ "dataAsOf": {
+ "type": "string"
+ },
+ "fallbackReason": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "notice": {
+ "type": "string"
+ },
+ "priceTypes": {
+ "additionalProperties": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "region": {
+ "type": "string"
+ },
+ "servedFromCacheAgeMs": {
+ "type": "number"
+ },
+ "source": {
+ "type": "string"
+ },
+ "sourceRegions": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "sources": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "staticPriceColumns": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "tier": {
+ "type": "number"
+ },
+ "unappliedFilters": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "unavailablePriceColumns": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "upstreamErrors": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "upstreamSchemaVersion": {
+ "type": "string"
+ },
+ "upstreamTimestamp": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tier",
+ "source",
+ "label",
+ "region",
+ "staticPriceColumns",
+ "unavailablePriceColumns"
+ ],
+ "type": "object"
+}Output schema / properties / sourceAdded value: +{
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "instances",
- "matchingCount",
- "catalogSize"
-]New value: +[
+ "instances",
+ "matchingCount",
+ "catalogSize",
+ "source"
+]compare-llm-models2 fields changedOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / properties / provenanceAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "catalogTotal": {
+ "type": "number"
+ },
+ "dataAsOf": {
+ "type": "string"
+ },
+ "eloAsOf": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "notice": {
+ "type": "string"
+ },
+ "pricesVerified": {
+ "type": "boolean"
+ },
+ "source": {
+ "type": "string"
+ },
+ "tier": {
+ "type": "number"
+ },
+ "upstreamSchemaVersion": {
+ "type": "string"
+ },
+ "upstreamSource": {
+ "type": "string"
+ },
+ "upstreamTimestamp": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tier",
+ "source",
+ "label",
+ "pricesVerified",
+ "eloAsOf"
+ ],
+ "type": "object"
+}estimate-llm-cost2 fields changedOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / properties / provenanceAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "catalogTotal": {
+ "type": "number"
+ },
+ "dataAsOf": {
+ "type": "string"
+ },
+ "eloAsOf": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "notice": {
+ "type": "string"
+ },
+ "pricesVerified": {
+ "type": "boolean"
+ },
+ "source": {
+ "type": "string"
+ },
+ "tier": {
+ "type": "number"
+ },
+ "upstreamSchemaVersion": {
+ "type": "string"
+ },
+ "upstreamSource": {
+ "type": "string"
+ },
+ "upstreamTimestamp": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tier",
+ "source",
+ "label",
+ "pricesVerified",
+ "eloAsOf"
+ ],
+ "type": "object"
+}compare-compute-pricing5 fields changedInput schema / properties / regionRemoved value: -{
- "description": "Pricing region: us-east, us-west, europe, asia-pacific. Default: us-east",
- "enum": [
- "us-east",
- "us-west",
- "europe",
- "asia-pacific"
- ],
- "type": "string"
-}Output schema / $schemaPrevious value: -"https://json-schema.org/draft/2020-12/schema"New value: +"http://json-schema.org/draft-07/schema#"Output schema / properties / provenanceRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "catalogTotal": {
- "type": "number"
- },
- "catalogueIsSubset": {
- "type": "boolean"
- },
- "dataAsOf": {
- "type": "string"
- },
- "fallbackReason": {
- "type": "string"
- },
- "label": {
- "type": "string"
- },
- "notice": {
- "type": "string"
- },
- "priceTypes": {
- "additionalProperties": {
- "additionalProperties": {
- "type": "string"
- },
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "region": {
- "type": "string"
- },
- "servedFromCacheAgeMs": {
- "type": "number"
- },
- "source": {
- "type": "string"
- },
- "sourceRegions": {
- "additionalProperties": {
- "type": "string"
- },
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "sources": {
- "additionalProperties": {
- "type": "string"
- },
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "staticPriceColumns": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "tier": {
- "type": "number"
- },
- "unappliedFilters": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "unavailablePriceColumns": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "upstreamErrors": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "upstreamSchemaVersion": {
- "type": "string"
- },
- "upstreamTimestamp": {
- "type": "string"
- }
- },
- "required": [
- "tier",
- "source",
- "label",
- "region",
- "staticPriceColumns",
- "unavailablePriceColumns"
- ],
- "type": "object"
-}Output schema / properties / sourceRemoved value: -{
- "type": "string"
-}Output schema / requiredPrevious value: -[
- "instances",
- "matchingCount",
- "catalogSize",
- "source"
-]New value: +[
+ "instances",
+ "matchingCount",
+ "catalogSize"
+]compare-llm-models2 fields changedOutput schema / $schemaPrevious value: -"https://json-schema.org/draft/2020-12/schema"New value: +"http://json-schema.org/draft-07/schema#"Output schema / properties / provenanceRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "catalogTotal": {
- "type": "number"
- },
- "dataAsOf": {
- "type": "string"
- },
- "eloAsOf": {
- "type": "string"
- },
- "label": {
- "type": "string"
- },
- "notice": {
- "type": "string"
- },
- "pricesVerified": {
- "type": "boolean"
- },
- "source": {
- "type": "string"
- },
- "tier": {
- "type": "number"
- },
- "upstreamSchemaVersion": {
- "type": "string"
- },
- "upstreamSource": {
- "type": "string"
- },
- "upstreamTimestamp": {
- "type": "string"
- }
- },
- "required": [
- "tier",
- "source",
- "label",
- "pricesVerified",
- "eloAsOf"
- ],
- "type": "object"
-}estimate-llm-cost2 fields changedOutput schema / $schemaPrevious value: -"https://json-schema.org/draft/2020-12/schema"New value: +"http://json-schema.org/draft-07/schema#"Output schema / properties / provenanceRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "catalogTotal": {
- "type": "number"
- },
- "dataAsOf": {
- "type": "string"
- },
- "eloAsOf": {
- "type": "string"
- },
- "label": {
- "type": "string"
- },
- "notice": {
- "type": "string"
- },
- "pricesVerified": {
- "type": "boolean"
- },
- "source": {
- "type": "string"
- },
- "tier": {
- "type": "number"
- },
- "upstreamSchemaVersion": {
- "type": "string"
- },
- "upstreamSource": {
- "type": "string"
- },
- "upstreamTimestamp": {
- "type": "string"
- }
- },
- "required": [
- "tier",
- "source",
- "label",
- "pricesVerified",
- "eloAsOf"
- ],
- "type": "object"
-}compare-compute-pricing5 fields changedInput schema / properties / regionAdded value: +{
+ "description": "Pricing region: us-east, us-west, europe, asia-pacific. Default: us-east",
+ "enum": [
+ "us-east",
+ "us-west",
+ "europe",
+ "asia-pacific"
+ ],
+ "type": "string"
+}Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / properties / provenanceAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "catalogTotal": {
+ "type": "number"
+ },
+ "catalogueIsSubset": {
+ "type": "boolean"
+ },
+ "dataAsOf": {
+ "type": "string"
+ },
+ "fallbackReason": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "notice": {
+ "type": "string"
+ },
+ "priceTypes": {
+ "additionalProperties": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "region": {
+ "type": "string"
+ },
+ "servedFromCacheAgeMs": {
+ "type": "number"
+ },
+ "source": {
+ "type": "string"
+ },
+ "sourceRegions": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "sources": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "staticPriceColumns": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "tier": {
+ "type": "number"
+ },
+ "unappliedFilters": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "unavailablePriceColumns": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "upstreamErrors": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "upstreamSchemaVersion": {
+ "type": "string"
+ },
+ "upstreamTimestamp": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tier",
+ "source",
+ "label",
+ "region",
+ "staticPriceColumns",
+ "unavailablePriceColumns"
+ ],
+ "type": "object"
+}Output schema / properties / sourceAdded value: +{
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "instances",
- "matchingCount",
- "catalogSize"
-]New value: +[
+ "instances",
+ "matchingCount",
+ "catalogSize",
+ "source"
+]compare-llm-models2 fields changedOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / properties / provenanceAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "catalogTotal": {
+ "type": "number"
+ },
+ "dataAsOf": {
+ "type": "string"
+ },
+ "eloAsOf": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "notice": {
+ "type": "string"
+ },
+ "pricesVerified": {
+ "type": "boolean"
+ },
+ "source": {
+ "type": "string"
+ },
+ "tier": {
+ "type": "number"
+ },
+ "upstreamSchemaVersion": {
+ "type": "string"
+ },
+ "upstreamSource": {
+ "type": "string"
+ },
+ "upstreamTimestamp": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tier",
+ "source",
+ "label",
+ "pricesVerified",
+ "eloAsOf"
+ ],
+ "type": "object"
+}estimate-llm-cost2 fields changedOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / properties / provenanceAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "catalogTotal": {
+ "type": "number"
+ },
+ "dataAsOf": {
+ "type": "string"
+ },
+ "eloAsOf": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "notice": {
+ "type": "string"
+ },
+ "pricesVerified": {
+ "type": "boolean"
+ },
+ "source": {
+ "type": "string"
+ },
+ "tier": {
+ "type": "number"
+ },
+ "upstreamSchemaVersion": {
+ "type": "string"
+ },
+ "upstreamSource": {
+ "type": "string"
+ },
+ "upstreamTimestamp": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tier",
+ "source",
+ "label",
+ "pricesVerified",
+ "eloAsOf"
+ ],
+ "type": "object"
+}compare-compute-pricingcompare-llm-modelsestimate-llm-costLLM API prices across 70+ providers: cheapest offer, comparisons, history and cost estimates.
Find AI model pricing, estimate token costs and compare offers. No API key required.
Compare LLM API prices, search models and providers, and access reviewed benchmark results.
Daily LLM API prices, cost estimates and automation ROI tools from shurco.ai
Add one secure layer between your agents and this server.