There is always another AI model.
A lab announces one on Monday. By Tuesday, people are posting benchmark screenshots. A provider adds it at a different price on Wednesday. By the end of the week, there are confident claims that it is either the new default or completely overrated.
Then I have to decide whether to use it.
That decision takes longer than it should. I might open Artificial Analysis to check broad quality and coding scores, OpenRouter to find the actual token price, and LM Arena to see how people rated the output. The model names do not always match. Some results are newer than others. Cheap input can hide expensive output. The highest-scoring model may cost several times more for a fairly small gain.
Doing this once is manageable. Doing it again whenever a promising model appears is a waste of time.
I built the LLM Pareto Frontier dashboard to shorten that research. It brings the useful parts of those sources into one view and asks a practical question:
Which models look most effective for their price, and which ones should I probably stop considering?
It does not choose a model for me. It gets me from a crowded market to a sensible shortlist much faster.
Why model selection keeps getting harder
The number of plausible models has grown faster than my ability to keep a reliable picture of them in my head.
There are flagship models, smaller fast variants, reasoning variants, coding releases, open-weight models and provider-specific versions. Prices move. Providers add and remove models. A model that looked expensive last month can become interesting after a price cut, while a new release can make yesterday's good-value option look awkward overnight.
The evidence is scattered too.
Artificial Analysis is useful for comparing quality, speed and cost across a broad set of tests. OpenRouter's model catalogue shows which models I can actually call there and what their input and output tokens cost. LM Arena's leaderboard dataset adds preference evidence from people comparing model responses.
I trust these sources for different things. That is exactly why checking all of them manually is slow. They use different names, measures and update schedules. There is no single row I can copy from one page and compare cleanly with another.
The usual shortcut is to pick one leaderboard and sort from the top. I do not find that very useful. It answers "which model scored highest here?" when my real question is "how much more am I paying for that difference, and is the difference large enough to matter?"
What I wanted the dashboard to answer
I wanted to open one page when a new model appeared and answer a handful of ordinary questions:
- Is this model genuinely near the best on a relevant quality measure?
- Is it cheap, expensive or somewhere in the middle?
- Is another model both better and cheaper?
- Does it still look attractive if my workload has lots of input tokens?
- Is the evidence current, and did the sources actually refer to the same model?
The third question is where the Pareto frontier helps.
Imagine a model that costs twice as much as another model and scores lower. Unless it has some advantage outside the chart, there is little reason to keep it on the shortlist. It has been beaten on both things I am comparing.
The useful models are harder to dismiss. One might be cheaper but slightly weaker. Another might be stronger but much more expensive. Neither is plainly superior, so both remain on the frontier.
A simple example
Suppose three models are good enough for a task:
| Model | Quality score | Cost |
|---|---|---|
| Model A | 80 | $1 |
| Model B | 84 | $3 |
| Model C | 78 | $2 |
Model C is easy to remove. Model A scores higher and costs less.
The choice between A and B is still real. A is cheaper; B is better. Which one I use depends on how much the quality difference matters for the job.
That is the basic job of the red line on the dashboard. It clears away options such as C and leaves the trade-offs that deserve thought.
Change the measure and the line changes. A model can be good value for coding but ordinary for general writing. It can look cheap on input price and expensive once output tokens are included. The dashboard is not trying to produce one permanent winner.
What the dashboard shows
The opening chart plots a quality measure vertically and a cost measure horizontally. Models toward the upper-left are more attractive: higher quality, lower cost.
I can switch the quality measure between Artificial Analysis indexes and selected LM Arena results. I can compare cost per task or OpenRouter token prices. If I choose a blended token cost, I can change the input/output mix to resemble the work I actually do.
That last control matters more than it sounds. Coding-agent tasks often send a lot of context and receive a relatively short patch. Long-form generation has a different shape. A single advertised token price does not describe both workloads well.
The table beneath the chart shows the exact values. I tend to use the plot to find the interesting area, then the table to compare the remaining models properly.
There is also an unmatched section. It lists source records the dashboard could not confidently connect to the same underlying model. I would rather see an untidy list than a clean chart built from questionable joins.
How it saves time when a new model arrives
Before this dashboard, a new release meant repeating roughly the same research:
- Find the model on each source.
- Check whether the names refer to the same version.
- Copy quality and price figures into notes or a spreadsheet.
- Convert the prices into comparable units.
- Look for models that are clearly better value.
- Repeat the process after the next release or price change.
Now the source feeds refresh, the known model identities are joined, and the chart recalculates around the measures I choose. I still need to judge whether a public benchmark resembles my work. I no longer need to spend the first part of that judgement collecting and aligning the basic evidence.
This is the real value of the dashboard. It is not the scatter plot. It is the removal of repetitive comparison work.
How the information gets onto the page
The system behind the dashboard is careful because a wrong join can be more misleading than a missing model.
The figure shows the whole route. Artificial Analysis, OpenRouter and LM Arena arrive as separate feeds. Small source-specific adapters put prices and results into consistent shapes without pretending the measures mean the same thing. A checked-in alias list records which source IDs belong to the same model. Records that cannot be joined safely go to the unmatched list.
The model names have to match
The same model can appear under a product name on one site, a provider-qualified ID on another, and a slightly different display label in a dataset.
It is tempting to solve this with fuzzy matching. I chose not to. Similar names can refer to different dates, variants or providers. Combining the quality score from one release with the price of another would create a very convincing lie.
The dashboard has an explicit alias list instead. A model joins only when its accepted source IDs are recorded there. Anything uncertain stays unmatched until I review it.
Missing numbers stay missing
A newly released model may have a price before it has a benchmark score. Another may appear in LM Arena but not be offered through OpenRouter.
The dashboard keeps those gaps as missing values. It does not turn them into zeroes. A model only appears in a particular quality-versus-cost comparison when both selected numbers exist.
Old data is labelled
Sources can fail or update at different times. The freshness strip shows when each feed was fetched and whether the dashboard is using current or retained data.
If one source has a temporary problem, the whole page does not need to disappear. The last successful values can remain visible, but they are marked stale. That gives me a usable view without pretending nothing changed.
Why there are four versions of the chart
The dashboard can render the same data with ECharts, Vega-Lite, Observable Plot and Plotly.
This is a side experiment rather than the reason the dashboard exists. I wanted to compare the real weight and behaviour of four visualisation libraries on the same job. Observable Plot adds far less client code than Plotly in this build. ECharts currently gives me the balance of interaction and control I prefer for the default view.
Most readers can leave it on ECharts. The other tabs are there because the dashboard also became a useful way for me to compare charting tools with something less artificial than sample data.
What this still cannot tell me
The dashboard helps me decide what to test. It cannot replace the test.
Public scores do not know my prompts, tools, retry rate or latency requirements. They do not know whether a model follows the particular instructions my coding setup relies on. The chart also leaves out context limits, regional availability, privacy requirements and provider reliability.
Price per token is not the same as cost per successful job. A cheap model that needs three attempts may cost more than an expensive model that gets the result right first time.
So I do not treat the frontier as a shopping list. I use it to remove obviously inefficient options, choose a small group that looks promising, and run those models against real work.
That is a much better starting point than chasing whichever model won the latest screenshot.
The result
New models will keep arriving. I do not expect the market to become easier to remember, and I do not want model research to become a recurring afternoon job.
The dashboard gives me a current, inspectable shortlist. It brings effectiveness and price together, shows where the evidence came from, and tells me when it could not make a safe match.
That is enough. I can spend less time reconciling model catalogues and more time finding out whether the promising models are actually useful.