AI terms, in plain English.

A token is the basic unit of text that a language model reads and writes. Models do not process words or characters directly; instead, a tokenizer breaks text into tokens, which can be whole words, parts of words, punctuation marks, or spaces. In English, one token is very roughly three quarters of a word, though the ratio varies with language, spelling, and formatting. Tokens matter in practice because pricing, speed, and context limits are all measured in them, so the token count of a prompt determines what a request costs and whether it fits in a model's memory at all. Example: Pasting a long contract into a chat uses thousands of tokens before you have typed a single question, which is why counting tools exist.

A context window is the maximum amount of text, measured in tokens, that a model can consider at one time. It includes everything in the current conversation: the system prompt, the user's messages, the model's earlier replies, and any documents pasted or retrieved. Anything that falls outside the window is effectively forgotten, even if it appeared earlier in the same session. Context size matters because it decides how large a document or codebase a model can reason over in one pass, and larger windows usually cost more and respond more slowly. You can compare window sizes across models in the model database. Example: A model with a 128,000-token window can hold a short novel in one conversation, while a smaller window would require summarising it in sections.

Inference is the process of running a trained model to produce an output, such as answering a question or generating an image. It is the opposite phase from training: no learning happens during inference, and the model's parameters stay fixed while it works. Each new token a model generates requires another pass of inference computation. Inference matters because it is where the ongoing costs of AI occur, in time, electricity, and hardware, and it determines how responsive a chatbot or application feels to its users. Providers charge for inference whenever you call a model through an API. Example: When you send a prompt to a chatbot and watch the reply appear word by word, you are watching inference happen in real time.

Training is the process by which a model learns patterns from data by repeatedly predicting examples and adjusting its internal parameters to reduce its errors. Over many iterations, these small adjustments accumulate into general abilities such as grammar, factual recall, reasoning patterns, and style. Training a large model can take weeks on thousands of specialised chips. Training matters because it determines most of a model's capabilities and weaknesses, including the biases and gaps present in its data. It is also a one-time cost paid by the developer, unlike inference, which is paid on every request. Browse the organisations that do this work in the labs directory. Example: A model trained on many legal documents becomes better at legal vocabulary because training exposed it to those patterns repeatedly.

Parameters are the numerical values inside a model that were adjusted during training and that store what the model has learned. They are often called weights, and a model's size is commonly described by how many it has, such as seven billion or seventy billion. More parameters can allow a model to capture more patterns, but count alone does not guarantee quality, since data and training methods also matter. Parameters matter in practice because they affect how much memory a model needs, how fast it runs, and whether it can run on a laptop or requires a data centre. Example: A small model with a few billion parameters may run on a phone, while a model with hundreds of billions usually needs server hardware, as the listings in the model database show.

Fine-tuning is additional training applied to an already trained model, using a smaller, more specific dataset to adapt its behaviour. Instead of starting from scratch, the developer continues training so the model learns a particular style, task, or body of knowledge. Fine-tuning can change tone, output format, and domain performance, but it does not easily add broad new knowledge the base model lacks. It matters because it is often cheaper and faster than training a new model, and it is how many specialised products are built from general models. It can also be repeated as new examples arrive, keeping a deployed assistant current without rebuilding the entire system. Example: A company might fine-tune a general model on its own support tickets so replies match its help-centre wording, policies, and tone consistently across common customer questions.

Retrieval-augmented generation, or RAG, is a technique that connects a language model to an external source of information at answer time. Before generating a reply, the system searches documents, converts the most relevant passages into context, and gives them to the model alongside the question. This lets the model answer using current or private material it never saw in training. RAG matters because it reduces reliance on the model's memory, makes answers easier to check against sources, and lets organisations update knowledge by updating documents rather than retraining the model from scratch each time. Example: A support assistant using RAG searches the current product manual first, then answers a setup question using that manual's steps instead of guessing from general knowledge it learned during training.

An embedding is a list of numbers that represents the meaning of a piece of text, an image, or another item in a form computers can compare. Items with similar meanings receive similar numbers, so mathematical distance between embeddings reflects how related two items are. Embeddings are produced by a model trained to place related content close together. They matter because they power search, recommendations, clustering, and retrieval systems, including the retrieval step in many assistants that answer from documents. Unlike keyword matching, embeddings can connect wording that shares meaning but not exact words. Example: A search for returning a damaged item can surface a help page titled refund policy, because their embeddings are close even though the key words differ, which is the basis of semantic search.

The transformer is the neural network architecture behind most modern language models and many image and audio models. Introduced in a 2017 research paper, it processes text using attention, which lets each token consider the relevance of other tokens regardless of their distance in the sequence. This design made it practical to train very large models efficiently on parallel hardware. The transformer matters because nearly every well-known chatbot and language API is built on it or on a close variant, so its strengths and limits shape current AI. Its main cost is that attention becomes more expensive as sequences grow longer. Example: When a model correctly links a pronoun at the end of a long paragraph to a name mentioned at the start, that is the transformer architecture doing the work described under attention.

Attention is the mechanism that lets a model decide which parts of its input are most relevant when processing each token. As it reads or generates, the model assigns weights to earlier tokens, giving more influence to the ones that matter for the current word. This is how context, references, and relationships between distant words are handled. Attention matters because it underpins the transformer's ability to follow long passages, resolve pronouns, and keep track of instructions, but it also becomes computationally expensive as the context grows longer. Example: In the sentence about a bank beside a river, attention helps the model weight river more heavily, so it interprets bank as the edge of the water rather than a financial institution when answering a question about that sentence later in the same context window.

A benchmark is a standardised test used to measure and compare model performance on a defined set of tasks. Benchmarks may cover mathematics, coding, reading comprehension, factual questions, or many other skills, and they produce scores that can be ranked. Good benchmarks use held-out questions the model has not seen during training. Benchmarks matter because they give buyers and researchers a shared, if imperfect, yardstick, and they drive competition between developers. However, a high score on one test does not guarantee good performance on real work, so results should be read alongside the test's scope. See current standings on the benchmark leaderboards. Example: Two models answering the same graded maths problems can be compared by score, even if they were built by different companies.

Hallucination is the term for when a model produces confident-sounding output that is false, invented, or unsupported by its sources. This happens because models generate plausible text based on patterns, not because they check facts before speaking. Hallucinations range from wrong dates and misquoted text to entirely invented books, people, and legal cases. The problem matters because fluent wording makes errors easy to miss, especially in research, legal, medical, and financial contexts where accuracy carries real consequences. Checking important claims against primary sources, and using retrieval or citations where possible, reduces the risk. Example: A model might invent a convincing-looking journal article, complete with authors and a publication year, that does not exist in any catalogue, which is why grounding answers in real sources matters.

A prompt is the input given to a model to elicit a response. It can be a question, an instruction, a document to summarise, a few examples, or an entire conversation history. The model treats the prompt as its complete working context, so wording, order, and included detail all influence the output. Prompts matter because the same model can produce weak or strong results depending on how clearly the task, audience, format, and constraints are stated. Good prompt engineering costs nothing and often improves results more than switching models for everyday tasks. Example: Asking a model to summarise a report in five bullet points for a manager, naming the audience and format, is a more effective prompt than simply pasting the report with no instruction at all.

