Monetizing AI — Alvaro Morales, Orb

How do you turn an AI capability into a product that reaches the right customers and pays for its continued development? Capturing some of the value created by AI is part of sustaining the innovation itself. Alvaro Morales approaches that problem as Orb’s co-founder and CEO, drawing on its billing work with AI and SaaS companies, including Vercel’s v0, Replit Agent, and Perplexity’s API.

Software pricing has always mixed judgment with measurement, but AI adds three pressures that make postponing the decision expensive:

• Pace: Model costs, inference costs, capabilities, and competing products change quickly. A pricing structure can become stale while the product is still finding its audience.
• Margins: Serving another customer can mean a substantial Anthropic or OpenAI bill. Shipping first and figuring out monetization later becomes harder when usage carries significant cost of goods sold, or COGS.
• Trust: Customers want to understand the return on their investment. The bill must make sense in relation to the value they receive.

Unexpected adoption compounds all three: usage can grow faster, or become more intensive, than the pricing model anticipates.

Even a high subscription price does not guarantee healthy economics. Morales cites ChatGPT Pro at $200 per month as a loss-making subscription, referring to Altman’s January 2025 report that usage exceeded expectations. That contemporaneous report describes a moment in the product’s history, not an audited or permanent profitability finding. The response is to replace “pricing on vibes” with three decisions: how to monetize, what to meter, and how to keep testing the pricing experience.

The first question is whether an AI capability needs its own charge. Morales introduces a framework attributed to Simon-Kucher: sell a standalone product or add-on, use the capability to encourage movement into a higher tier, or include it at no additional charge to stimulate another revenue-generating behavior. Packaging and monetization overlap here: bundling into a premium tier can drive an upsell, while increasing that tier’s price also captures value directly.

Audience relevance determines whether an add-on makes sense. GitHub Copilot launched as a separately monetized capability on top of the base GitHub seat. A GitHub customer does not necessarily get the same value from coding assistance as another customer. Separating the purchase lets the group that benefits pay for it without imposing the charge on every seat.

Packaging can change as the product matures. Morales describes Notion AI as first to market in its category and initially sold as an add-on. It subsequently became part of the Business and Enterprise tiers, alongside tier price increases he describes in the talk. The commercial goal shifts from selling an optional feature to making the higher tiers more attractive and encouraging adoption there.

Expedia illustrates a different route. Morales describes an AI feature, launched about a month before the talk, that turns Instagram Reels into bookable trips. Users do not pay a separate charge for that capability; Expedia absorbs the serving and inference costs. His inferred rationale is that easier trip discovery could generate more travel bookings. The AI feature can therefore contribute to revenue without becoming a separately billed product.

Once a capability needs a price, the next decision is the value metric: the unit that determines what a customer pays. Agents change this question because customers increasingly buy work performed, automation achieved, or an outcome delivered, rather than access to an application where they do the work themselves.

This spectrum moves from inputs toward results. The right position depends on what customers understand and what the product can measure reliably.

Vercel’s v0 sits toward the resource end. Its historical token-based pricing metered input and output tokens through credits, with monthly included credits and additional purchases. Morales connects that granularity to a developer audience interested in understanding the capabilities it consumes. Zapier instead charges for tasks within a workflow, or Zap: customers subscribe to a monthly task quantity and can incur overages when they exceed it. The bill follows automation activity rather than underlying model consumption.

Morales describes Intercom Fin as charging $0.99 per successful customer-support resolution. His example is an interaction in which the user confirms that the answer solved the problem and does not need escalation to a human agent. That illustrates the outcome contract: payment depends on the support result. Later Fin documentation also counts assumed resolutions, such as a user leaving without requesting further assistance; explicit confirmation is therefore not the only documented signal, and that later definition should not be substituted for the historical example.

Outcome pricing attracts attention because it puts the customer’s desired result directly into the commercial agreement. Yet Morales reports seeing few strong working examples outside customer experience and support at the time of the talk. Customer and vendor must agree on what success means and be able to measure it with reasonable objectivity. Without both, the apparent simplicity of charging for success moves the disagreement into the invoice.

