Schematron V2 Turbo: Cheap HTML-to-JSON Extraction at Volume

Most teams that scrape the web at scale start by pointing a general chat model at raw HTML and asking for JSON. It works, and then the invoice arrives. A product page is easily ten thousand tokens of markup, and a million pages a day turns a cheap per-token price into a large monthly number.

Schematron V2 Turbo is Inference.net's answer to that specific job. It does one thing: read messy HTML and emit JSON that matches a schema you supply. It is not a chat model, it does not take instructions, and that narrowness is the point.

A model with no prompt

The unusual part is the interface. According to Inference.net's documentation, the Schematron models take no system or user instructions at all. You send the raw HTML as the user message and put everything else in the JSON schema passed through response_format. Field names, types, required fields and field descriptions are the whole of your control surface.

That changes how you write an extraction job. If you want a price normalised to a number, or a list of tags rather than a comma-separated string, you say so in the schema description for that field, not in a paragraph of prose. Pydantic and Zod both let you attach descriptions to fields, and the docs recommend doing exactly that. Our guide to designing the schema before the prompt applies here with unusual force, because there is no prompt to fall back on.

The documentation also recommends temperature 0, and the vendor describes its strict JSON mode as producing schema-compliant output every time. Validate anyway. Schema-valid and correct are different properties.

Turbo versus Small: a sliver of quality for more throughput

Schematron V2 shipped as two models, announced on Inference.net's blog on 16 April 2026; OpenRouter lists Turbo from 12 September 2026. Catalogue listings describe Turbo as a 3B-parameter model. The vendor positions Schematron V2 Small as the quality option for complex schemas and long pages, and Turbo as the throughput and cost option.

The vendor's own numbers make the trade unusually explicit:

• Extraction quality, graded 1 to 5 by GPT-5.4 as a judge: Turbo 4.039, Small 4.060, the older open Schematron 8B 4.070, the older 3B 3.909.
• Throughput on a single H100 with 10K input and 500 output tokens: Turbo 4.14 requests per second, Small 2.47, the old 3B 2.47, the old 8B 1.63.
• SimpleQA, used as an extraction layer under a small search agent: Turbo 79.42, Small 83.10, old 3B 75.47, old 8B 85.58.

Read that carefully. On the judge score, Turbo gives up two hundredths of a point to Small for roughly two thirds more throughput. On the factuality test the gap widens to almost four points, which suggests Turbo misses more when the answer depends on finding one specific fact buried in a page. All of these are vendor-run, and the quality metric is an LLM judge, so treat them as directional.

The decision rule that falls out: Turbo for wide, shallow schemas over predictable pages (product listings, job posts, directory entries); Small when a schema has many nested fields or when missing a single value is expensive.

What a page actually costs

Turbo is listed on OpenRouter at $0.03 per million input tokens and $0.15 per million output at the time of writing. Inference.net's own launch post quoted $0.06 input and $0.15 output on its API. Prices move; check both before you budget.

Take the vendor's benchmark shape of 10K input tokens and 500 output tokens per page. At the OpenRouter list price that is $0.0003 of input and $0.000075 of output, so roughly $375 per million pages. At the $0.06 input rate it is roughly $675. Input dominates, which is why the next section matters more than the model choice.

OpenRouter lists a 128K context window and up to 8,192 output tokens. The output cap is rarely a constraint for extraction, but a schema that asks for every review on a long page can hit it, so check for truncated JSON in your validation step.

Preparing the HTML

The docs recommend pre-cleaning pages with lxml, removing scripts, styles and inline styles, because that matches how the training data was prepared. They also advise removing less rather than more: an aggressive readability pass can strip the table that held the specifications you wanted.

from lxml.html.clean import Cleaner

cleaner = Cleaner(scripts=True, javascript=True, style=True, inline_style=True)
clean_html = cleaner.clean_html(raw_html)

Cleaning is also your largest cost lever. Inline scripts and styles can make up a large share of a modern e-commerce page, and trimming to the main content region removes more. Measure your own pages before and after; the saving is the number that goes into your budget. For bulk work, Inference.net offers a Batch API that accepts up to 50,000 jobs in a 24-hour window.

Where it stops being the right tool

Turbo extracts; it does not reason across pages, summarise or judge. A field that needs synthesis, such as "is this listing a duplicate of one we already have", belongs in a separate step with a general model. The vendor notes that fields requiring summarisation need explicit schema descriptions, which is a polite way of saying the model will only do what the schema spells out.

The V2 weights are closed and served only through the API. If you need to self-host, the original Schematron 3B and 8B weights remain on Hugging Face. Note that Inference.net now routes API calls for inference-net/schematron-3b to V2 Turbo and bills them at V2 rates, so update your model identifier explicitly rather than inheriting a silent change. The same logic applies to V2 itself: re-run your labelled sample whenever the provider changes what an identifier serves.

Before you migrate a pipeline

1. Pull 200 pages from your real crawl, not a curated sample, including the ugly ones.
2. Hand-label the fields you care about on 50 of them.
3. Run Turbo and Small on the same cleaned HTML at temperature 0 and compare field by field, not page by page.
4. Count missing values separately from wrong values. A null is cheap to detect; a plausible wrong price is not.
5. Measure tokens per page before and after cleaning, and price the run at both list prices.

If Turbo matches Small on your labelled fields, the throughput gain is free. If it drops the fields your business depends on, the cheaper model is the expensive one.