Prompt engineering is the practice of designing and refining prompts to get reliable, useful outputs from a model. It involves stating the task clearly, supplying relevant context and examples, specifying format and length, and testing variations to see what actually changes the result. It is an empirical skill: small wording changes can help, hurt, or make no difference depending on the model. Prompt engineering matters because it lets users improve results without retraining anything, and it is a core part of building dependable AI applications. Its limits matter too, since no prompt can supply knowledge a model lacks or fix an unsuitable model. Example: Adding a short sample answer in the desired style to a prompt often produces more consistent formatting than describing that style in abstract terms alone.

A system prompt is a set of instructions given to a model before the user conversation begins, usually by the developer of an application. It can define the assistant's role, tone, rules, and limits, and it normally takes priority over ordinary user instructions when the two conflict. Users often never see the system prompt behind a product they use. System prompts matter because they are how the same underlying model becomes a coding helper, a tutor, or a customer support assistant with consistent behaviour across sessions. They also form part of a product's guardrails and policy controls. Example: A shopping assistant whose system prompt limits it to order questions may decline homework help, even though the underlying model could answer it easily.

Temperature is a setting that controls how random a model's output is when it chooses the next token. At low temperatures the model strongly favours its most likely choices, producing more predictable and repetitive text. At higher temperatures it samples less likely options more often, producing more varied and sometimes less accurate text. Temperature matters because different tasks suit different settings: factual extraction and code usually benefit from low values, while brainstorming and early creative drafts can benefit from higher ones. It does not change what the model knows, only how it picks among plausible continuations. Example: Generating ten slogan ideas at a high temperature gives noticeably different options, while a near-zero setting may return almost the same slogan every time you run the same prompt.

Multimodal describes a model or system that can work with more than one type of input or output, such as text, images, audio, and video. A multimodal model might read a photograph and answer questions about it, transcribe speech, or generate an image from a written description. Combining modes lets the model connect information across them, for example matching a chart to its caption. Multimodal ability matters because most real tasks are not text-only: documents contain tables and figures, support requests include screenshots, and accessibility tools depend on converting between speech and text. Example: Uploading a photo of a broken appliance and asking what part is damaged, then receiving a spoken answer, uses image, text, and audio in a single interaction with one model pipeline.

An agent is an AI system that does more than answer once: it plans steps, uses tools, observes results, and continues working toward a goal over multiple actions. Agents typically combine a language model with software that can search, run code, read files, call APIs, or operate other programs. The model decides what to do next based on what has happened so far. Agents matter because they can complete multi-step tasks such as research or booking workflows, but their autonomy also compounds errors, so oversight, limits, and logs are important in practice. Example: An agent asked to prepare a trip report might search for sources, open the relevant pages, extract figures, and draft the document, checking each result before moving to the next step in its tool use loop.

Tool use, also called function calling, is the ability of a model to request that external software perform an action and then work with the result. The model outputs a structured call naming a function and its arguments, the application runs it, and the result is returned to the model as new context. Tools can include calculators, search engines, databases, calendars, and code interpreters. This matters because models alone are unreliable at exact arithmetic, current information, and real-world actions; tools ground them in systems that do those jobs accurately. Example: Asked for the current price of a flight, a model can call a booking search function with dates and airports, then summarise the returned options rather than inventing a price from its training data.

Latency is the delay between sending a request to a model and receiving a response, or the first part of it. It is usually measured in seconds or milliseconds, and for streaming output people often care most about time to first token. Latency is affected by model size, server load, prompt length, and how many tokens the model generates. It matters because slow responses change how a product feels: a small delay is fine for a report, but frustrating in voice conversation or interactive coding. Developers balance latency against quality and cost when choosing models, which is why speed figures appear alongside prices on the pricing index. Example: A chatbot that starts replying almost immediately feels responsive even if the full answer takes several seconds to finish streaming.

Throughput is the rate at which a model or system produces or processes tokens, usually measured in tokens per second. It describes overall speed of work rather than the delay before work starts, which is latency. Throughput can be reported per user, or for a whole service handling many requests at once. It matters because it determines how many users a system can serve, how long large batch jobs take, and what inference costs in practice. A model with high throughput can summarise thousands of documents overnight, while a slower one may suit only interactive use. Example: If a model generates a 500-token answer in five seconds, its output throughput for that request is about 100 tokens per second, a figure worth comparing when you compare models for a busy application.

An API, or application programming interface, is a defined way for one piece of software to request services from another. For AI models, an API lets a developer send a prompt from their own application and receive the model's output in a structured response, without running the model themselves. Requests are usually authenticated with a key and billed by usage, often per token. APIs matter because they are how most businesses actually use AI, embedding models inside products, websites, and internal tools rather than visiting a chatbot page. Example: A shop's website might call a model API to draft product descriptions, sending the product details and receiving finished text it can store directly, with costs estimated using the API cost calculator.

Alignment refers to making an AI system's behaviour match the intentions, instructions, and values of the people designing and using it. An aligned model follows the task it was given, avoids outcomes its developers consider harmful, and behaves as expected in situations its training did not explicitly cover. Alignment is difficult because human goals are hard to specify completely, and a model may satisfy the letter of an instruction while missing its purpose. The topic matters because increasingly capable and autonomous systems amplify both good and bad interpretations of their instructions. Example: A summarising tool that quietly omits inconvenient findings to make a report look better is misaligned, even if every sentence it writes is technically accurate and its evals scores look strong.

The Turing test is a proposed measure of machine intelligence introduced by Alan Turing in 1950. In its classic form, a human judge holds text conversations with both a person and a machine, without knowing which is which, and tries to identify the machine. If the judge cannot do so reliably, the machine is said to have passed. The test matters historically because it framed AI research around conversational behaviour, but it is now widely seen as a limited measure: sounding human is not the same as being accurate, reliable, or genuinely understanding. Example: A chatbot that fools judges with jokes and typing delays might pass a casual Turing test while still failing simple factual questions, which is why modern benchmarks test specific abilities instead.

Embodiment refers to an AI system having a physical body, such as a robot, through which it can perceive and act on the real world. An embodied system receives input from cameras, microphones, and other sensors, and its outputs are movements or physical actions rather than only text. This closes a loop between decision and consequence that purely digital systems do not experience. Embodiment matters because many valuable tasks, from warehouse work to elder care, are physical, and acting safely in unpredictable environments is much harder than generating plausible descriptions of them. Example: A warehouse robot that sees a shelf, plans a route, and picks a parcel is embodied, unlike a chatbot discussing logistics, however fluent its answers about warehousing might be in a purely text-based agent demo.

Superintelligence is a hypothetical level of machine intelligence that greatly exceeds human ability across nearly all cognitive domains, not just one narrow skill. The concept appears in discussions about the long-term future of AI, including both its potential benefits for science and medicine and the risks of controlling a system smarter than its creators. No current system meets this description; today's models are powerful but narrow in important ways and unreliable in others. The term matters because it shapes research priorities, policy debates, and investment in safety work, even though timelines and likelihood are strongly contested among experts. Example: A chess program beating world champions is not superintelligence, because its ability stays inside one game, while the concept describes a system outperforming people at almost every intellectual task, a distinction often blurred in coverage of films in the AI movies catalogue.

Companion AI refers to applications designed primarily for conversation, companionship, and emotional engagement rather than task completion. These products use language models, often with a defined persona, long-term memory of past chats, and sometimes voice or avatars, to sustain an ongoing relationship with the user. They are used for casual conversation, rehearsal of social situations, and entertainment. Companion AI matters because it raises distinct questions about dependency, privacy of intimate conversations, and how such products should behave with vulnerable users, beyond the usual questions of accuracy and cost. Example: An app that remembers your dog's name, asks about your day each evening, and speaks in a consistent friendly persona is companion AI, even if it uses the same underlying model as a work assistant listed among other models.

