What infratoapp reads from your pricing page, and how often

Your page is the source, read on a schedule

infratoapp gets a vendor’s prices by reading the vendor’s own pricing or documentation page with a crawler, extracting each value together with the sentence around it, and stamping it with the URL and the date it was read. Prices are read again on a schedule, on their own cadence. A price older than 21 days is hidden rather than shown stale.

Today that process holds 464 current GPU rate observations from 48 providers, and 750 input-price listings for models. None of them was typed in by us from memory or supplied over email. Each can be traced to a page somebody can open.

None of this depends on a claim. We read unclaimed vendors’ pages exactly as we read claimed ones. Claiming adds the ability to correct a value and to request a different source page, not a different way of reading.

What gets stored with each rate

Four things travel together: the value, the sentence it came from, the URL of the page, and the read date. A reader who hovers over a figure on the site sees all of them. That is deliberate, because a price that cannot be checked is a price nobody should quote, and the method page says so in more words.

The sentence is the part vendors forget about. If your page shows a rate inside an image, behind a toggle that loads after the page, or in a calculator that only answers when someone types, there may be no sentence to extract. In that case the field shows no answer on record. A missing value on this site means we did not find one, never that you do not offer the thing.

Values that come from you through the vendor portal are stored differently. They are labelled as supplied by the vendor, never ranked differently from crawled values, and checked again against your public pages.

The 21 day rule, from your side

When a rate passes its window it disappears from public tables until the next good read. For a vendor this has one practical effect: if the crawler cannot read your page for a few cycles, your row drops out of the comparison while competitors whose pages are readable stay in it.

The reason for hiding instead of flagging is on the method page: a stale price shown as current is the one error the site treats as unaffordable. A caveat in small type does not stop a buyer copying the number into a spreadsheet.

So a pricing page that moves, renames its anchors every quarter, or starts returning an error to automated readers costs you visibility here before anyone notices. Check that the page still loads without a login, and that the rates are in the HTML.

When you change prices

Between a change on your page and the next read, the old figure is what we hold, and the old figure is what a buyer sees here, with its old date beside it. The date is the warning. A buyer who sees a read date from last week knows the figure is last week’s.

If the new page has a new address, that is a change to where we read facts from, which a claimed vendor requests and we review within two working days. Do not expect the crawler to find a new URL on its own.

If we read the page and got the value wrong, the route is a dispute with the page attached. The value stays visible with a flag while it is re-read; an upheld dispute is published as a correction, and one that fails is closed with the supporting quote attached.

Writing a page that reads cleanly

Put each rate in text, next to the exact name of the thing it prices, in one unit. For GPUs that means the card with its form factor and memory, and a price per GPU per hour. For models it means the model name and version with input and output prices per million tokens on the same row.

Keep a visible date on the page. Our read date says when we looked; your date says when you last changed anything, and together they tell a buyer whether a gap between our figure and yours is a lag or an error.

Name the commitment beside every rate. An on-demand rate and a reserved rate in one column will be read as one product, and the cheaper of the two will be compared with everyone else’s on-demand price, which is unfair to them and, once a buyer notices, to you.

If the same card sells at different rates in different regions, say which region each rate belongs to. A headline rate with regional rates further down will be read as the only rate, and a buyer who finds the regional price later has two figures for one card.

Model prices follow the same path

Token prices are read the same way, from the provider’s own page, with input and output rates per million tokens. We currently hold 750 input-price listings from 16 providers. The count of listings that state a cached input price is 507.

The weak points are the same too. A rate that appears only inside a calculator, or a table that loads after a sign-in, leaves no sentence to quote. A page that puts input and output prices on separate tabs makes the pair harder to read together, so keep both on one row, beside the model’s exact name and version.

Whatever you sell, the read date on our side and the change date on yours are what let a buyer judge a figure. A page that states neither the unit nor the date leaves us to guess, and the rule here is not to guess: the field stays empty.