Array of conditions that must ALL be met for this tier to match (AND logic).
The default tier must have an empty conditions array. Conditional tiers should have one or more conditions that define when this tier's pricing applies.
Multiple conditions enable complex matching scenarios (e.g., "high input tokens AND low output tokens").
Unique identifier for the pricing tier
Whether this is the default tier. Every model must have exactly one default tier with priority 0 and no conditions.
The default tier serves as a fallback when no conditional tiers match, ensuring cost calculation always succeeds. It typically represents the base pricing for standard usage patterns.
Name of the pricing tier for display and identification purposes.
Examples: "Standard", "High Volume Tier", "Large Context", "Extended Context Tier"
Prices (USD) by usage type for this tier.
Common usage types: "input", "output", "total", "request", "image" Prices are specified in USD per unit (e.g., per token, per request, per second).
Example: {"input": 0.000003, "output": 0.000015} means $3 per million input tokens and $15 per million output tokens.
Priority for tier matching evaluation. Lower numbers = higher priority (evaluated first).
The default tier must always have priority 0. Conditional tiers should have priority 1, 2, 3, etc.
Example ordering:
This ensures more specific conditions are checked before general ones.
Pricing tier definition with conditional pricing based on usage thresholds.
Pricing tiers enable accurate cost tracking for LLM providers that charge different rates based on usage patterns. For example, some providers charge higher rates when context size exceeds certain thresholds.
How tier matching works:
Why priorities matter:
Every model must have exactly one default tier to ensure cost calculation always succeeds.