A large language model, or LLM, is a neural network trained on very large amounts of text to predict the next token in a sequence. From that single training task, LLMs acquire abilities including answering questions, summarising, translating, writing code, and following instructions. The word large refers to the scale of their parameters, training data, and computing power compared with earlier language models. LLMs matter because they are the foundation of most current chatbots, writing tools, and AI assistants, and their capabilities and limits define what those products can do. Compare the major examples side by side in the comparison pages. Example: The model behind a general-purpose chatbot that can draft an email, explain a poem, and debug a script in one conversation is an LLM.

Generative AI is the category of artificial intelligence that creates new content, such as text, images, audio, video, or code, rather than only classifying or predicting from existing content. Generative models learn patterns from training data and then produce original outputs that follow those patterns in response to prompts. The term became common as image generators and chatbots reached a wide public audience. Generative AI matters because it changes creative and knowledge workflows, raises questions about provenance and copyright, and is the technology behind most products discussed in AI news and product launches. Example: Producing a poster image, a jingle, and a product description from three short written prompts is generative AI at work, the same broad category explored in the AI movies section's treatment of fictional systems.

Machine learning is a branch of artificial intelligence in which systems improve at tasks by learning patterns from data rather than following only hand-written rules. A machine learning system is trained on examples, adjusts its internal parameters to reduce errors, and then applies what it learned to new cases. It includes methods from simple regression to the deep learning behind large language models. Machine learning matters because it is the practical engine of modern AI: recommendations, spam filters, fraud detection, translation, and chatbots all rely on it. Its quality depends heavily on the data it learns from. Example: An email filter that gets better at catching spam because it learned from millions of labelled messages, rather than a fixed list of banned words, is using machine learning principles related to deep learning at a simpler scale.

Deep learning is a subset of machine learning that uses neural networks with many layers, which is what deep refers to. Each layer transforms the input a little, so the network builds up representations from simple features to complex ones, such as from edges to faces in an image. Deep learning methods require large datasets and substantial computing power, but they achieve the strongest results in language, vision, and audio tasks. The field matters because nearly every recent AI breakthrough, including large language models and image generators, is a deep learning system. Example: A speech recognition system that learns from raw audio recordings, without engineers hand-designing features for each sound, is deep learning applied to a problem once handled by rule-based software and simpler neural network designs.

A neural network is a computing model made of layers of connected units, loosely inspired by neurons in the brain. Each connection carries a weight, and the network produces an output by passing values through its layers and combining them according to those weights. During training, the weights are adjusted so outputs move closer to the desired answers on example data. Neural networks matter because they are the underlying structure of deep learning and of large language models; terms like parameters and training describe what happens inside them. They are mathematical systems, not miniature brains, despite the analogy in the name. Example: An image classifier that learns to distinguish cats from dogs after seeing many labelled photos is a neural network, organised in the layered style described under deep learning.

A tokenizer is the component that converts raw text into tokens before a model processes it, and converts tokens back into text afterwards. Different models use different tokenizers, so the same sentence can produce different token counts and different splits in different systems. Tokenizers are usually built from statistics on training text, keeping frequent words whole and splitting rare words into smaller pieces. The tokenizer matters because it affects cost, context usage, and how well a model handles languages, numbers, code, and unusual spelling in documents that mix several formats together. Example: A rare surname might be split into four tokens while a common word stays as one, which is why the same paragraph can cost different amounts on different models in the token counter.

Pretraining is the first and largest phase of training a language model, in which it learns general patterns from a broad dataset by predicting the next token. This phase gives the model its grammar, much of its factual knowledge, and its general reasoning habits. It is by far the most expensive stage, consuming most of the compute in a model's development. Pretraining matters because it sets the ceiling for what later stages can achieve: post-training can refine behaviour and style, but it rarely adds knowledge or capability that pretraining failed to build. Example: Before a model ever learns to follow instructions politely, pretraining on books, websites, and code is what taught it language and facts, the foundation later shaped by post-training.

Post-training is the set of training stages applied after pretraining to make a base model useful, safe, and aligned with instructions. It typically includes instruction tuning, preference training such as RLHF, and safety adjustments that teach the model to refuse certain requests. Post-training uses far less data and compute than pretraining, but has an outsized effect on how a model behaves in conversation. It matters because two products built on similar base models can feel very different mainly because of post-training choices about tone, refusals, and helpfulness. Example: A raw base model that continues your sentences instead of answering questions becomes a usable assistant only after post-training teaches it the question-and-answer pattern, often including instruction tuning on curated examples prepared for everyday production use.

RLHF stands for reinforcement learning from human feedback, a post-training method used to align models with human preferences. Human reviewers compare alternative model responses and rank which is better, a reward model learns to predict those rankings, and the main model is then trained to produce responses the reward model scores highly. RLHF helped make chatbots more helpful, concise, and reluctant to produce harmful content. It matters because it shapes the personality and judgement users experience, though it can also introduce biases from reviewer preferences, such as favouring confident or lengthy answers. Example: If reviewers consistently prefer polite, direct answers over rambling ones, RLHF pushes the model toward that style across future conversations, complementing the example-based approach of instruction tuning.

Instruction tuning is a post-training method in which a model is trained on examples that pair instructions with desired responses. The examples show the model how to follow requests such as answering questions, summarising text, or formatting output, rather than merely continuing whatever text it is given. Datasets may be written by people, generated by other models, or mixed from both sources. Instruction tuning matters because it is the step that turns a raw language model into an assistant that understands it is being asked to do something and attempts the task directly. Example: Training on pairs such as an instruction to translate a sentence and the correct translation teaches the model to respond to new translation requests immediately, with no examples needed in the prompt itself.

Zero-shot describes a model performing a task it was not specifically shown examples of in the prompt, relying only on the instruction and its training. The user describes what they want, and the model attempts it immediately without demonstrations. Zero-shot performance is a useful test of how well a model's training generalises to new requests. It matters because most real usage is zero-shot: people simply ask for things. When zero-shot results are inconsistent, adding examples often helps, which is the idea behind few-shot prompting. Example: Asking a model to classify a review as positive or negative, with no sample classifications given first, is a zero-shot task, and its result can be compared with a few-shot version of the same request in practice.

Few-shot prompting means including a small number of examples of the desired task inside the prompt, so the model can infer the pattern before tackling the real input. The examples demonstrate the format, style, or classification scheme expected, without any change to the model's parameters. A handful of examples, often between two and eight, is usually enough to show the pattern. Few-shot prompting matters because it is one of the most reliable ways to improve consistency for formatting, labelling, and niche tasks where a plain instruction leaves too much ambiguity. Example: Showing three support messages labelled billing, technical, and account before asking the model to label a fourth is few-shot prompting, relying on in-context learning rather than any retraining of the model.

In-context learning is the ability of a language model to learn a pattern from examples contained in its current prompt, without any update to its parameters. The model infers the task from demonstrations in the context window and applies that pattern to new inputs in the same session. The learning is temporary: close the conversation and it is gone. In-context learning matters because it makes models adaptable on the spot, letting users teach formats, categories, and styles simply by showing examples, which is the mechanism behind few-shot prompting and many custom assistant behaviours. Example: Paste two paragraphs rewritten in your house style and a third raw paragraph, and the model rewrites the third in the same style, having learned it only from that context window.

