OptimToken

Compare LLM Models

compare-llm-models

Read-only

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.

Input Schema

Name	Required	Description
`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

Output Schema

Name	Required	Description	Default
`error`	No
`models`	Yes
`source`	Yes
`eloAsOf`	Yes
`dataAsOf`	No
`provenance`	No
`catalogSize`	Yes
`finopsBadge`	No
`volumeLabel`	Yes
`useCaseLabel`	Yes
`matchingCount`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 5, 2026

changedInput schema / properties / capability / description

Previous 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."

Changed10 schema fields changedAug 18, 2026

changedInput schema / properties / capability / description

Previous 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."

changedInput schema / properties / category / description

Previous 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."

changedInput schema / properties / minElo / description

Previous 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."

addedInput schema / properties / minElo / exclusiveMinimum
```
Added value: +0
```

changedInput schema / properties / useCasePreset / description

Previous 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"

addedOutput schema / properties / models / items / properties / batchApplied
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / models / items / properties / batchEligible
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / models / items / properties / cacheApplied
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / models / items / properties / cacheEligible
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / properties / models / items / required

Previous 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"
+]

Changed2 schema fields changedAug 18, 2026

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / properties / provenance

Added 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"
+}

Changed2 schema fields changedAug 18, 2026

changedOutput schema / $schema

Previous value: -"https://json-schema.org/draft/2020-12/schema"New value: +"http://json-schema.org/draft-07/schema#"

removedOutput schema / properties / provenance

Removed 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"
-}

Changed2 schema fields changedAug 17, 2026

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / properties / provenance

Added 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"
+}

First observedAug 17, 2026

TDQS

A4.4/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All OptimToken tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Compare LLM Models

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources