400 AI Models Listed; Median Input Price Reached $0.55

The later sealed census listed 400 AI models on OpenRouter. The earlier census listed 343. Over the same comparison, the median paid input price moved from $0.45 to $0.55 per million tokens. Those facts are deliberately paired, but they do not establish that the additional listings caused the median to move.

This page measures a change between two sealed censuses of models publicly listed on OpenRouter with posted per-token prices. It measures one marketplace listing, not every model and not every direct-vendor price. A marketplace listing can appear, disappear, change metadata, or change price without revealing why.

400 models were listed in the later OpenRouter census.

$0.55 was the later median paid input price per million tokens.

The comparison runs from July 13, 2026 to August 7, 2026. It is a current benchmark for teams that need a dated input to model-routing discussions, not a recommendation to select a model from a single price statistic.

What changed in the marketplace listing

The numbers describe the public model listing available through OpenRouter at the two sealed endpoints. They do not describe usage volume, model quality, latency, availability, direct-contract pricing, or what a customer will pay in an unrelated platform. A model with a listed price is not automatically appropriate for a production workflow.

Paid listings moved from 315 to 378.

Free-price listings moved from 24 to 17.

The listing count moved by +57, from 343 to 400.

A “free,” “paid,” or “variable” label here is a listing classification from the price fields observed at the endpoint. It should not be translated into a claim about total cost. For example, variable pricing is kept separate rather than silently treated as free or paid.

The AI crawler blocking trend covers a different operational layer: public web-access policies. It is useful alongside this page only because an AI program needs both model-routing choices and deliberate content-access policy. Neither source measures the other.

Price units: input and output are different measures

Token prices are quoted per million tokens in this sealed comparison. Input is the material sent to a model; completion is the material returned from it. The price entries below are medians across the observed paid listings at each endpoint, not a quote for an individual model or a computed blended workload cost.

The input median rose by +$0.10 and the completion median rose by +$0.25. These are already sealed differences. This article does not divide one by the other, translate them into a per-request estimate, or annualize a short comparison interval because those calculations would require a workload profile that the snapshot does not contain.

The practical lesson is not “the market got more expensive.” It is that a routing policy should name its units. A team comparing candidates should distinguish prompt volume from completion volume, static listings from actual invoices, and a marketplace view from a contractual or direct-provider view.

Listing mix provides context, not causation

The later census had more listings in each paid tier represented by the snapshot. That gives a reader context for the changing median without pretending to explain it.

More listings in a band do not show that all models in that band repriced. They also do not identify the models that entered or left the marketplace. The sealed comparison intentionally stops at the observable aggregation. That boundary makes it more useful for monitoring than an improvised explanation would be.

A marketplace listing count is not a benchmark of model quality, throughput, or customer cost.

The research catalog carries the machine-readable JSON and CSV companion files for this report. Those files preserve the same limited claim: observed public listing movement at named endpoints.

Put model-cost research to Work

An engineering, data, or operations lead can make a model-cost workflow more accountable by separating the research input from the deployment decision. Start with a small registry of permitted models, intended tasks, expected input and completion patterns, owner, and review date. Then attach marketplace observations as one review signal instead of treating a table as an automatic routing rule.

US Tech Automations can build an agentic workflow that gathers approved pricing observations, flags a material policy change, and sends it to the product or data lead who owns the decision. The point is not to promise savings from a headline median. It is to make model selection, review, and change control repeatable when an automation handles real customer work. The agentic workflows overview explains the broader pattern.

For teams that publish public content as well as run models, the related AI-crawler policy report can anchor a separate owner and review cycle. Keeping cost routing and site-crawler policy in distinct workflows prevents a loose benchmark from becoming an accidental company-wide rule.

What the seal can and cannot say

Every endpoint is copied from its named content-addressed source seal and every delta is exact subtraction performed by the comparison sealer. Nothing is estimated, modeled, annualized, or extrapolated. Listing changes can reflect additions, removals, repricing, or metadata changes and do not by themselves identify a cause.

