> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kymaapi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Model comparisons

> How /compare pages are built, what they will and will not tell you, and which of them Kyma asks a search engine to index.

Every model Kyma serves can be put beside any other on a URL. Sort two to four
model ids alphabetically, join them with `-vs-`, and that is the page:

```
https://kymaapi.com/compare/<model-a>-vs-<model-b>
```

Any other ordering of the same models permanently redirects to the sorted one.
One comparison has one URL.

## What is on the page, and what is not

Three things, and nothing else:

| Half                              | Source                                               |
| --------------------------------- | ---------------------------------------------------- |
| Price per 1M tokens               | What that model costs on Kyma today                  |
| Availability, throughput, latency | Kyma's own measurement of the model while serving it |
| Context, modalities, capabilities | The specification the model's creator publishes      |

There are no benchmark scores on these pages. Kyma publishes what it measures
and what a creator publishes about its own model; a third-party scoreboard
measuring somebody else is neither, it goes stale without telling anyone, and a
page carrying it would be making a claim it cannot refresh. So a comparison page
will tell you what a model costs and whether it answers, and it will not tell
you which model is smarter.

Availability is the same number, computed the same way, as the one on
[/models](https://kymaapi.com/models) and
[/status](https://kymaapi.com/status): successful observations divided by total
observations over 30 days, counting Kyma's scheduled probe and real customer
requests alike. Throughput and latency are probe-only, from one identical prompt
sent to every model every six hours, so the only variable left between two rows
is the model.

## Which comparisons get indexed

Every combination renders, and every combination has a canonical URL. Not every
combination is submitted to a search engine, because a site that asks to be
indexed on tens of thousands of near-identical pages teaches a crawler that most
of it is not worth fetching.

A curated comparison is always indexed. Anything else is indexed when **both**
of these hold:

1. **Every model in it has at least 100 observations in the last 30 days.** A
   model measured since yesterday has a real reading on a sample thin enough
   that one failure moves it by a point, so a comparison resting on it is not
   something to rank.
2. **It is one of the curated comparisons, or it has been opened on at least
   three separate days.** Curated comparisons are the matchups a buyer actually
   shops between, listed on [/compare](https://kymaapi.com/compare). Anything
   else has to have been asked for on three different days, so three reloads in
   a row do not count as three occasions.

Everything else is `noindex, follow`: the page works, it renders, it shares, and
its links are still crawled. Only the request to rank it is withheld.

Column count is not part of the rule. A four-model comparison people open is
indexed on the same terms as a two-model one.

## Finding comparisons programmatically

`/compare` lists the curated set, the most-opened combinations among those
opened in the last 30 days, and the last 20 opened. `views` is a lifetime total:
`window` chooses which combinations are listed, it does not window the counter.
The same data is available directly:

```bash theme={null}
curl "https://api.kymaapi.com/v1/compare/popular?sort=views&window=30d&limit=20"
```

```json theme={null}
{
  "items": [
    {
      "slug": "<model-a>-vs-<model-b>",
      "model_ids": ["<model-a>", "<model-b>"],
      "n_models": 2,
      "views": 41,
      "seen_days": 9,
      "last_seen": "2026-09-07T21:44:02.118Z"
    }
  ],
  "window": "30d",
  "sort": "views",
  "limit": 20
}
```

No authentication, cached for five minutes, and rate limited to 60 requests per
minute per IP. `sort` is `views` or `recent`, `window` is `7d`, `30d`, `90d` or
`all`. `seen_days` is the number of distinct days the combination has been
opened on, and it is what the index rule above is measured against.

The counter behind it records a slug, the model ids in it, two counts and three
dates. It holds no user id, no IP address, no session and no referrer.