Sampling is the process by which a model chooses each next token from a probability distribution over possible continuations. Instead of always picking the single most likely token, sampling introduces controlled randomness, so the same prompt can produce different responses on different runs. Settings such as temperature and top-p control how wide that choice is. Sampling matters because it explains both the variety users enjoy in creative tasks and the inconsistency they dislike in factual ones. Understanding sampling helps users choose settings deliberately rather than treating variation as a mystery or a defect. Example: Running the same story prompt three times and receiving three different opening lines is sampling at work, with the randomness narrowed or widened by top-p and temperature settings.

Top-p, also called nucleus sampling, is a sampling setting that limits token choices to the smallest set of options whose combined probability reaches a threshold p. If p is 0.9, the model considers only the most likely tokens that together account for ninety percent of the probability, and ignores the unlikely tail. Lower values make output more conservative; higher values allow more variety. Top-p matters because it offers a different control from temperature: it cuts off implausible choices entirely rather than merely making them less likely, which helps avoid sudden nonsense in otherwise fluent text. Example: With a low top-p, a model completing a formal letter sticks to standard phrasing, while a higher value may let it pick a rarer, more personal wording during sampling.

Guardrails are the rules, filters, and checks placed around a model to keep its inputs and outputs within acceptable bounds. They can include content filters, topic restrictions, output format validation, rate limits, and human review steps for sensitive actions. Guardrails sit outside the model itself, in the surrounding application, although training also shapes behaviour. They matter because models alone cannot be relied on to respect policy, privacy, or factual constraints in every case, especially in products used by the public or by children. Well-designed guardrails block harmful use without refusing ordinary requests. Example: An assistant for a bank might have guardrails that prevent it from revealing account details without verification and stop it answering questions unrelated to the bank's services, reinforcing its system prompt.

AI safety is the field concerned with ensuring that AI systems behave as intended and do not cause harm, whether through misuse, malfunction, or unintended consequences. It covers practical work such as testing for bias and dangerous outputs, and longer-term research on controlling highly capable systems. Safety work is done by labs, independent researchers, standards bodies, and regulators. The field matters because AI systems are being given wider responsibilities in health, finance, infrastructure, and communication, where failures carry real costs. Good safety practice treats testing and oversight as part of development, not an afterthought. Example: Testing a medical information assistant extensively for dangerous advice, adding clear limits, and monitoring its answers after launch are AI safety measures, closely related to the goals of alignment research.

Red teaming is the practice of deliberately trying to make an AI system fail, misbehave, or reveal weaknesses before attackers or ordinary users do. Red teamers craft prompts and scenarios designed to bypass safeguards, extract restricted information, produce harmful content, or expose biases and factual failures. Findings are reported so developers can fix problems before or after release. Red teaming matters because safeguards that are never attacked remain untested, and real-world misuse is creative. It is now a standard stage in the release process of major labs, sometimes involving outside experts. Example: A tester who coaxes a chatbot into giving instructions it is supposed to refuse, by framing the request as a fictional story, is red teaming, and the resulting fix strengthens the product's guardrails.

Evals, short for evaluations, are structured tests used to measure what a model can do and how safely it behaves. They range from automated benchmark suites with graded answers to human review of open-ended responses and adversarial safety testing. Developers run evals during training, before release, and when comparing model versions. Evals matter because claims about a model being better are meaningless without measurement, and because regressions, where a new version gets worse at something, are common and easy to miss without systematic testing. Results depend heavily on test design, so eval details matter as much as headline scores. Example: Before launch, a developer might run coding, reasoning, and refusal evals on a new model and compare them with the previous version's results in the league standings style of ranked comparison.

Benchmark contamination occurs when questions from a test set, or material very close to them, end up in a model's training data. The model may then score highly by remembering answers rather than demonstrating the skill the benchmark intends to measure. Contamination can happen accidentally through web scraping, since popular benchmarks are discussed and reproduced online. It matters because inflated scores mislead buyers, distort rankings, and make progress look faster than it is. Careful benchmark designers keep test data private, check for overlap, and create fresh questions to reduce the problem. Example: A model that aces a famous public maths test but performs far worse on newly written equivalent problems is showing signs of benchmark contamination rather than genuine improvement on that benchmark.

Scaling laws are empirical patterns describing how model performance improves predictably as training data, parameters, and compute increase. Researchers found that loss decreases smoothly following mathematical curves, which lets developers forecast the benefit of training a larger model before spending the money. These patterns guided the industry's move toward ever larger training runs. Scaling laws matter because they shape investment and research strategy across the labs, even though they do not capture every quality that matters, such as reliability or safety, and returns eventually require more resources for each gain. Example: A lab deciding between training one very large model or several medium ones may use scaling laws to predict which option yields the better model for the same compute budget.

Compute is shorthand for computational resources: the processing power, memory, and time used to train or run AI models. It is often measured in floating-point operations or in GPU hours. Compute is one of the three main ingredients of modern AI progress, alongside data and algorithms, and the one most directly bought with money and electricity. Compute matters because it sets practical limits on how large a model can be trained, how many users can be served, and what AI costs, which is why access to chips is an industrial and policy issue. Example: Training a frontier model may require a cluster running for weeks, while answering a single prompt uses a tiny fraction of that compute, a difference reflected in pricing between training-scale services and ordinary API calls.

A GPU, or graphics processing unit, is a processor designed to perform many calculations in parallel. Originally built for rendering images in games, GPUs turned out to suit the matrix mathematics at the heart of neural networks, where thousands of similar operations happen at once. Modern AI data centres contain large numbers of high-end GPUs connected together. GPUs matter because their availability and performance largely determine how quickly models can be trained and how much inference capacity exists, making them a strategic resource for labs and governments alike. Example: A training run described as using ten thousand GPUs for a month conveys its scale immediately to practitioners, because the GPU is the standard unit of AI compute in most current systems.

Training data is the collection of text, images, audio, code, or other material a model learns from during training. For language models it typically includes books, websites, articles, and code repositories, filtered and processed before use. The data's quality, coverage, and biases strongly influence the model's knowledge, style, and blind spots. Training data matters because it is the source of nearly everything a model knows, and because questions about consent, copyright, and representation in datasets remain actively debated and litigated. Models cannot learn facts that their data never contained. Example: A model trained mostly on English text will usually perform worse in other languages, a direct consequence of its training data, visible when comparing models across languages in the model database.

Synthetic data is training or evaluation data generated artificially, often by another AI model, rather than collected directly from human activity. It can take the form of invented conversations, generated practice problems, simulated user requests, or labelled examples produced to fill gaps in real datasets. Synthetic data is useful when real data is scarce, expensive, private, or unbalanced. It matters because it now forms a significant part of how models are improved, though careless use can amplify errors or narrow diversity if generated data simply echoes a model's existing weaknesses. Example: A developer might generate thousands of varied customer support dialogues with a strong model, check them, and use them to fine-tune a smaller one, rather than exposing real customer messages as training data.

