# Create Pricing Models & Products Real-world AI pricing models rarely stay simple for long. A customer might want a flat recurring fee plus overages on tokens, or volume discounts that kick in at specific tiers, or per-feature charges alongside a base subscription. Most billing engines force you to pick one shape and live with it; Revenium's product configuration is built from a small set of composable building blocks, which means almost any pricing model you can design fits into the same structure without custom code. This page is a reference for every pricing capability available on a product. Skim it once to understand what's possible, then come back to the relevant section when you're configuring a specific pricing model. ### :dollar-sign: The Two Pricing Primitives Two building blocks cover the pricing surface. Almost every pricing model you can design is a combination of these: * **Pricing Tiers** - the most common building block. Usage ranges with a per-unit rate and/or a fixed per-tier charge. * **Metering Elements** - custom units of usage beyond transaction counts. Tokens, pages, characters, minutes, credits, or anything else your product consumes. ### :stairs: Pricing Tiers - The Default Building Block Tiers are how most pricing models express the basic shape of "a certain amount included, then charged per unit above that." Each tier defines a usage range and the price within that range: * **Tier Name** - your internal label (e.g. "First 1,000", "1,000+"). * **Tier Max Value** - the upper bound. The final tier is always Unlimited. * **Unit Rate** - price per unit within this tier. * **Fixed Cost / Tier** - an optional flat charge applied when a customer enters this tier, on top of unit rates. A simple two-tier structure might look like: first 1,000 units at $1.50 per unit, then 1,001+ at $1.35 per unit. Tiers can be stacked as deep as you need, and you get two distinct charging modes to choose between: * **Charge per tier** - each transaction is priced at the rate of the tier it falls into. Transaction 1,200 is charged at the overage rate; transaction 800 is still at the included-unit rate. * **Highest tier reached** - once a customer reaches a higher tier during the period, all their transactions for that period are re-rated at the higher tier's price. Per-tier pricing is the standard choice for most AI products - it's what customers intuitively expect. Highest-tier-reached is a stronger volume incentive and works well for predictable-usage enterprise deals, but can produce surprising invoices for variable workloads. You can also combine multiple pricing metrics on a single product. Adding a second metric (with **Add Pricing Metric**) gives it its own tier structure, which is how you express "charged on input tokens *and* output tokens" or "charged per transaction *and* per unique active user" in one product. ### :list-timeline: Pricing on Units Other Than Transactions Transaction-count pricing ("$X per request") is the simplest model, but it's rarely the right one for AI products where per-request cost varies by orders of magnitude depending on prompt length, model, or output size. **Metering Elements** solve this by letting you charge on any value passed in the metering payload. Head to **Configuration > Revenue Sources > Usage Meters** to create a metering element. Each one has a key name (the field Revenium looks for in your payloads), a description, and a data type - number or string. Revenium creates common AI-related elements automatically (Input Tokens, Output Tokens, Character Count, Credits Consumed, Duration Seconds, Resolution, Quality), but you can add any custom unit your product uses. Once the element exists, you can reference it on a product's pricing configuration. The key is the **Aggregation Method** - how the values received during an invoicing period get combined into a single billable number: * **Sum Element Values Received** - totals every value reported during the period. The default for cost and token metering. * **Average of All Values Received** - averages across the period. Useful for things like average response quality or latency. * **Maximum of All Values Received** - the highest value seen. Useful for tiered resource access ("you're billed at the highest resolution tier you used this month"). * **Count Element Occurrences** - counts how many times the element appeared with any value. Useful for feature usage billing. * **Count Unique Values Received** - counts distinct values. Useful for "per active user" or "per unique customer" billing. * **On each occurrence of specific value** - fires a charge every time a specific value shows up. Example: $2 every time the `country` field equals "Germany". * **On first occurrence of specific value** - fires once per period, the first time a specific value appears. Useful for one-time activation charges triggered by usage. A single product can combine pricing on multiple elements. Click **Add Pricing Metric** to add a second (or third) element with its own aggregation method and tier structure. This is how you express "$0.001 per input token and $0.003 per output token" as a single product. ### :retweet: Recurring Charge Behavior Two fields control how the fixed monthly/annual fee is applied: * **Invoice Timing** - charge the recurring fee at the start or end of each invoicing period. Customer prepayment is common; post-payment is usually for enterprise contracts with net terms. * **Allow immediate cancellations and pro-rated invoices** - when a subscription is canceled mid-period, either the subscription remains active through end-of-period (default) or it cancels immediately and a pro-rated invoice is generated for the partial period. ### :table: Custom Metadata Arbitrary key-value pairs attached to the product. Metadata isn't used by Revenium's billing engine directly, but it's returned on product queries and shows up in analytics, which makes it useful for product categorisation, internal tagging, or passing values through to downstream finance systems. ### :tags: Free Products It's valid (and often useful) to create products with no pricing. Three common reasons: * **Internal reporting** - grouping AI usage by internal team or project without invoicing it. Gives you the same analytics surface as a paid product. * **Free tiers** - limited usage that's included at no charge. The structure lets you build freemium funnels without building the billing logic yourself. * **Chargebacks** - internal cost allocation across business units. Revenium tracks the AI cost, but doesn't generate a customer invoice. To create one, simply leave the pricing section blank when configuring the product. You'll usually also want to disable **Send Invoices to Subscription Owners** so the customer doesn't receive zero-dollar invoices. ### :ruler-combined: Designing Pricing - A Practical Approach When you're designing a new pricing model, the order that tends to work is: 1. **Start with metering elements.** What are you actually charging for? Transactions? Tokens? Minutes of audio? Pages processed? Get the unit right before thinking about the rate. 2. **Add tiers.** Most pricing models fit a "first N units included, then per-unit overage" shape. Start there. 3. **Add a recurring charge.** The fixed subscription fee that covers the included usage. The biggest mistake teams make is over-complicating the initial pricing model. Launch with the simplest structure that works, then add complexity as you learn what customers actually value. Revenium's configuration is flexible precisely because pricing changes frequently in practice - changing a tier structure on a live product is a form change, not a code change. ### :code: Via API Most of what's on this page can be configured programmatically. [Products](https://revenium.readme.io/reference/get_product) and [metering element definitions](https://revenium.readme.io/reference/get_metering_element_definition) both have full CRUD endpoints - useful when you want to manage many products, version-control pricing configuration in a repo, or deploy pricing changes through an automated workflow rather than the UI. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.revenium.io/monetize-your-ai/create-pricing-models-and-products.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.