How we built the Agora pricing model

Until recently, every successful call to the Agora API cost one credit.

A catalog lookup cost one credit. So did a deep search, which runs several language model calls, a web search, and a series of live price and stock checks before it returns. A deep search does far more work than a catalog lookup. The meter treated them as the same.

That was fine while usage was small. It is not a fair way to charge anyone, and it is hard to explain. So we rebuilt our pricing from the bottom up. We started with the work behind every request, then defined a single credit, then built the plans on our pricing page on top of it.

This post explains how that model works, with the numbers. It covers how we measure the work in a request, what a credit is, how subscriptions and credits fit together, and what we have not worked out yet.

The short version

• One unit. Everything on Agora is metered in credits. One credit is worth $0.001 at list, so 1,000 credits is $1.

• One rule. A request is charged for the work it does. The same formula prices every endpoint, so a request that does ten times the work costs ten times the credits.

• Subscriptions are credits bought in advance. Each plan's allowance comes from its price. Committing more, or committing for longer, lowers the price per credit.

• Top-ups cost more than plans. Usage you didn't plan for costs more than usage you did, so moving to a bigger plan always beats topping up.

• One balance. Shoppers, merchants, developers and AI agents all draw from the same kind of credit, priced by the same rule.

The rest of the post shows how we got there.

One credit for the whole platform

Agora is several products on one platform. Shoppers use AI search, price and stock alerts, and automatic discounts. Merchants build stores. Developers call the API and bring our catalog into their own apps. AI agents call the same endpoints people do.

We wanted one pricing model to cover all of it. The usual alternative is a separate price list for each product, and those lists tend to drift. Each gets its own discounts, its own exceptions, and its own idea of what a unit of work is worth. After a year, nobody can say what anything really costs.

So we have one way of measuring work, one formula for turning it into credits, and one credit. A shopper's search and an enterprise catalog sync are priced by the same rule. A plan is just a way to buy those credits in advance.

The model also reflects how Agora makes money, and how it doesn't. We don't sell ranking, we don't hold inventory, and our pricing page lists no checkout fees on paid store plans. Our revenue comes from one place: the work the platform does for a customer. If the pricing is honest about that work, customers can see exactly what they are paying for.

Step one: measure the work, not the endpoint

Our engineering team set the rule everything else follows: price the calls an endpoint makes, not the endpoint's name. The name tells you nothing. What matters is what the request does once it arrives.

So we mapped every user-facing request to the work behind it. Two examples show how different they can be.

A regular search makes three small model calls. The first works out what the shopper means. The second rewrites the query for search, and it is longer when the shopper is refining an earlier search or asking about products already shown. The third reranks the candidates. The first two are cached for seven days, so a repeated query does less work.

A deep search is a different kind of request. It makes six or seven calls to a larger language model, runs a web search for outside sources, and makes seven live calls to check product availability. Most of the work is in the language model calls, which run fresh every time.

Every other endpoint was mapped the same way, down to whether it touches an outside service at all. Some don't. Store and brand lists run on our own search index, and store management runs on our own database.

Step two: turn work into credits

With the work of each request mapped, the price comes from one formula applied the same way everywhere. The result is a whole number of credits, rounded up. Anything that succeeds costs at least one.

We set a credit at $0.001 for a practical reason. It is small enough that even the lightest metered request costs several credits, not a fraction of one. That keeps prices precise. With a larger credit, rounding up would make light requests much more expensive than the work they do.

Here is what each request type costs today.

The ratios are the point. A deep search costs about 40 times a regular search because it does about 40 times the work. A product lookup costs about half a regular search for the same reason. Nothing is priced by hand, and no endpoint subsidizes another.

A few design choices are worth explaining.

Cached and uncached requests cost the same. We thought about passing cache savings on. We decided against it. A customer can't see or control our cache, so a price that changed with it would be impossible to predict. A regular search costs 13 credits whether or not we have seen the query before. We take on the variation so the customer gets a stable price.

Requests to our own systems cost one credit. Store and brand lists and store management don't call outside services, but they still use our servers. One credit keeps that usage visible without pretending we can price a fraction of a server.

Some things are free. Failed calls are free, as they always were. Checking your credit balance used to cost a credit. Now it's free. You shouldn't pay to find out how much you have left.

New endpoints price themselves. Before, a new endpoint had to be priced by hand or it defaulted to one credit. Now an engineer declares what the endpoint does, and the formula gives its price. New features join the same price list automatically.

What changed

Under the old meter, a product lookup and a deep search both cost about a dollar. Now the lookup costs seven tenths of a cent and the deep search about 53 cents. Every plan goes further for every kind of request than it did before. It goes much further for light requests than for heavy ones, which is how it should be.

Step three: subscriptions

Once a credit has a fixed value, a subscription is simple to define. It is a monthly commitment to buy credits. In return you get a better rate and access to more features.

Each plan's allowance comes from its price, not from a separate decision. Divide the plan's included value by the value of a credit and you get its allowance. If the credit value ever changes, every plan adjusts with it.