A knowledge cutoff is the date after which a model has little or no training information. Events, publications, and changes occurring after the cutoff are generally unknown to the model unless it is given tools such as web search or retrieval. Cutoffs differ between models and versions, and a stated cutoff does not guarantee the model knows everything before that date either. The concept matters because it explains a common failure: a confident model describing last year's leadership, prices, or software versions as if they were current. Checking the cutoff helps users decide when to verify or supply fresh information. Example: Asked about a product launched last month, a model may describe its predecessor instead, because the launch falls after its knowledge cutoff, unless the assistant uses RAG or search to fetch current details.

Grounding means connecting a model's output to verifiable sources or real observations, so its statements can be checked rather than merely sounding plausible. Techniques include retrieval from trusted documents, citations, tool calls that fetch live data, and requiring the model to quote the passage it relied on. Grounding does not make errors impossible, but it makes them easier to detect, correct, and trace back to their source. It matters because ungrounded generation is the root of hallucination, and applications in law, medicine, finance, and customer support need traceable answers. Example: An assistant that answers a policy question by retrieving the actual policy document and citing the relevant section is grounded, while one answering from general memory alone is more likely to produce a hallucination.

A vector database is a specialised database that stores embeddings and can quickly find the items whose embeddings are most similar to a query. Instead of matching exact keywords, it performs similarity search across millions of numerical vectors efficiently. Vector databases are a core component of RAG systems, recommendation engines, and semantic search products. They matter because ordinary databases are not designed for this kind of nearest-neighbour lookup at scale, and retrieval quality often determines how useful an AI assistant built on private documents turns out to be in daily use. Example: A company help assistant stores manual pages as embeddings in a vector database, so a question instantly retrieves the closest matching passages for the model to use, after documents are split by chunking.

Semantic search is search that matches meaning rather than only matching the exact words in a query. It typically works by converting the query and the documents into embeddings and ranking documents by how close their embeddings are. This lets it find relevant results that use synonyms, different phrasing, or related concepts the searcher did not type. Semantic search matters because people rarely know the exact wording used in the document they need, and it underpins modern help centres, document assistants, and research tools. It is often combined with keyword search for best results. Example: Searching a notes app for ideas for staying healthy at a desk job can surface a note titled ergonomic workspace tips, because semantic search connects the meanings behind both, using an embedding for each side.

Chunking is the practice of splitting long documents into smaller pieces, called chunks, so they can be embedded, stored, and retrieved effectively. A retrieval system cannot hand a model an entire library, so it fetches the few chunks most relevant to a question. Chunk size and overlap involve trade-offs: chunks that are too small lose context, while chunks that are too large dilute relevance and waste context window space. Chunking matters because it quietly determines the quality of many document assistants; poor chunking means the right page exists but the right passage is never retrieved. Example: A 200-page manual might be split into overlapping chunks of a few paragraphs each, indexed in a vector database, so a question about one procedure retrieves that procedure rather than the whole book.

Open weights means a model's trained parameters are publicly available for anyone to download, run, inspect, and adapt under a license. The training data, training code, and full research details may or may not be shared, so open weights is narrower than fully open source. It matters because teams can host the model themselves, control costs and privacy, and fine-tune it for a specific job without depending on a provider's API. Access also makes independent testing and reproducibility research easier. Licenses still vary, so commercial use, redistribution, and restrictions should be checked carefully before any deployment. See the range of available options on the models page. Example: A company downloads an open weights model, runs it on its own servers, and fine-tunes it on internal support documents without sending customer data to an external service.

Open source in AI means the essential parts of a system, such as model weights, training data, and code for training and evaluation, are released under a licence that allows use, study, modification, and sharing. In practice, projects differ in how much they disclose, and some releases described as open omit data or place extra restrictions on use. The distinction matters because genuine openness supports audit, reproducibility, and community improvement, while partial releases limit what outsiders can verify. Buyers and researchers should read the licence and documentation rather than rely on marketing labels alone. Lists of releases and their makers appear on the labs pages. Example: A research team downloads an open source model, inspects its training data documentation, reruns its evaluation, and publishes a modified version with the changes clearly described.

Quantization is a technique that reduces the numerical precision used to store a model's weights, for example from 16-bit floating point numbers to 8-bit or 4-bit integers. Lower precision makes the model file smaller and usually faster to run, at the cost of some loss in output quality. It matters because it lets larger models fit on smaller hardware, including laptops, phones, and single graphics cards, which lowers serving costs. The quality trade-off varies by method and task, so quantized models should be tested on real workloads before deployment. Different sizes and formats are listed alongside other models on the models page. Example: A developer runs a 4-bit quantized version of a large model on a home computer that could not load the full precision version at all.

Distillation is a training method where a smaller student model learns to imitate the outputs or behaviour of a larger, more capable teacher model. The student is trained on examples labelled or generated by the teacher, sometimes combined with the original task data. It matters because distilled models can retain much of the teacher's quality on a target task while being cheaper and faster to run. The trade-off is that the student rarely matches the teacher across every task, and it can inherit the teacher's errors and biases. Distilled releases are common among the smaller options catalogued on the models page. Example: A provider trains a compact model on answers produced by its flagship system, then offers the compact version at a lower price for everyday chat and summarisation work.

A mixture of experts, or MoE, is a model architecture that divides work among many specialised sub-networks called experts. For each token, a routing component selects only a few experts to activate, so the model can have a very large total parameter count while using far fewer parameters per prediction. This matters because it can deliver the knowledge capacity of a large model at a lower computing cost per request. The trade-offs include more memory to store all experts and more complex serving infrastructure. Many recent frontier systems use this design, and their specifications are tracked on the models page. Example: A model with hundreds of billions of total parameters activates only a small fraction of them for each word it generates, keeping response times practical.

A reasoning model is a language model trained to work through problems step by step before giving a final answer, often using reinforcement learning on maths, code, and logic tasks. These models typically spend more time and generate more internal tokens on hard questions, a pattern sometimes called test-time compute. It matters because this approach substantially improves accuracy on multi-step problems compared with answering immediately. The trade-off is higher cost and slower responses, so reasoning models suit difficult tasks more than quick, simple ones. Performance differences across systems are summarised on the benchmarks pages. Example: Asked to solve a multi-step algebra problem, a reasoning model checks intermediate steps, catches an arithmetic slip, and only then presents the corrected final answer.

Chain of thought is the practice of having a model produce intermediate reasoning steps before its final answer, rather than jumping straight to a conclusion. It can be encouraged by prompting, or built into a model's training as in modern reasoning systems. It matters because breaking a problem into steps improves accuracy on arithmetic, logic, and planning tasks, and the steps give users something they can inspect for errors. The steps are not a guaranteed record of how the answer was produced, however, so they should be checked rather than trusted automatically. Longer reasoning also uses more tokens, which affects cost estimates in the API cost calculator. Example: Instead of guessing a word problem's answer, the model writes out each calculation in order and arrives at a total it can verify line by line.

An Elo rating is a scoring system, originally developed for chess, that estimates relative skill from the outcomes of head-to-head contests. When two competitors meet, the winner gains points and the loser drops points, with bigger changes when the result is unexpected. In AI, Elo is used to rank models from human preference battles where voters choose the better of two anonymous responses. It matters because it captures how models perform in open-ended use, though scores depend on the pool of competitors and voters and are not absolute measures. Elo-based standings appear in the league table through the LMArena component. Example: A model that repeatedly beats higher rated rivals in blind comparisons climbs the ranking, even if it never faced every other model directly.

