Writing a pricing page an agent can use

Most pricing pages are built for a person comparing three plans in a table. That page answers a question an agent is not asking.

What an agent actually searches for

Real queries, issued by coding agents mid-task in our sessions:

site:algolia.com pricing records search requests grow plan official
site:meilisearch.com/docs typo tolerance ranking rules filterable attributes production self hosted

Note the shape. Scoped to a site. The word "official". And in the first one, three units named directly: records, search requests, plan.

That is a different page.

What to publish

What a unit is, in words. Not "10,000 requests". What counts as a request. Does a retry count. Does a failed call count. Does a batch of fifty count as one or fifty.

This is the single most useful paragraph and almost nobody writes it.

Where the meter ticks. At the call, at the record stored, at the seat, at the project, per month, per day. An agent reasoning about cost needs the dimension, not the number.

The free tier as a number. "Free for the first 100,000 jobs a month" is usable. "Generous free tier" is not.

The limits that are not price. Rate limits, payload sizes, retention, concurrency. Often more decisive than cost, and usually on a different page or missing.

What happens at the boundary. Do you throttle, queue, reject, or bill the overage. An agent choosing between two products treats "rejects at the limit" and "bills the overage" very differently, and correctly.

Whether the thing it needs is gated. If single sign-on, audit logs or the region it needs are on a higher plan, say so plainly on the page. Stating a limit is better than silence, and it stops you winning a session you would lose at the security review.

Put it in the documentation, not only in marketing

The marketing pricing page can stay as it is. It is doing a job for a human comparing options.

Add a documentation page called pricing or limits that explains the units in plain terms. That is what a site-scoped search finds, and it is what an agent can use in a decision. It also happens to be the page your existing customers keep asking support about.

The shape that works

# Pricing units

Current as of September 2026.

## What is billed

One **job** is one call to `queue.send()`. A retry is not a new job. A batch
of 50 messages is 50 jobs.

## What is not billed

Failed sends, cancelled jobs, and anything in the dead letter queue.

## Free tier

100,000 jobs a month, no card. Everything works except private networking.

## At the limit

We queue rather than reject, and bill the overage at $1 per 10,000 jobs.
Nothing is dropped.

## Limits that are not price

| | Free | Paid |
| --- | --- | --- |
| Payload size | 256 KB | 2 MB |
| Retention | 7 days | 30 days |
| Concurrency | 10 | 500 |
| Rate limit | 100/s | 5,000/s |

A table, real numbers, a date, and a sentence saying what counts as one.

If pricing is custom

Say the shape anyway.

"Priced on volume of records and number of environments, typically five figures a year, with a conversation at over 50 million records" tells an agent something usable. "Contact sales" tells it nothing, and an agent that finds nothing treats the product as unknowable and moves on to one that is legible.

You are not giving away a negotiating position by naming the dimensions you meter on. Your competitors already know.

Why this is worth an afternoon

In our data, one of the recurring reasons an agent raised a product and then passed over it was a missing answer to a specific production question. Cost is one of those questions, and it is asked more often than the category's own literature suggests, because several of the people asking have a budget constraint they mentioned in the request.

See the products coding agents consider and never choose.