Large Language Model (LLM) Capabilities Markdown Table Template
An LLM comparison table is a procurement document disguised as a cheat sheet. It turns up in AI architecture docs, cost-estimation wikis and vendor evaluations, and the people reading it are deciding which model handles which workload, whether a long document fits in a single request, and what next quarter’s API bill will look like. Every one of those decisions depends on numbers that providers revise without notice, which shapes how the table has to be built.
Edit This Template
Edit cells, add rows, or sort — the Markdown updates livePaste cells from Excel or Google Sheets into the first header to replace the table · Tab / Enter / arrows move · Shift+F10 opens row & column actions
When to Use This Table
The defining property of a trustworthy version is that each figure carries a date and a source. Model line-ups, list prices and context limits move every few months, and a table copied from a blog post written last year will quietly mislead anyone who budgets from it. Put an “as of” date above the table, link each provider’s pricing page, and identify models by their pinned API identifiers rather than marketing names, because aliases such as “latest” are repointed to newer snapshots over time.
The second property is honesty about what the quality column measures. Vendor-reported scores come from different prompts, sampling settings and harnesses, so a capability column is a starting hint, not a ranking. The table becomes genuinely useful once it also carries a cost-per-request estimate for your own traffic and a pass rate on your own evaluation prompts.
Formatting This Table in Markdown
A large language model (llm) capabilities table puts a few things in cells that Markdown treats as syntax. These are the ones to watch so it renders correctly on GitHub, GitLab, Obsidian and docs sites.
Two dollar signs in a cell may pair as math
On GitHub
$…$is math, so a cell such as$3.00 - $15.00may be read as a formula between the dollar signs. Escape each sign as\$, or put the currency in the header (Input (USD / 1M)) and keep cells numeric; math cannot span cells, so a single price per cell has nothing to pair with.Split modalities into columns or line breaks
A string like “In: text, image, audio / Out: text” is hard to scan. Use one ✅ or — column per modality, or short lines separated by
<br>; avoid[x], which does not render as a checkbox in GitHub cells (see checkmarks).Equal decimals and one unit style per column
Pad prices to the same decimals (
$0.20,$15.00) so right-aligned digits line up, and write context windows in one unit: all400,000or all400k, never a mix. Keep the Checked column in ISO form (YYYY-MM-DD) so rows compare correctly as text.Keep pricing URLs out of cells with reference links
Write
[pricing][a]in the cell and define[a]: https://…under the table, so inline URLs do not bloat every row. Reference links resolve in GFM renderers, though not every editor or chat tool resolves them.
What Goes in Each Column
| Column | Alignment | What to put here |
|---|---|---|
| Foundation Model | left :--- | The exact API model identifier in backticks, with the provider and display name beside it. Pin a dated snapshot where the provider offers one. For open-weight models, name the host or inference provider, because price, limits and even quantisation depend on who serves the weights. |
| Context Window | right ---: | Maximum tokens per request as the provider documents it, right-aligned with thousands separators so magnitudes line up. Write the exact integer rather than “128k”, which some readers take as 128,000 and others as 131,072. Note separately if the maximum output length is lower. |
| Input ($ / 1M) | right ---: | List price in USD per million input (prompt) tokens, right-aligned with two decimals. Use the standard on-demand tier here and footnote the rest: discounted cached-input rates, batch-processing discounts, and higher rates some providers charge once a prompt passes a length threshold. |
| Output ($ / 1M) | right ---: | List price per million generated tokens, usually several times the input rate, so it often dominates the bill for chatty or long-form workloads. If a model emits reasoning tokens, check the provider’s docs for how they are billed; they commonly count as output even when hidden. |
| Multimodal | center :---: | Which modalities the API accepts and returns, centered: “In: text, image, PDF / Out: text” is far more useful than a bare check mark. A consumer app supporting voice does not mean the API endpoint you will call accepts audio, so verify against the API reference. |
| Coding Benchmark (HumanEval) | right ---: | Pass@1 percentage on HumanEval’s 164 Python problems, right-aligned with one decimal, plus a footnote saying who measured it and when. Recent models cluster close to the ceiling, so consider swapping in a harder or private coding evaluation and naming it in the header. |
| Checked | center :---: | The date you copied this row’s prices and limits from the provider’s pricing and model pages, in ISO format (2026-10-01), centered. The template’s YYYY-MM-DD cells are placeholders; re-check any row older than your budget cycle before anyone cites it. |
How to Fill It In
- 1Filter on hard requirements before comparing prices: data residency, required modalities, minimum context length, whether you need open weights, and your organisation’s approved-vendor list. Models that fail a requirement do not belong in the table at all.
- 2Collect every figure on the same day from primary sources: the provider’s pricing page for rates and its model documentation for context and modality limits. Record that date above the table and put the URL in a Source column or footnote. Convert any per-1K price to per-1M by multiplying by 1,000.
- 3Estimate cost per request from your traffic:
input_tokens × input_price / 1,000,000 + output_tokens × output_price / 1,000,000. Tokenisers differ between providers, so measure token counts by sending a sample of real prompts and reading the usage figures each API returns, instead of assuming a fixed characters-per-token ratio. - 4Run a fixed evaluation set of 50–200 prompts drawn from real usage through each candidate with identical settings, grade the outputs, and add the pass rate as a column. This number outranks any vendor benchmark for your decision.
- 5Add a review date. Before anyone cites the table in a budget or design review, re-check the pricing pages and the provider’s deprecation notices, and sort by the column that matters with the Markdown table sorter.
Ready-to-Paste Variations
Dated pricing table with sources
The shape to publish internally. Model names and figures below are illustrative placeholders; replace every cell from the provider pages on the date you check them.
| Model ID | Provider | Context (tokens) | Input $/1M | Cached input $/1M | Output $/1M | Checked | Source |
| :--- | :--- | ---: | ---: | ---: | ---: | :---: | :--- |
| `vendor-a-large-2026-05` | Vendor A | 400,000 | 2.00 | 0.50 | 8.00 | 2026-10-01 | [pricing](https://example.com/a/pricing) |
| `vendor-b-small` | Vendor B | 200,000 | 0.15 | — | 0.60 | 2026-10-01 | [pricing](https://example.com/b/pricing) |
| `open-model-70b` (Host C) | Host C | 128,000 | 0.60 | — | 0.80 | 2026-10-01 | [pricing](https://example.com/c/pricing) |Workload cost estimate
Converts list prices into money for one workload. Token counts are measured per model because tokenisers differ; prices are illustrative and the arithmetic is shown so reviewers can check it.
| Model | Input $/1M | Output $/1M | Avg input tokens | Avg output tokens | Cost / request | Cost / 1M requests |
| :--- | ---: | ---: | ---: | ---: | ---: | ---: |
| Model A | 2.00 | 8.00 | 3,000 | 500 | $0.0100 | $10,000 |
| Model B | 0.15 | 0.60 | 3,300 | 520 | $0.000807 | $807 |
| Model C | 10.00 | 40.00 | 2,900 | 480 | $0.0482 | $48,200 |In-house evaluation results
The column vendors cannot give you: pass rate on your own graded prompts, with latency measured from your region. Example figures only.
| Model | Pass rate (n = 150) | Median latency (s) | p95 latency (s) | Notes |
| :--- | ---: | ---: | ---: | :--- |
| Model A | 132 / 150 (88.0%) | 2.1 | 5.8 | Best on multi-step extraction |
| Model B | 111 / 150 (74.0%) | 0.7 | 1.6 | Fails long tables; fine for routing |
| Model C | 138 / 150 (92.0%) | 6.4 | 14.9 | Reserve for hard cases |Common Mistakes
Publishing prices and context limits with no date or source, so a figure that was right at launch is still being quoted a year later.
Put “Prices checked YYYY-MM-DD” above the table, link each pricing page, and assign someone to re-verify before every budget cycle.
Ranking models on input price alone, or on a single blended “price” whose input/output weighting nobody wrote down.
Keep both columns and add a cost-per-request column computed from your measured input and output token counts.
Treating a token as the same unit across providers, then comparing context windows and per-token prices directly.
Tokenise a representative sample with each provider and compare cost per request or per document, which is the unit you actually pay for.
Copying vendor HumanEval scores from launch announcements and reading small gaps as a ranking.
Footnote who ran each benchmark and with what settings, treat differences of a few points as noise, and rely on your own evaluation set for the decision.
Listing a moving alias such as a “latest” model name, so the table silently describes a different model next month.
Use the pinned snapshot identifier the API accepts, and record deprecation dates so readers know when a row will stop working.
Related Markdown Table Templates
Browse all 50 templatesMachine Learning Model Benchmark Matrix
Compare machine learning and deep learning models across accuracy, precision, recall, F1 score, model parameter count, and inference latency.
SaaS Tiered Pricing Matrix
Tiered pricing table featuring monthly subscription costs, included user seats, bandwidth quotas, and key tier differentiators.
API Latency Percentiles (p50 to p99.9)
Measure service response latency distributions across p50, p90, p95, p99, and p99.9 percentiles alongside error rates.
Large Language Model (LLM) Capabilities: Frequently Asked Questions
Why are output tokens priced higher than input tokens?
Input tokens are processed together in a parallel pass over the prompt, while output tokens are generated one at a time, each needing its own forward pass. Providers price that extra compute into the output rate, which is why long responses cost far more than long prompts.
If a model has a huge context window, should I send everything?
No. You pay for every input token on every call, latency grows with prompt length, and answer quality can drop when the relevant passage is buried in a very long context. Some providers also charge a higher rate above a prompt-size threshold. Retrieve what is relevant instead.
How should I list open-weight models that I host myself?
There is no list price, so derive one: divide your hourly GPU cost by the millions of tokens per hour you sustain at realistic batch sizes. Footnote the hardware, quantisation and utilisation assumed, since each changes the result substantially.
Is HumanEval still a useful coding benchmark?
It is short Python function completion, and leading models score close to the maximum, so it no longer separates them well and may be affected by training-data contamination. Keep it only for continuity with older tables and add a harder or private evaluation.