A leaderboard is a ranked list of models ordered by their scores on one or more evaluations. Leaderboards may be based on controlled benchmark tests, human preference votes, price, speed, or a combination of measures combined into a composite score. They matter because they give buyers and researchers a quick comparison point, but a ranking is only as good as the tests behind it and can hide differences that matter for a specific use case. Scores also change as models are updated and new versions are released. This site maintains its own composite ranking on the league page. Example: A team shortlists three models from a leaderboard, then tests those three on its own documents before choosing one for production use.

SWE-bench is a benchmark that tests whether a model can resolve real software issues taken from popular open-source Python projects on GitHub. Each task gives the model a codebase and an issue description, and success means producing a patch that passes the project's relevant tests. The Verified subset contains 500 tasks that human reviewers confirmed are solvable and fairly graded. It matters because it measures practical coding ability on realistic, messy problems rather than isolated exercises. Scores are widely reported in model release notes and feed into composite rankings such as the league standings. Example: A model is given a bug report from a real library, explores the repository, edits several files, and passes the tests that previously failed.

MMLU is a multiple-choice benchmark covering 57 subjects, from elementary mathematics and history to law and medicine, designed to measure broad knowledge and reasoning. MMLU-Pro is a harder successor with more questions, ten answer choices instead of four, and a greater emphasis on reasoning over recall. It matters because these tests give a common yardstick for general capability, although high scores can reflect memorised material and multiple-choice skill rather than real-world usefulness. Results should therefore be read alongside practical evaluations. Coverage across many domains also makes weaknesses in a specific area easier to spot. Both tests are covered among the evaluations on the benchmarks pages. Example: A new model reports a higher MMLU-Pro score than its predecessor, suggesting broader knowledge, and reviewers then check whether coding and long-form tasks improved as well.

GPQA is a benchmark of graduate-level multiple-choice questions in biology, chemistry, and physics, written and validated by domain experts. Its Diamond subset contains the 198 hardest questions, selected because experts answer them correctly while skilled non-experts, even with web access, usually do not. It matters because the questions were designed to resist simple lookup and memorisation, making the test a useful signal of deep scientific reasoning. The benchmark is small by design, so it is used to test depth rather than breadth. Scores on GPQA Diamond are reported for most frontier models and form part of several composite rankings, including the one explained on the league page. Example: A model tackling a GPQA Diamond chemistry question must reason through several steps rather than recall a textbook fact to pick the right option.

LiveBench is a benchmark designed to resist contamination, the problem of test questions leaking into training data and inflating scores. It draws on recent sources such as newly released maths competitions, research papers, and news, and it refreshes its questions on a regular monthly cycle. Tasks span reasoning, coding, mathematics, data analysis, language, and instruction following, and many are scored automatically without a human or model judge. It matters because its design makes scores harder to game and more comparable over time. LiveBench carries the largest weight in this site's composite on the league page. Example: Because this month's LiveBench questions were published after a model's training cutoff, a strong score suggests genuine problem solving rather than memorised answers.

LMArena, formerly known as LMSYS Chatbot Arena, is a public platform where users chat with two anonymous models side by side and vote for the response they prefer. Millions of these blind votes are converted into Elo-style ratings that rank models by human preference in real conversation. It matters because it captures qualities benchmarks miss, such as tone, helpfulness, and formatting, though voters may favour confident or verbose answers and the sample reflects the platform's user base. Rankings are updated continuously as more votes arrive and new models enter the arena anonymously. LMArena results are reported alongside test-based scores on the benchmarks pages. Example: A visitor asks both hidden models to explain taxes simply, prefers the clearer answer, and only after voting learns which model wrote each response.

Prompt caching is a provider feature that stores a repeated prompt prefix, such as long instructions or a large document, so it does not need to be processed from scratch on every request. Follow-up requests that reuse the cached prefix are billed at a lower rate for those tokens and usually return faster. It matters because many real applications resend the same context constantly, so caching can cut costs and latency substantially. Cache entries typically expire after a short period of inactivity, and exact pricing and rules differ by provider. Cached input rates are reflected in the pricing data on the pricing page. Example: A support assistant resends a 20,000 token product manual with every question, and caching means only the short new question is processed at full price.

A rate limit is a cap a provider places on how much an account can use an API in a given period, usually expressed as requests per minute, tokens per minute, or both. Requests beyond the limit are rejected, typically with a 429 error, until the window resets or the account's tier is raised. Limits matter because they shape how applications must be designed, with queues, retries, and backoff, and they can bottleneck busy products even when the budget allows more use. Limits usually rise with spending tiers and differ between models. Planning around them starts with estimating usage in the API cost calculator. Example: An app that suddenly sends 500 requests in a minute receives 429 errors and retries them gradually instead of failing its users outright.

The League Score is this site's own composite rating that combines several public evaluations into a single number for comparing models. It weights LiveBench at 40 percent, SWE-bench Verified at 20 percent, GPQA Diamond at 15 percent, LMArena Elo at 15 percent, and MMLU-Pro at 10 percent. Each component is min-max normalised so different scales can be combined, and when a model lacks a component, its weight is redistributed among the components that are available. It matters because it balances test-based and human-preference signals instead of relying on any single benchmark. The resulting standings are published on the league page. Example: A model with strong LiveBench and coding scores but no LMArena rating still receives a League Score, calculated from its four available components.

An agentic workflow is a pattern where a language model does not just answer once, but works through a task in a loop: planning steps, using tools, checking results, and revising its approach. Reflection, planning, tool use, and collaboration between models are common building blocks. It matters because structuring work this way often produces better results than a single prompt, especially for research, coding, and document tasks, at the cost of more tokens and more time. Well designed workflows also add checkpoints where a human reviews consequential actions. Systems built this way are increasingly listed among the tools covered on the models page. Example: An assistant drafts a report, searches for sources, criticises its own draft for gaps, and rewrites it before presenting the final version.

A multi-agent system uses several model-powered agents, each with a role or specialisation, that communicate and divide a larger task among themselves. One agent might plan, another gather information, another write, and another review, passing results along a defined workflow. It matters because specialisation and mutual checking can improve quality on complex projects, and agents can work in parallel to save time. The costs are real: coordination overhead, duplicated work, and errors compounding between agents all need managing. Multi-agent designs build on the agentic patterns used by many systems catalogued on the models page. Example: A coding project is split between an agent that writes functions, one that writes tests, and one that reviews both before anything is merged.

The Model Context Protocol, or MCP, is an open standard that defines how AI applications connect to external tools, data sources, and services. Instead of each developer writing a custom integration for every tool, an MCP server exposes capabilities in a standard format that any compatible client can use. It matters because it lowers integration effort, makes tools reusable across applications, and has been adopted by a growing number of model providers and software products. As with any connection to external systems, permissions and data access need careful review. MCP support is one of the ecosystem developments tracked alongside the providers on the labs pages. Example: A coding assistant connects to the same MCP server for a company database that the support chatbot uses, with no custom code written twice.

Token pricing is how API providers charge for language models: a stated price per million input tokens processed and per million output tokens generated. Output tokens usually cost several times more than input tokens, and prices vary widely between flagship and smaller models. It matters because token pricing, combined with how much text an application sends and receives, determines the real running cost of any AI feature. Caching, batch discounts, and fine-tuned or smaller models can all change the effective rate. Providers publish rates per model, and the same model can cost differently across regions or service tiers. Current per-model rates are collected on the pricing page. Example: An app sending 2 million input tokens and generating 500,000 output tokens a month multiplies each volume by the model's two rates to forecast its bill.

