Verified inference, explained.

Repeatable production workloads

Pareta is infrastructure for AI tasks embedded in products and automated workflows — not a destination chatbot or general coding copilot. It is best for tasks with a stable objective, a defined output contract, and a measurable quality bar — classification, structured extraction, domain coding, embeddings, and reranking: many tickets to classify or invoices to extract, each different, scored the same way against the same contract. The workloads it is built for share four characteristics; if yours has them, auto is designed for it.

There is no minimum volume. An evaluation set is 5–50 items, and the same path that wins your evaluation serves your production traffic.

What verified inference means

Verified inference is a serving path in which every specialist result is checked against the workload’s quality bar before it is returned, and a frontier model produces the response whenever the specialist path cannot meet that bar. It combines three things a plain model API does not provide: a specialist matched to the workload, a check on what the specialist produced, and automatic escalation when the check is not cleared or no specialist holds the bar.

The quality bar belongs to the workload, not to the request. Each Pareta specialist carries a measured quality ratio against the strongest frontier baseline on its task’s benchmark, and you define your own bar for your own workload by evaluating auto on your data. Nothing is configured per request: your application sends an ordinary chat completion with the model ID auto and receives an ordinary response.

The gate raises the floor of what a specialist may return and decides when a frontier model must take over. It does not make any single answer correct by construction, and it is not re-run on frontier-served responses (see 05).

The specialist fleet and workload matching

Behind auto is a fleet of open-weight specialists hosted on Pareta’s serving infrastructure, several of them distilled in-house for a single task. Each specialist is deployed for one kind of work and carries a measured quality ratio against the strongest frontier baseline on that task’s benchmark. Specialist identities are not part of the API: GET /v1/models returns exactly one entry, auto, and the response echoes auto as the model.

Published benchmarks

Matched or beat the strongest frontier baseline on all five published benchmarks, with 30–140× lower serving cost. Quality is the specialist’s score relative to the strongest frontier model on the task (= 100%); the metric is named per row.

Path tested: stated per row on the benchmarks page — benchmark harness, direct endpoint, or the product path through auto; none of the figures include route-mix or escalation statistics. The frontier models were run on the same items; frontier cost = their actual usage tokens × vendor list price, Pareta cost = actual metered billing. The chart is on the homepage; the retrieval models have their own page, as does ICD-10 coding.

The workload quality bar and the verification pipeline

The quality bar is task-level. Each specialist carries a measured quality ratio against the strongest frontier baseline on the task’s benchmark, and that measurement decides how much checking a specialist result receives before it is returned. The bar is not configurable at request time; you define your own bar for your workload through evaluation on your data (10).

• What passes. A specialist result that clears the checks configured for its task is returned as the response.
• What does not. A specialist result that does not clear verification is not returned; the request escalates to a frontier model before the response is produced (05).
• Frontier-served responses. A response produced by a frontier model is returned as served; the quality gate is not re-run on it. Conformance to your response_format is still enforced however the request was served, and if no conformant answer can be produced the request fails with an explicit error.

Verification is a quality gate, not a guarantee that an AI output can never be wrong. Schema instructions written only in the prompt are not enforced by specialists; response_format with a json_schema is the supported contract (09).

Automatic frontier escalation

Frontier models step in only when needed to maintain the quality bar. There are two cases, and both happen inside one request, before the response is returned; your application sees a single completion.

• Frontier-served responses are returned as served. The quality gate is not re-run on a frontier model’s output. response_format conformance is still enforced.
• Escalation is visible. X-Pareta-Served-By reports specialist or frontier, X-Pareta-Escalated is true when a specialist attempt was followed by a frontier answer, and X-Pareta-Route-Version stamps the serving revision — compare it first when output formatting changes between identical requests. The receipt headers (08) tell you what was billed.
• Unsupported input is declined. A request whose input or modality nothing deployed can serve returns an explicit error rather than a silent empty answer.

How this differs from a router or marketplace

