A new model lands every week and the announcements all sound the same. This guide gives beginners two sturdy skills: how to find out what a model can actually do, and how to track what is coming next without drowning. It names the real places to look, shows you how to use each, and ends with a radar you can keep.
Sam keeps hearing it. A new model tops a chart, a demo goes viral, a founder posts that everything has changed. Sam tries the model, and it is fine, sometimes great, sometimes worse than the one already in use. The confusion is not Sam's fault. It comes from treating "capability" as a single thing a model either has or lacks, like horsepower.
It is not one thing. A model can be brilliant at code and clumsy at poetry, sharp in English and shaky in Hindi, dazzling in a demo and unreliable on your actual task. "Is it good?" has no answer. "Is it good at the specific thing I need?" has one, and finding it is a skill you can learn in an afternoon.
The number everyone quotes when a model launches is a benchmark score: it aced some exam by a point or two. That is real information, and it is not the same as "good for you." A benchmark measures one narrow thing under lab conditions, and the launch tweet measures nothing but excitement.
So the goal of Part I is not to find the highest number. It is to build a quick, honest picture of what a model does well and badly, using three simple lenses that anyone can apply. None of them is a benchmark.
To size up any model, look through three lenses in order. Read what its makers claim, in the model card, including the limitations they admit. Check independent evidence, on leaderboards and human-preference rankings, while staying skeptical of both. And try it yourself, on two or three examples of your real task, because nothing else counts as much.
Part I finishes with the first lens up close. Part II is a tour of exactly where to point the second and third: the real websites, and how to use each one.
Every serious model comes with a model card: a short document from its makers describing what it is, what it is for, and where it fails. Learning to read one is the fastest capability skill there is. Here is a real-shaped card. Click each field to see what it tells you and the trap to watch for.
A model card is a sales brochure written by the seller, so read the claims with a pinch of salt and the limitations with full attention. Honest makers list real weaknesses; the absence of any limitations section is itself a warning sign. This is lens one done. Now, where the real evidence lives.
If there is one place to start, it is Hugging Face. Think of it as a giant public library where nearly every open model, dataset, and demo lives, each with its card on the cover. Scroll through the four moves that turn it from an intimidating wall of names into a tool.
Go to the Models tab and use the filters on the left: the task (chat, summarize, image), the language, the license, the size. In seconds you go from a million models to the handful that fit your job.
Click a model and you land on its card: what it is, its license, its limitations, its scores. This is lens one from chapter 04, sitting right there on the page.
Many models have a Space, a live demo you run in the browser with no setup. Type your real example in, see the answer. This is lens three, trying it, made effortless.
Hugging Face hosts leaderboards that rank models on shared tests. Useful for a shortlist, and, as the next chapter warns, never the final word.
Here are the exact doors, with what each is for. Open them in another tab as you read.
Independent evidence comes in two flavors, and knowing the difference protects you from both. A benchmark leaderboard scores models on fixed exams. A human-preference arena shows real people two anonymous answers and asks which they like, then ranks by who wins more often. One measures exam skill, the other measures felt quality. Click each to see how to read it and where it misleads.
New capabilities appear faster than anyone can read. The trick is not to drink the whole firehose; it is to tap a few good pipes and let the rest flow past. Here are the source types worth one visit a week each. Hover a tile for what it is, how to use it, and the link.
Now you can size up a model and find the sources. The last skill is holding it all in one view that shows not just what exists, but how ready each thing is for you to rely on. Borrow a tool teams have used for years: the Tech Radar, from Thoughtworks. It sorts everything into four rings by how much you should trust it: Hold (watch, do not use), Assess (worth an experiment), Trial (use on a real but low-risk project), and Adopt (use with confidence).
The rings are not about how new or exciting a thing is. They are about how much evidence you have gathered. That is the whole point, and it is one dial. Below is a live radar of GenAI trends. Grab the new trend and drag its evidence from nothing to plenty, and watch it earn its way inward from Hold to Adopt.
Watch one real-shaped trend travel the rings as its evidence accumulates over a few months. This is what maintaining a radar actually feels like: not a single decision, but a blip you nudge inward as the proof arrives. Scroll it through.
A viral post claims a tiny model rivals the giants. Exciting, and it is one person's demo. It goes on the radar in Hold: noted, not trusted.
Benchmark scores appear and hold up on paper. Enough to move it to Assess and spend an afternoon trying it on your own examples.
Independent people reproduce the results and report the rough edges honestly. You put it on one real, low-stakes project. It works. That earns Trial.
It has now handled real work for weeks without nasty surprises. You move it to Adopt and reach for it by default. The tweet became a tool, one ring at a time.
The method only helps if you use it, so make it tiny and repeatable. Click through the five steps of a personal radar you can run in a notes app in fifteen minutes a month.
A radar organizes your attention; it does not grant certainty. Hold it loosely.
Benchmarks can be contaminated. If a test's questions leaked into a model's training data, its score is inflated and meaningless. This happens more than anyone admits, which is exactly why your own test outranks any leaderboard.
Everything moves faster than your radar. A blip you placed in Trial can be made obsolete next week by something newer. The radar is a monthly snapshot, not a live feed. Re-check the things you actually depend on.
Open and closed models trade differently. An open model you can run yourself buys privacy and control; a closed model behind an API often buys raw capability and no maintenance. "Better" depends on which you are optimizing, and your radar should note which is which.
Recency is not quality. The newest model is not automatically the one to adopt, and the loudest trend is not the most useful. The rings exist precisely to slow your excitement down to the speed of evidence.
Capability is task-specific: read the card, check the arena, try it yourself.
The sources are few and namable; visit two a week.
Trends belong on a radar that moves on evidence, not noise.
You are not behind. You just needed a map.
Put it together on any claim you meet. Pick what evidence actually exists for a new model or trend, and read which ring it has earned and how much to trust it. The presets are three claims you will genuinely see this month.
Seven rabbit holes the main path stepped around. Each stands alone.
lm-evaluation-harness, a program that runs a model against dozens of standard benchmarks with one command. Overkill for a beginner, but worth knowing it exists: it means "the benchmark" is reproducible code, not a magic number, and you can point the same tool at your own tasks.