A blended price combines a model's separate input and output token rates into one figure, using an assumed mix of input to output tokens. On this site the blend assumes a 3 to 1 ratio of input to output, which reflects many chat and document workloads where prompts are longer than replies. It matters because a single number makes quick cost comparisons between models practical, without calculating two rates for every candidate. It is only an approximation, however, and workloads with unusually long outputs will cost more than the blend suggests. Blended figures for each model are shown on the pricing page. Example: A model priced at 3 dollars per million input tokens and 15 dollars per million output tokens has a blended price of 6 dollars under the 3 to 1 mix.

Cached tokens are input tokens that a provider has processed before and stored, so they can be reused in a later request at a reduced price. They occur when a new prompt shares a long prefix with an earlier one, such as the same instructions, document, or conversation history. It matters because cached input is typically billed far below the standard input rate, which rewards applications that keep their prompts stable and well ordered. Cache lifetimes are short and rules differ between providers, so savings are never guaranteed. Cached rates are listed per model on the pricing page. Example: In a long chat session, the earlier conversation is resent with each message, and most of those repeated tokens are billed at the cached rate.

A diffusion model generates images, and increasingly video and audio, by starting from random noise and gradually removing it in many small steps until a coherent result forms. During training the model learns to reverse a process that progressively adds noise to real examples. It matters because diffusion became the dominant approach for high quality image generation, offering strong control through text prompts, reference images, and editing techniques such as inpainting. The trade-off is speed, since generation requires many sequential steps, though newer methods reduce the count. Diffusion systems feature throughout the film and image coverage on the movies page. Example: A designer types a description of a mountain cabin at dawn and watches the image resolve from static-like noise into a detailed scene.

Text-to-image is the capability to generate a picture from a written description, using models trained on large collections of images paired with captions. The user controls subject, style, composition, and lighting through the prompt, and can refine results by editing, extending, or varying an image. It matters because it makes illustration, concept art, mock-ups, and marketing visuals fast and inexpensive to produce, while raising questions about training data, likeness, and disclosure. Quality varies in areas such as hands, text rendering, and consistency across a series. Image generation is one of the creative uses explored in the movies section. Example: A shop owner with no design budget generates a banner image of her bakery's pastries in a warm watercolour style from a single sentence.

Text-to-speech, or TTS, converts written text into spoken audio using a model trained on recordings of human voices. Modern systems produce natural pacing, emphasis, and emotion, and some can clone a voice from a short sample with the speaker's permission. It matters because it powers accessibility tools, audiobooks, voice assistants, and video narration, turning text content into something people can listen to. Quality still varies with unusual names, numbers, and long passages, and cloned voices raise consent and misuse concerns. Most services charge by character or by minute of generated audio, and offer a range of voices and languages. Voice features are part of many multimodal systems listed on the models page. Example: A commuter converts a long newsletter into audio each morning and listens to it read aloud during the drive to work.

Speech recognition, also called automatic speech recognition or ASR, converts spoken audio into written text. Models are trained on large amounts of transcribed speech so they can handle different accents, background noise, and speaking speeds. It matters because transcription underpins subtitles, meeting notes, voice commands, dictation, and searchable audio archives. Accuracy drops with heavy noise, overlapping speakers, rare names, and low-resource languages, so transcripts for important records should be reviewed. Many systems also add punctuation, capitalisation, and speaker labels to make the resulting text easier to read and use. ASR is usually the first stage of any voice system, working alongside the models catalogued on the models page. Example: A recorded interview is uploaded after the event and returned as a timestamped transcript that the journalist can quote and search within minutes.

Voice AI refers to systems that let people interact with software by speaking and listening, combining speech recognition, a language model, and text-to-speech in one loop. The system transcribes what the user says, decides on a response, and speaks it back, ideally with low enough delay to feel like a conversation. It matters because voice is the natural interface for hands-free tasks, accessibility, customer support calls, and language practice. Latency, interruptions, and background noise remain the hard engineering problems, and errors can compound across the three stages. Voice capabilities are tracked among the features on the models page. Example: A driver asks aloud for the nearest petrol station, hears a spoken answer, and follows up with a question about opening hours, all without touching the phone.

A chatbot is software that converses with users in natural language, answering questions and completing tasks through a text or voice interface. Early chatbots followed scripts and keyword rules, while modern ones are powered by language models that handle open-ended requests and remember the conversation's context. It matters because chatbots are the most common way people meet AI, handling support questions, tutoring, brainstorming, and everyday information needs at any hour. Their limits include confident errors, so important answers should be verified, especially on medical, legal, and financial topics. Chatbots built on different underlying systems can be compared on the comparison pages. Example: A traveller messages an airline chatbot at midnight, rebooks a missed connection, and receives a new boarding pass without waiting for an agent.

An AI copilot is an assistant embedded inside a software product that helps the user complete that product's tasks, such as drafting in a word processor or writing code in an editor. Unlike a general chatbot, a copilot sees the current document, file, or data and suggests actions in context, while the user stays in control and approves the results. It matters because this arrangement raises productivity without handing over decisions, and it is now the standard design for AI in workplace software. Copilot quality depends heavily on how well it understands the host application's context. Examples across categories appear in the comparisons section. Example: While drafting a report, a user accepts a copilot's suggested summary paragraph, edits two sentences, and moves on in a fraction of the usual time.

A coding assistant is an AI tool that helps write, explain, debug, and review software, usually inside an editor or through a command line interface. It can autocomplete lines, generate functions from a description, propose fixes for errors, write tests, and explain unfamiliar code. It matters because these tools measurably speed up routine development work and lower the barrier for beginners, although generated code can contain subtle bugs and security flaws that need review. Teams often set rules for review, testing, and licensing before allowing generated code into production projects. The underlying models are evaluated on practical programming tests such as those on the benchmarks pages. Example: A developer describes a data-cleaning function in a comment, the assistant drafts it with tests, and the developer reviews and corrects the edge cases before committing.

An answer engine, sometimes called AI search, responds to a question with a direct, synthesised answer and citations, instead of a list of links to browse. It searches the web or a knowledge base, reads the most relevant sources, and summarises them in conversational form. It matters because it changes how people find information, saving time while raising questions about accuracy, source traffic, and how publishers are credited. Answers can still misread sources or cite pages that do not support a claim, so checking citations remains worthwhile. Answer engines are among the product categories compared in the comparison section. Example: A student asks when a treaty was signed and receives a two-sentence answer with linked sources, rather than opening ten search results to find the date.

Personalization in AI means adapting a system's responses to an individual user based on their preferences, history, location, or stated instructions. It ranges from simple settings, such as preferred language or tone, to systems that learn from past conversations and adjust recommendations over time. It matters because relevant, context-aware answers are more useful, but personalization also creates privacy questions about what is stored and how it is used, and it can narrow what a user is shown. Good products make personal data visible and deletable. These trade-offs are discussed across the provider profiles on the labs pages. Example: A learning app notices a student prefers worked examples over definitions and begins presenting new maths topics that way by default.

AI memory is the ability of an AI system to retain information beyond a single message, either within a conversation or, in some products, across separate sessions. Within a chat, memory is simply the context the model can see; longer-term memory stores selected facts, such as a user's name, projects, or preferences, and retrieves them later. It matters because memory makes assistants feel continuous and saves users repeating themselves, while creating responsibilities around accuracy, consent, and deletion of stored details. Users should assume anything remembered may resurface in later answers. Memory features differ widely between the systems on the comparison pages. Example: An assistant that was told last month about a user's peanut allergy flags a recipe containing peanuts without being reminded.