The source is the OpenRouter models API, interpreted only as public listing data. Its model documentation is useful for understanding the catalog surface. This report does not reproduce vendor descriptions or assert that every model available from a vendor appears on the marketplace.

Frequently Asked Questions

Q: Does 400 mean there are 400 AI models available everywhere?

A: No. It is the later count of models publicly listed on OpenRouter in this comparison. Direct-vendor catalogs and other marketplaces may differ.

Q: Does the $0.55 median tell me what my application will cost?

A: No. Application cost depends on the selected model, prompt and completion volume, routing, and commercial terms. The figure is a marketplace-listing median per million input tokens.

Q: Did the new listings cause the median price to rise?

A: The seal does not establish causation. It records both movements and leaves additions, removals, repricing, and metadata changes as possible explanations rather than claims.

Q: Why are variable-price models separate?

A: A variable price field is not safely comparable to a fixed free or paid label without extra assumptions. The sealed comparison keeps the category separate.

Q: Is this a recommendation to buy a model?

A: No. It is a dated research input. A production decision should include task quality, security, latency, reliability, governance, and the actual commercial path.

Source: US Tech Automations Research, OpenRouter public model-listing trend seal, July 13, 2026 – August 7, 2026. Aggregate factual observations only; no vendor descriptions or direct-price claims.

A sound way to use a marketplace price snapshot

Price research becomes useful when it is attached to a decision that has a bounded purpose. For example, a team may want to know whether its approved routing set still reflects the public marketplace it monitors. That is a different task from finding the universally cheapest model, forecasting a budget, or choosing a model for a safety-sensitive workflow. The sealed comparison supports the first task and deliberately stops before the others.

The first question to ask is whether the marketplace is the actual purchase surface. Some teams route requests through a marketplace; others buy from a direct provider or work through a platform with its own commercial terms. A listing census is most relevant to the former and remains context for the latter. Treating it as an invoice proxy creates a false precision that the source cannot justify.

The second question is whether a median fits the workload. A median summarizes a set of observed prices; it does not specify the token mix, task complexity, fallback behavior, cache behavior, or quality threshold for a real application. Those inputs should come from an internal measurement plan. The price snapshot can populate a review note, while the application telemetry and procurement terms determine the actual operating decision.

The third question is governance. A model-routing change can affect data handling, output quality, latency, reliability, and customer experience. Price is one decision factor, not a release criterion. The most durable workflow records who may add a model, who tests it, where it may be used, when it must be reviewed, and which failure path applies. That makes a changing catalog manageable without letting it silently rewrite production behavior.

The comparison is intentionally reproducible at the display level. A reader can see the named endpoints and the published price-unit definition rather than being asked to trust a generic “prices changed” statement. It does not republish expressive model descriptions, build a ranking, or imply that a catalog label is a performance evaluation.

Finally, keep time horizon visible. The two censuses are a short dated interval. They are useful for noticing a current composition change, but they are not a long-run price curve and should not be projected forward. The evidence says exactly what was listed at the endpoints; it does not claim why the listing changed or what it will do next.

An accountable review records the question being answered. A marketplace listing can support a routing review, while application telemetry and commercial terms support a workload-cost decision. That separation lets a data lead use the evidence without letting a public median silently control production behavior. For a separate, stricter public-price observation, see the automation pricing-page audit. For clarity, nothing is estimated, modeled, or extrapolated beyond the sealed marketplace observations in this report.

This is also why the report preserves both listing composition and price medians. A reader can see that the catalog changed without treating one metric as an explanation for the other. If a team needs to understand a specific supplier or model, it should collect primary documentation and evaluation evidence for that purpose. The sealed record remains a bounded starting point, not an inference engine.

That distinction keeps a research update useful even when catalog conditions change again soon after publication.