Core Concepts
A billable metric is simply a measurable unit. It doesn’t have a price - that comes later when you create plans. Each metric belongs to exactly one product and specifies:- Name - What customers see (e.g., “Input Tokens”, “GPU Hours”)
- Unit - How it’s measured (e.g., “tokens”, “hours”, “GB”)
- Aggregation - How to sum usage (currently SUM only)
How Metrics Work
Billable metrics track variable consumption through events. Perfect for:- LLM tokens processed
- Compute hours consumed
- Data transferred
- Queries executed
For fixed charges like platform fees, subscriptions, or setup costs, use Fees instead of billable metrics.
Real-World Examples
LLM Service Separate input and output for different pricing:- Metric: “Input Tokens” (unit: “tokens”)
- Metric: “Output Tokens” (unit: “tokens”)
- Metric: “Fine-tuning Hours” (unit: “hours”)
- Metric: “Storage” (unit: “GB-hours”)
- Metric: “Compute” (unit: “vCPU-hours”)
- Metric: “Queries” (unit: “queries”)
- Metric: “Minutes Processed” (usage mode, unit: “minutes”)
- Metric: “Bandwidth” (usage mode, unit: “GB”)
- Metric: “Transcoding Jobs” (usage mode, unit: “jobs”)
Design Considerations
Granularity matters. Too many metrics complicate billing. Too few limit pricing flexibility. Think about pricing evolution. Can’t split a metric later without migrating customers. Customer clarity. Metrics should be intuitive and easy to understand on invoices.Common Patterns
Tiered Resources Create separate metrics for different resource classes:- “Standard Compute”
- “Premium Compute”
- “GPU Compute”
- “Data Ingress”
- “Data Egress”
- “SD Video Processing”
- “HD Video Processing”
- “4K Video Processing”
Reporting Usage
Once metrics are defined, you’ll report usage through events. Each event includes:- Metric ID
- Quantity consumed
- Customer ID
- Timestamp
- Optional metadata
Next Steps
After defining metrics:- Create plans to group your offerings
- Set prices for each metric
- Report usage as customers consume resources