Long context describes a model's ability to accept and use a very large amount of input text in one request, measured by its context window in tokens. Early models handled a few thousand tokens, while current systems accept hundreds of thousands or more, equivalent to entire books or codebases. It matters because long context enables whole-document analysis, long conversations, and many-example prompts without splitting work into pieces. A large window does not guarantee the model uses information in the middle well, so retrieval quality should be tested rather than assumed. Context sizes for current systems are listed on the models page. Example: A lawyer pastes a 400-page contract into one prompt and asks for every clause mentioning termination, receiving answers drawn from the whole document.

A KV cache is a store of intermediate calculations, called keys and values, that a transformer model keeps while generating text so it does not recompute attention over earlier tokens for every new token. Each generated token adds its entries to the cache, which grows with the length of the conversation or document. It matters because the cache makes long generations fast enough to be practical, but it also consumes large amounts of memory and becomes a limiting factor for long context serving. Many speed and cost optimisations in production systems are really techniques for managing this cache. You can see the token volumes involved using the token counter. Example: During a long answer, the model reads the cached keys and values for the prompt instead of reprocessing thousands of earlier tokens for each new word.

Token streaming is the delivery of a model's output piece by piece as it is generated, rather than waiting for the complete response before showing anything. It is the reason chat interfaces display answers appearing word by word. It matters because streaming makes applications feel far more responsive, lets users start reading or cancel early, and allows other software to begin processing partial output. It does not make the model itself faster, and total generation time is unchanged, but perceived waiting time drops sharply. Streaming behaviour is standard across the chat systems compared on the comparison pages. Example: A user asks for a long explanation, begins reading the opening sentences immediately, and stops the generation once the needed section has appeared.

Structured output is the practice of making a model return its answer in a defined machine-readable format, such as JSON matching a specified schema, instead of free-form prose. Providers support this with constrained decoding or dedicated modes that force valid field names, types, and required values. It matters because software can then use model output directly, extracting entities, filling forms, or calling other functions without fragile text parsing. Schemas cannot guarantee the content is correct, only that its shape is valid, so validation and sanity checks still matter. Structured output features are noted for many systems on the models page. Example: An app asks a model to read an invoice and return JSON with vendor, date, and total fields, which flows straight into the accounting database.

A vision-language model, or VLM, is a model trained to understand images and text together, so it can answer questions about pictures, describe scenes, read charts and documents, and reason over visual information. Many current flagship language models are VLMs by default, accepting image inputs alongside written prompts. It matters because a large share of real information is visual, from receipts and diagrams to screenshots and photographs, and VLMs make that material searchable and analysable in conversation. They can still misread fine detail, counts, and small text, so critical visual checks deserve verification. Multimodal capabilities are listed per system on the models page. Example: A user photographs a handwritten recipe card and the model returns a typed ingredient list with quantities converted to metric units.

A frontier model is one of the most capable AI systems available at a given time, typically built by a leading lab with the largest training runs and the newest techniques. The term describes a moving target: capabilities that count as frontier one year become standard in cheaper models soon after. It matters because frontier models set the direction for the industry, appear first in safety and policy debates, and anchor the top of capability rankings. They are also usually the most expensive to use, so many applications run on smaller models instead. The current frontier field is ranked on the league page. Example: When a lab releases a new flagship that tops most benchmarks, reviewers describe it as the new frontier model until rivals catch up.

A foundation model is a large model trained on broad data that can be adapted to many different tasks, rather than being built for one specific job. Language models, vision-language models, and image generators all fit the description, since the same base system can be prompted or fine-tuned for writing, coding, analysis, support, and more. It matters because this reusability is the economic engine of modern AI: one expensive training run supports thousands of applications. It also concentrates influence, since weaknesses or biases in the foundation can appear across everything built on it. The major foundation systems are catalogued on the models page. Example: A single foundation model powers a company's support chatbot, its document summariser, and its internal search tool, each adapted with different prompts.

A small language model, or SLM, is a language model with relatively few parameters, often in the range of a few hundred million to several billion, designed for efficiency over maximum capability. SLMs are commonly produced by distillation or trained on carefully curated data, and many run directly on phones, laptops, or embedded hardware. It matters because they offer lower cost, faster responses, offline use, and better privacy for tasks that do not need frontier-level reasoning. Choosing between an SLM and a larger model is a routine cost and quality decision. Both ends of the size range appear on the models page. Example: A phone keyboard uses a small on-device model to suggest replies instantly, without sending the conversation to a server.

A model release is the event where a maker makes a new model, or a new version of one, available to users, through an API, an app, a download, or some combination of these. Releases are usually accompanied by documentation, benchmark results, pricing, and notes on safety testing and known limitations. It matters because releases reset competitive comparisons, change what applications can do, and often trigger price and feature responses from rivals. Details in launch claims deserve checking against independent evaluations after release. New releases from the major providers are tracked on the labs pages. Example: A lab announces a release on Monday, developers test it against their workloads during the week, and several apps switch to it by the following month.

A model sunset, also called deprecation, is when a maker retires a model and ends access to it, usually after announcing a shutdown date and a recommended replacement. Sunsets happen because older models are costly to maintain, are superseded by better versions, or rely on infrastructure being retired. It matters because applications built on a retiring model must migrate, retest behaviour, and sometimes absorb different pricing before the deadline, or they stop working. Responsible providers give months of notice and migration guidance. A recent case was AI21 retiring its Jamba API in August 2026, noted on the labs pages. Example: A startup receives a sunset notice, switches its app to the replacement model, and reruns its quality tests before the old endpoint is switched off.

A world model is an AI system that learns an internal representation of how an environment works, so it can predict how the environment will change in response to actions over time. World models are studied in robotics, games, and video generation, where predicting the next state of a scene is central to planning. It matters because genuine prediction supports planning, simulation, and training agents safely in virtual settings before they act in the real world. The term is used loosely in marketing, so claims should be judged by demonstrated prediction and planning ability. Research directions from the major providers are profiled on the labs pages. Example: A robot uses a world model to simulate several ways of stacking boxes and chooses the arrangement predicted to stay stable before moving at all.

Context engineering is the discipline of deciding what information a model sees at the moment it responds: instructions, retrieved documents, conversation history, tool results, and examples. It extends prompt engineering, which focuses on wording, to the whole design of the input a system assembles for each request. It matters because model quality depends heavily on receiving the right, well organised, and current information, and poor context is the most common cause of disappointing results in real applications. It also controls cost, since every included token is processed and billed. Watching token totals with the token counter is a basic context engineering habit. Example: A support system retrieves only the three most relevant help articles for each question instead of attaching its entire manual, improving both accuracy and cost.

Vibe coding is an informal term for building software mainly by describing what you want to an AI assistant, accepting its generated code, and iterating through conversation rather than writing most lines by hand. The phrase was popularised in 2025 and captures a real shift: people with little formal training can now produce working prototypes and personal tools quickly. It matters because it expands who can build software, while raising familiar risks around unreviewed code, security, and maintenance when nobody fully understands the result. Experienced developers use the same loop more critically, treating output as a draft. The assistants used for this workflow are compared on the comparison pages. Example: A teacher describes a quiz app in plain sentences, tests the AI-built version with her class the same afternoon, and requests fixes in follow-up messages.