Support has useful signals: ask whether the answer resolved the question, observe whether the interaction escalated, and relate automation to identifiable human support costs. Creative work is harder. Its success criteria may be less discrete, and its contribution to revenue or cost savings less directly attributable. Morales calls the appeal of outcome pricing “literally ROI”: the charge is tied to the result the customer wants. Extending that alignment to other categories requires continued work on definitions and measurement.

The third framework treats pricing as a continuing product practice. An older SaaS pattern was to choose a price, add value for one to three years, then confront a large and painful increase to catch up. AI’s pace makes that interval difficult to sustain.

Morales argues that model releases can move costs tenfold overnight and invokes Claude 4 in that discussion. The launch announcement, however, states that token prices stayed consistent with the preceding Opus and Sonnet models; the talk supplies no workload comparison establishing a tenfold task-cost change. The practical issue is still material: a team needs to reassess its economics as model choices and consumption change, rather than wait years between pricing decisions.

Pricing is more than the price point. Feature packaging, tier boundaries, rate limits, usage volumes, and custom terms all shape the exchange of money for value. How those choices are communicated affects whether customers understand that exchange. Experimentation therefore includes both the commercial structure and the experience of buying and using it.

Orb Simulations brings that experimentation into a workflow: apply alternative pricing structures to product usage data and examine their consequences before launch.

The foundation is a stream of raw product usage events. An application instruments what customers do and sends those events to Orb in real time. Billing rules operate on that data, while analytics show accrued costs and the charges customers are accumulating. Usage measurement and billing share the same underlying record of consumption.

Orb noticed customers using this setup without actually billing anyone. They sent usage data and created shell pricing structures on top of it. Conversations revealed that these teams were running closed betas, including betas for upcoming AI agents: the product existed, customers were trying it, but the pricing decision was still open.

Simulations turned that improvised process into a dedicated product. Instead of treating a pricing rule only as an instruction for charging customers, the team can treat it as a scenario to backtest against collected usage. The question becomes concrete: what would this cohort’s consumption have cost under a different pricing structure?

The demonstration configures a simulation in a deliberate order:

1. Select the period. Use a window that captures relevant consumption, such as the closed beta.
2. Choose the cohort. This can be unpaid beta customers or existing customers on older pricing who are about to receive additional value.
3. Start from a baseline. Build alternative scenarios so their effects can be compared against a common reference.

The cohort and period determine which actual usage the proposed rules will price.

The demo proposes a fixed $20 fee per customer for AI agent access. Morales does not specify a billing cadence for that fee. He then contrasts it with more granular token charging: either a simple unit price or a tiered structure that includes some tokens free and charges for additional consumption.

These are alternative pricing possibilities to evaluate against the same usage data, not charges being imposed on the beta customers.

Running the simulation produces a report comparing the proposed scenarios. The first view addresses top-line revenue: given the customers’ observed consumption, which pricing structure produces the greatest revenue impact?

For an existing customer base, revenue is only one decision criterion. A structure that increases revenue sharply may also create difficult bill changes. The report therefore compares customer impact, including the average change to existing customers, alongside the expected revenue mix. Its summary brings simulated revenue and customer impact together across the Baseline, Pay as you go, and Hybrid scenarios.

The detailed view includes a scatter plot showing percentage change and revenue impact by customer, plus an exportable dataset of individual customer effects. That makes it possible to move beyond an aggregate average and inspect who would experience the change. The backtest answers a conditional question about recorded usage under proposed prices; it does not establish how customers will change their consumption after those prices launch.

Morales advocates simulating before going to market so that launch decisions are informed by the likely billing impact on the existing customer base. The demonstration supplies no numerical revenue result, but it shows the decision process: explore alternatives, inspect their distributional effects, and choose with a clearer understanding of the trade-offs.

The commercial objective is to align the way a product earns revenue with the value customers perceive and the behavior the business wants to encourage. Direct charges, indirect revenue, the billing unit, and ongoing experimentation are parts of that same design problem. Morales reports that Orb customers have achieved substantial revenue results and reached the right audiences by improving this alignment, without giving figures or named closing case studies. Finding suitable pricing can be difficult, but teams can converge toward it through measured iteration.