Poolside: Laguna XS 2.1 (free)

Specifications

How to read this page

Everything above is either a sourced fact or a number we computed from sourced facts. Price, context window, modality and weight availability come from live provider data, not from a marketing page, and they are refreshed when the index rebuilds. The score and its breakdown come from a dated benchmark snapshot, so they describe the model as measured on that date — not as it may behave after a silent provider-side update.

The category table is the part worth reading closely. A single overall number compresses seven different abilities into one figure and inevitably hides variance; the contribution column shows exactly how much each category moved the total, so a model carried by one very strong category is easy to spot. If your workload is narrow — only code, only long-context retrieval, only maths — the relevant category row is a better guide than the headline score, and the raw task scores beneath it are better still.

Cost deserves the same scepticism as capability. Input and output are priced differently, and most production workloads are output-heavy, so a model that looks cheap on input can be the expensive option in practice. Benchmarks also say nothing about latency, rate limits, regional availability or how a provider behaves under load — all of which decide whether a model is usable for you. Treat this page as the measurable half of the decision.

Before you commit to this model

Benchmark position is the easiest thing to compare and rarely the thing that decides whether a model works for you. Run your own prompts against it before you build on it — a model that leads a category can still be wrong in the specific shape your product needs, and one that sits mid-table can be perfectly adequate at a fraction of the price. The numbers above narrow the shortlist; they do not pick the winner.

Check the operational side separately, because none of it appears on this page: latency under your real payload sizes, rate limits at your expected concurrency, regional availability if you have data-residency constraints, and what the provider does when demand spikes. Teams are far more often burned by a rate limit or a timeout than by a model being a few points weaker on a benchmark.

Then price the workload properly rather than by the headline figure. Input and output tokens cost different amounts, most production traffic is output-heavy, and prompt caching can change the arithmetic substantially if your prompts share a long prefix. A model that looks expensive per input token can be the cheaper option once a real usage pattern is applied — and the reverse trap is just as common.

Weight availability changes the calculus entirely. An open-weights model can be self-hosted, fine-tuned on your own data and kept inside your own network, which matters when prompts carry anything sensitive or when you need the model to stay frozen while a provider iterates. The trade is that you take on the serving cost and the operational burden, which pays off at sustained volume and rarely does at low or spiky traffic. A proprietary model removes that burden and removes that control with it.

One last caution about the score itself: it reflects a single dated snapshot, and providers update models behind unchanged names. If this page shows an older snapshot, treat the figures as evidence about how the model behaved then rather than a guarantee about today. That is precisely why the snapshot date is printed rather than hidden.

FAQ