AI tool marketing runs on words that sound technical and are rarely defined. These are the ones that change a buying decision, and each links to where we work the comparison through.
The capability words that appear on every landing page, defined by what they actually constrain.
The units a language model reads and writes in, roughly fragments of words. Tokens are what you are billed on and what every limit is expressed in, which is why a price per token means nothing until you know how many tokens your actual work consumes.
Where we cover itThe instruction given to a model. Most of the difference between good and bad output comes from being specific about the things the model cannot infer, rather than from any particular phrasing, and the gain is in iteration rather than in a formula.
Where we cover itHow much material a model can hold in view at once, measured in tokens. It is the hard ceiling on what a tool can reason over in a single pass, and it is the specification that most often decides whether a tool fits a real workflow.
Where we cover itA standardised test used to compare models. Benchmarks are useful for ranking and weak for predicting your results, because your task is almost never the benchmark task and models are increasingly tuned against the published ones.
Where we cover itThe commercial terms, which differ far more between vendors than the capabilities do.
A metered unit of usage, sold in bundles. Credits are not comparable between vendors: one can mean a second of video on one platform and a whole image on another, so a price per credit tells you nothing until you know what one credit buys.
Where we cover itA cap on how much you may use in a period, separate from what you have paid for. It is the specification most often discovered in production rather than during evaluation, because it only bites at volume.
Where we cover itA per-person licence. Seat-based pricing decouples cost from usage, which favours heavy individual users and penalises teams where many people need occasional access, and that asymmetry is usually the whole comparison.
Where we cover itThe failure modes and safeguards worth understanding before you rely on output.
Output that is fluent, confidently stated and wrong. It is a property of how these systems generate text rather than a bug to be patched, which is why verification workflow matters more than model choice for anything consequential.
Where we cover itFurther training of an existing model on your own examples to shift its behaviour. It changes style and format reliably and is a poor way to add facts, which is the most common reason people are disappointed by it.
Where we cover itSupplying a model with relevant documents at question time instead of training them in. It is the standard approach for grounding answers in your own material, and the quality of the retrieval usually matters more than the model.
Where we cover itPairs that get used interchangeably on a pricing page and are not interchangeable. Each one changes what you are buying.
Both are ways to make a model work with your material and they solve different problems. Fine-tuning changes HOW the model responds, reliably shifting style and format. Retrieval changes WHAT it has in front of it. Using fine-tuning to add facts is the most common and most expensive mistake in this area.
Where this bitesTokens are a real technical unit and are comparable between vendors that bill in them. Credits are an invented commercial unit and are not comparable at all: the same word means different quantities on different platforms, which is precisely why some vendors bill in them.
Where this bitesContext is how much a model can consider in ONE request. A rate limit is how many requests you may make over a period. A large context with a tight rate limit and a small context with a generous one fail in completely different ways, and only one of them shows up in evaluation.
Where this bitesA benchmark score is a ranking on a standardised test. Hallucination is confident wrongness on YOUR task. A model can top a leaderboard and still fabricate on your material, because the benchmark measured something else, and increasingly models are tuned against the published ones.
Where this bitesSeat pricing charges per person regardless of use; credit pricing charges per unit of work regardless of who does it. Teams with many light users are punished by seats, and small teams doing heavy work are punished by credits. Modelling your real usage decides it, and the list price never does.
Where this bitesModel capabilities, pricing and limits in this field change month to month. These describe how the terms are generally used; the vendor current documentation governs, and is worth checking before you commit to a tool.