Skip to content
InfratoApp
InfratoApp / Blog / a-model-page-an-assistant-can-quote-correctly

A model page an assistant can quote correctly

Assistants quote pages that state facts plainly: an answer first, exact names, dated figures and structured data. None of that guarantees a citation.

INFRATOAPP · PUBLISHED 23 OCTOBER 2026 · 5 MIN READ · 3 SOURCES · PRICES LAST CHECKED 2H AGO

What a quotable model page holds

A model page an assistant can quote correctly states its facts in sentences that are true when lifted out alone: what the model is, its exact identifier, its price per million input and output tokens, its context length in tokens, its license in a line, and the date each was last checked. Put them at the top as text, mark them up as structured data that matches the visible page, and keep them current. Nobody can promise any assistant will cite it, and this post does not.

What can be said is that a page which does not state a fact plainly cannot be quoted for it, and a page that states it wrongly will be quoted wrongly.

The difference between quoted and quoted correctly matters more to a maker than it looks. A wrong context length repeated in an answer reaches buyers who never visit your page, and they rule the model out on a figure you did not write.

Answer first, because the first paragraph travels

A passage lifted into an answer can arrive without the page around it. A first paragraph that begins with the company's mission, or a sentence about the frontier of intelligence, gives nothing to lift. One that says the model's name, what it is for, how much context it takes and what it costs gives a complete answer in a few lines.

Write that paragraph as if it will be read with nothing else. No pronouns pointing back to a heading, no it that needs the title to mean anything. The same discipline applies to every post on this site, because we expect our own paragraphs to travel the same way.

Headings help in the same way. A heading that says what the section holds, such as price per million tokens, tells a reader and a crawler where a fact lives. A heading such as built for scale says nothing about what follows.

Exact names, every time

Use the full model identifier the API accepts, not a nickname, and use it the same way every time it appears. An assistant asked about a specific version has to match that string, and a page that alternates between the marketing name, a short name and the identifier makes the match harder. The naming problem in how buyers find a new model starts on the maker's own page.

Name other things exactly as well. The precision of the weights, the hardware you tested on, the license by its full title. Vague nouns such as the latest GPUs or a permissive license are unquotable because nobody can check them.

Units belong beside every figure. Context in tokens, price per million tokens with input and output on separate lines, memory in gigabytes. A figure with its unit can be quoted without the surrounding table, and a bare number cannot.

Dates make a figure safe to repeat

A price or a limit without a date is a figure nobody can trust a month later, and a careful reader, human or not, has to guess whether it still holds. Put a last-checked date beside each block of facts, in a full date format, as text. Change it only when you have actually checked.

This is the rule this directory runs on. Every price and fact here carries the page it was read from and the date, and a price older than 21 days is hidden rather than shown stale. How that works is published, along with what we refuse to show. The token price table works the same way, from each seller's dated page.

An old figure can do more harm than a missing one. A page that still carries last quarter's price, undated, can be quoted at last quarter's price, and the buyer who acts on it has no date to warn them.

Structured data that says only what the page says

Markup in a schema such as Product with an Offer can carry the price, its currency and unit, and the date it is valid from, in a form a machine reads without parsing prose. The rule that matters is that markup must state only what the visible page states. Google's published guidelines for structured data say markup should describe content readers can see on the page, and markup claiming a price the page does not show breaks that rule.

Keep the markup generated from the same source as the visible text, so the two cannot drift. A buyer reading the page and a crawler reading the markup should get the same figure on the same date.

Do not put facts only in markup. A fact in structured data that is missing from the visible page cannot be checked by a reader, and a reader has no reason to trust what they cannot check. Markup is a second copy of the page, not a place for facts the page leaves out.

What this cannot promise

No outside party knows how any assistant weighs sources, and claims to the contrary are guesses. A clear, dated, consistently named page is more likely to be quoted correctly than a vague one. That is reasoning from how quoting works, not a measurement, and it is all this post claims.

Check the result the plain way. Ask an assistant about your model by name and compare its answer with your page. Where it is wrong, see whether your page states that fact clearly. Where the page is clear and the answer is still wrong, the error sits upstream of anything a page can fix.

The directory holds 1,116 live products, 144 of them in the models layer, each with sourced facts a buyer can check. A maker that wants its own wording there can claim its listing for free and answer its category's questions with a source.

What we could not answer

  • ⚑We cannot measure whether any assistant cites a given page, so nothing here is evidence that these changes increase citations.
  • ⚑How structured data is used varies by search engine and changes over time, and this post does not track it.
infratoapp, “A model page an assistant can quote correctly”, read 27 October 2026. live products in the directory: 1,116. https://www.infratoapp.com/blog/a-model-page-an-assistant-can-quote-correctly

Questions people ask about this

How do I get my model cited by AI assistants?

Nobody outside the labs can promise that. What helps is a page that states facts plainly at the top, uses the exact model identifier every time, dates each figure, and carries structured data matching the visible text. A page that does not state a fact cannot be quoted for it.

Should a model page use structured data?

It can, if the markup states only what the visible page states. A Product with an Offer can carry a price, currency, unit and the date it is valid from. Generate the markup from the same source as the text so the two never disagree.

Why should a model page date its facts?

Prices, limits and versions change, and a figure without a date cannot be trusted a month later. A last-checked date beside each block of facts tells a reader, and any system quoting the page, whether the figure is likely to still hold.

These render as FAQPage structured data · answers are filled from the same live figures

Read next

Name your models so every seller spells them alike

When sellers spell one model several ways, price tables split it into separate rows. Publish one canonical name and a grammar for its variants, and keep both.

Open weights: list where the model can be served

Published weights mean many sellers. The page buyers want is a dated list of hosts, the build each one serves, and the limits each one enforces on the model.

Release notes that say what changed and what to retest

A model update can change behaviour, the prompt format, the tokenizer or the price. Release notes should list each change and the test a buyer must run again.