Traditional routers select among third-party model providers. Pareta operates its own specialist fleet for recurring production tasks, checks each specialist result against the workload’s quality bar, and uses frontier models when needed to maintain that bar.

Billing behavior

You are billed only for the model that produces the final response. Routing, verification, retries, and non-serving attempts are included. Each completed request is billed once, at the rate of whichever path produced the response.

• One debit per request. However many internal calls Pareta makes to serve a request — matching, a specialist attempt, model-graded checks, an escalation — the ledger records one debit, for the model that produced the final response.
• Errors are not billed. A request that fails with an explicit error bills nothing. An empty balance returns HTTP 402 and the request is not served.
• Direct endpoints. /v1/embeddings and /v1/rerank are metered per input token and per document scored respectively; rates are on the retrieval page and the pricing page.

New accounts start with $30 in credit; no card is required. Worked examples of all three paths are on the pricing page.

Response receipts

Every completion carries its own receipt in response headers, as micro-dollar integers (1,000,000 = $1.00). Two numbers are reported, and they are not the same kind of number.

curl -si https://api.pareta.ai/v1/chat/completions \
  -H "Authorization: Bearer $PARETA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "auto", "messages": [{"role": "user", "content": "..."}]}' \
  | grep -i x-pareta

x-pareta-billed: 653
x-pareta-frontier-would-have-cost: 11795

Example values in micro-dollars, as shown in the API documentation. x-pareta-billed is exact; x-pareta-frontier-would-have-cost is estimated. Streamed responses carry the same two numbers as SSE comment lines just before data: [DONE]; comments are invisible to OpenAI SDK parsers, so stock clients are unaffected. Serving-path diagnostics ride on every auto response (tool-calling turns carry the receipt headers only): X-Pareta-Served-By (specialist | frontier; none on a $0 clarification), X-Pareta-Specialist (the workload capability, never a model id), X-Pareta-Escalated, X-Pareta-Route-Version, and X-Pareta-Input-Required on clarification responses; streams carry the same as SSE comment lines.

API compatibility

Use your Pareta API key, point the OpenAI client at Pareta’s base URL, and set the model ID to auto. The features below are supported in production; anything not listed is ignored or rejected as described in the compatibility section of the docs.

import json
from openai import OpenAI

client = OpenAI(api_key=PARETA_API_KEY, base_url="https://api.pareta.ai/v1")

resp = client.chat.completions.create(
    model="auto",
    messages=[{"role": "user", "content": f"Classify this support ticket: {ticket}"}],
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "intent",
            "schema": {
                "type": "object",
                "properties": {
                    "label": {"type": "string", "enum": ["refund", "billing", "other"]}
                },
                "required": ["label"],
                "additionalProperties": False,
            },
        },
    },
)
label = json.loads(resp.choices[0].message.content)["label"]

With response_format set, a streamed response delivers the JSON as a single validated chunk rather than token by token. Full parameter-by-parameter behavior, including what returns a 400, is in the inference guide.

Evaluation on representative production data

The published benchmarks state the path tested per row. Your own evaluation is the end-to-end one: it runs auto — the same matching, verification, and escalation that serves production traffic — and the frontier models you name on the same items, under the same grading contract, and reports per contender the quality with a confidence interval and the measured cost.

• There is no deploy step. The path that served your evaluation is the path that serves the model ID auto in production.
• Evaluation runs are metered. The run is billed for the compute across auto and the frontier baselines you include; an empty balance is refused with a 402 before the run starts.
• Data that fits no built-in scorer can be graded by a judge panel against what you asked for; Pareta proposes this rather than assuming it.

Data flow and subprocessors

Pareta-hosted specialists run on Pareta’s serving infrastructure. A request reaches a third-party provider only when it is served by a frontier model, when model-graded verification runs, or when quality grading in an evaluation uses a frontier judge. Inputs and outputs are not used to train models.

Read Security & data → · Privacy Policy

Benchmark the production workload you already run

Use the OpenAI client already in your application, set the model ID to auto, and compare Pareta with your current frontier model on representative traffic before switching production.