Compare LLM API and cloud compute pricing, estimate workload costs, pick a model within budget.
Scored across 5 tools
The tools have overlapping LLM pricing domains but each has a clearly distinct purpose, and descriptions explicitly cross-reference when to use which (e.g., browse vs. side-by-side vs. exact cost vs. recommendation). This explicit guidance eliminates ambiguity in tool selection.
All names follow a consistent kebab-case verb-noun pattern (compare-, estimate-, recommend-). The verb varies appropriately with the action, and the noun phrases are descriptive and predictable.
Five tools are well-scoped for a cloud/LLM pricing and cost optimization server. Each tool has a distinct, non-redundant role, covering compute pricing plus four complementary LLM cost functions.
The LLM side is well-covered with browsing, side-by-side comparison, exact cost estimation, and recommendation. Compute coverage is thinner with only a comparison tool, lacking cost estimation or recommendation for compute, but this may be intentional given the server's token-focused purpose.
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; a savings-plan or reserved rate that appears there is a static estimate, not a live quote. Prices are returned as the catalogue serves them and dated by provenance.
| 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 cover the safety profile (readOnly, not destructive, openWorld), and the description goes well beyond them: it discloses that prices are Linux on-demand list prices in USD. Most valuably, it warns that some price columns are not live and points to provenance.priceTypes/staticPriceColumns, flagging that savings-plan or reserved rates shown there are static estimates, not live quotes. This is exactly the kind of caveat that prevents an agent from misreporting data.
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 purpose and provider list, then filters, then a critical price-semantics caveat. Information-dense with no wasted preamble, though the provenance clause is long and slightly hard to parse in one pass.
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?
With annotations, a 100%-covered schema, and an output schema present, the description supplies the remaining context an agent needs, chiefly the price provenance caveat. Nothing essential to correct interpretation 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 schema already documents all 11 parameters thoroughly, including enum values and the zero-match behavior for invalid strings. The description adds little per-parameter meaning beyond the cross-cutting price-type context, so baseline 3 is appropriate.
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?
Names a specific verb (Compare) and resource (cloud compute instance pricing) and enumerates the seven providers covered. It is clearly distinct from its LLM-oriented siblings, so an agent can route here for infrastructure pricing without ambiguity.
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 usage by listing the filters (region, provider, vCPUs, memory, category, processor, use case) an agent would apply, but never states when to prefer this over alternatives or any exclusions. This is inferred rather than explicit guidance.
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. Prices, costs and scores are final as returned: rounded and ranked server-side, and dated by provenance. The text block is a numbered table of the same figures.
| 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 declare readOnlyHint/openWorldHint, but the description adds real behavioral context beyond them: prices come from optimtoken.optimnow.io 'where reachable', the `provenance` field reports which tier served the data and whether it is vendor-verified, values are 'rounded and ranked server-side', and both list-price and optimized (caching/batch) costs are reported. It does not cover output size limits or pagination behavior beyond `limit`, which is why this is a 4 rather than a 5.
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 dense single block, but it is front-loaded: purpose first, then when-to-use examples, then sibling routing, then data provenance. Nearly every sentence carries information, though the 'price tier and openness are independent' sentence duplicates the `category` schema description and is the one clearly redundant line.
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 re-explained, and annotations cover the safety profile. What the description must supply for a 10-parameter, externally-sourced pricing tool — data provenance, server-side rounding/ranking, and the dual list/optimized cost model — it supplies, and it even notes the text block mirrors the table.
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% and the schema itself is unusually rich — it already explains the category/openness independence, the enum values, and typical ELO ranges. The description restates the filter dimensions ('filter by provider, price tier, openness, capability, price range, or minimum ELO') and repeats the category/openness independence note almost verbatim, adding little the agent cannot read in the schema. Baseline 3 is correct.
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 — 'browse and filter the whole LLM catalogue' — and immediately specifies the shape of the result: 'a ranked table: price, quality (ELO), efficiency and capabilities.' It goes further by naming the sibling tools it is not (recommend-llm-model, compare-models-side-by-side), so an agent can distinguish it 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?
It gives explicit when-to-use with concrete trigger utterances ('show me models under $1/1M', 'which providers have vision models') and then states the exclusions with alternatives: recommend-llm-model for a single pick under a budget, compare-models-side-by-side for 2-4 named models. Both the positive case and the routing boundaries are spelled out.
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 outcome is reported in resolution and in the text: a name that matched nothing, matched several models, or duplicated an earlier pick is stated explicitly, and such a name gets no column rather than a zero cost. Prices and costs are final as returned: rounded server-side and dated by provenance.
| 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?
Annotations already declare readOnly/openWorld/non-destructive, and the description goes well beyond them: it explains per-name resolution outcomes (unmatched, ambiguous, duplicated), that such a name yields no column rather than a zero cost, that prices are rounded server-side and dated by `provenance`, and that outcomes surface in a `resolution` field. That is real behavioral context an agent could not infer from 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?
Front-loaded with purpose and the key routing rule in the first two sentences, then resolution semantics and pricing caveats. Every sentence carries information, though the resolution/reporting sentence is dense and slightly run-on relative to the rest.
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 enumerated; instead the description covers the parts an agent must know — model resolution semantics, the no-column-on-failure rule, preset-restricted volume, and pricing provenance. Nothing material is missing for correct invocation.
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 both parameters (the 2-4 name array with example and the volumePreset enum with default) — baseline 3. The description adds genuine meaning on top: names are resolved against the catalogue with explicit failure modes, and the volume-preset constraint is tied to a routing decision (outside 10k/100k/1m, use another tool).
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 (compare), resource (2-4 named LLM models), and the scope it operates over (all 8 use-case profiles at a chosen monthly volume, returning list and optimized cost). This is clearly distinguishable from siblings like recommend-llm-model and estimate-llm-cost without opening a 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?
Explicitly says when to use it (user names specific models to weigh against each other, rather than filtering the whole catalogue) and when not to, naming the alternative: 'If they also supply their own token counts, or a volume outside 10k/100k/1m, use estimate-llm-cost instead.' Both the positive and negative selection conditions are spelled out.
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. Cost figures are final as returned: rounded server-side and dated by provenance, with the lever behind each saving, or the reason there is none, named in the text.
| 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?
Annotations already cover safety (readOnlyHint, destructiveHint=false, openWorldHint), and the description adds real behavioral context beyond them: each figure returns both a list price and an optimized price achievable via prompt caching/batch API, rounded server-side and dated by provenance, with the saving lever named. That is genuinely useful disclosure.
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?
Dense but front-loaded, with the exact-numbers-vs-presets distinction and the sibling alternative placed early. Every sentence carries content, though the description is on the longer side.
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 zero-required-param pricing tool with a full output schema, the description covers purpose, usage routing, parameter behavior, and return-value semantics sufficiently. An agent can select and invoke it correctly without opening the schema.
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 conceptual meaning beyond the schema: it frames the model-name path as yielding detailed breakdowns versus comparing across all presets, and clarifies the custom-token path implied by the schema.
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 (cost a workload) and immediately distinguishes itself from sibling cost tools by emphasizing EXACT caller-supplied numbers versus the 10k/100k/1m presets. It also carves out the comparison case by naming compare-models-side-by-side directly.
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?
Explicit when-to-use ('about 800 in and 200 out, 4 million calls a month') and explicit when-not/alternative ('To compare 2-4 named models like for like at a preset volume, use compare-models-side-by-side instead'). 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.
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, recommendations is empty, and the nearest misses are returned in nearMisses instead, each carrying the constraint it failed and flagged as a miss in the text. The ranking is computed server-side and is final.
| 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?
Annotations already cover the safety profile (readOnly, non-destructive, open-world), so the bar is lower, yet the description adds substantial behavior: list-price vs optimized cost is what's tested, over-constrained queries return empty recommendations plus nearMisses flagged as misses, and the ranking is server-side and final. It also enumerates the constraint dimensions, which is not derivable from 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?
Front-loaded with purpose, then routing, then constraints, then failure mode — a good order. It loses a point for redundancy: the 'top 3' return is described twice ('Returns a ranked top 3...' and 'Returns a top 3 as structured facts — efficiency rank, ELO...'), which overlaps with the output schema.
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?
Output schema exists so return fields need not be explained, yet the description still covers the failure path (over-constrained → nearMisses) and the cost basis, leaving no gap an agent needs to call this 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?
Schema coverage is 100%, so baseline is 3, but the description adds value by naming the four constraint dimensions (monthly budget, minimum ELO, required capability, self-hostability) that drive the per-constraint satisfied/violated breakdown, and by clarifying that minElo is a hard filter rather than a soft preference.
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 ('Pick a model') and immediately scopes it: 'ranked top 3 for one workload under optional constraints.' It explicitly names and distinguishes the sibling compare-llm-models, so an agent can route correctly without reading 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 with a concrete example ('what should I use for support tickets under $500 a month') and an explicit when-not rule pointing at the alternative tool for browsing/filtering the catalogue.
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-costCompare AI model prices and estimate workload costs with four read-only tools. No account needed.
LLM 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.
Add one secure layer between your agents and this server.