Plan prices, allowances, seats and rate limits are as listed on our . Annual billing charges ten months for twelve.

Some of this is deliberate.

Starter and Premium are priced at list. $25 buys $25 of credits, and $200 buys $200 of credits. The difference between them is what you can do, not the rate. Starter is for running a store on your own domain. Premium adds API access, developer and merchant tools, and the ability to bring our catalog into your own app. We kept the API off Starter on purpose. API customers use the platform differently and need rate limits and tools a single store doesn't.

Scale is the first volume discount. $750 buys $1,000 of credits, 25% off list. It is also the first plan where unused credits roll over. Scale exists because a Premium customer who needs a million credits a month shouldn't pay list price for them.

Annual billing is a second, separate discount. Two months free cuts the rate by a sixth on any plan. Combined with Scale, an annual customer pays $0.625 per 1,000 credits, 37.5% below list.

Seats are priced separately from credits. Extra console seats are $25 a month. Premium allows up to five seats and Scale up to ten. A seat is access, not work, so it gets a flat price.

Free is sized around deep search. A Free account gets 2,000 credits a month, enough for about 150 regular searches or three deep searches. Most of what Agora does, a developer can find elsewhere. Deep search is the part they can't, so the free allowance should be enough to try it properly. We expect to adjust this once we see how people use it.

What a plan buys

Here is what each allowance is worth if you spend it all on one kind of request.

Real usage is a mix, and that is why there is one credit. A developer doesn't have to decide in advance how many deep searches or comparisons they will need. They spend from one balance, and each request costs what it does.

Step four: credits beyond the plan

Sometimes a customer needs more than their plan includes. There are two ways to get more credits, and they are priced on opposite sides of the plan rate on purpose.

Add-ons: committing to more

At checkout, any paid plan can add more credits. Add-ons renew monthly, and each step costs less per credit than the one before.

The credit totals match the options on our pricing page. The add-on rates are set so each plan leads into the next. The largest Premium add-on reaches $0.75 per 1,000, which is Scale's base rate. Past that point, Scale is the better deal, and it comes with rollover, more seats, and higher limits.

Top-ups: buying when you need them

A top-up is a one-time purchase for usage you didn't plan for. Top-up credits last 12 months.

Every top-up costs more per credit than every plan, and that is intentional. A customer who needs a million extra credits every month should be on Scale, which costs $750 for the same million. Top-ups are for the month a launch goes better than expected, not a regular way to buy capacity.

A worked example

Take a developer on Premium whose app does this on a typical day:

Over 30 days that is about 215,000 credits, a little more than Premium's 200,000. The developer has three options:

The add-on is the clear choice. It costs $100 less than the top-up and comes with more headroom. If the app keeps growing, the add-on steps lead to Scale. The developer can work all of this out from the pricing page without talking to us. Note also that the three deep searches a day use nearly a quarter of the credits. That is the formula doing its job: the most expensive feature is the one that does the most work.

This gives the whole system one ordering rule. Committing always beats paying as you go. Committing to more beats committing to less. Committing for longer beats paying month to month. The cheapest option for the customer is also the most predictable one for us.

Enterprise

Enterprise is priced outside the self-serve plans. Credits are set against catalog size and request volume, as our pricing page describes. Contracts include an account manager, an uptime SLA, and advanced catalog ingestion.

At enterprise scale, a list price per request stops being the right way to think about it. A customer sending millions of requests a month is buying capacity and reliability, and the contract reflects that. The same measure of work sits underneath, so every contract is grounded in what the platform actually does. But the price is negotiated.

What we haven't worked out yet

The model rests on measurements where we have them and careful estimates where we don't. These are the main open questions.

• Real usage. We don't yet have enough traffic to know how customers mix their requests. The examples in this post are illustrative. Plan allowances, especially Free, will be tuned as real data comes in.

• Caching. Our caches last seven days, and we don't yet know how often they are hit. Since cached requests cost the same, this won't change what customers pay. It does change how much work the system does, and we want to measure it properly.

• Estimates in the work model. Some inputs, such as the size of each model call, are still estimates rather than measurements. We will replace them as we instrument each endpoint.

• Store Builder. AI generation in the store builder varies widely from one session to the next. It isn't yet measured the same way as everything else. It is the one part of the platform the unified model doesn't cover today, and bringing it in is next.

There is one advantage to setting prices before we have much usage data. We can get the structure right now, instead of moving a large customer base onto it later. That window closes as we grow, which is why we did this now.

Closing

The pricing model is a small number of decisions, applied consistently. Measure each request by the work it does. Turn that work into credits with one formula. Let plans be ways to buy those credits in advance, priced so that committing to more always costs less. Price unplanned usage above the plan rate, so the cheapest option is always clear.

Each piece is simple. What matters is how they fit together. A shopper's search, a merchant's store and a developer's API call are priced by the same rule and paid from the same balance. When we add a feature, it joins the same price list. When the work behind a feature changes, its price follows.

We will share updates as real usage replaces our estimates, including where we got things wrong.