When to use the native API

The OpenAI-compatible surface exists for one reason: you already have an OpenAI client. It maps /v1/chat/completions onto extract for structured output, and onto classify plus extract for function calling. The other five capabilities have no chat equivalent.

Move to the native endpoints when you need a probability, a character offset, a batch, or a capability the facade cannot reach.

What the OpenAI surface cannot return

The chat facade returns one assistant message. Structured extraction arrives as a JSON string you must parse. Function calling arrives as one tool call with a stringified arguments object. Neither carries a confidence number, so you cannot build the confidence routing that the native fields make trivial.

Migration table

Fewer calls per request

Tool selection over two or more tools runs classify first to pick the tool, then extract to fill its arguments. That is two inference calls. Calling classify or extract directly runs one.

Measured on 2026-09-16 against production:

Batching removes round trips. The chat facade takes one message set per request. Every native endpoint takes texts with up to 32 items. yes-no and answer also take up to 32 statements or questions.

Statements and questions cost almost nothing extra, because they go into one inference call. Each item in texts costs its own inference call. Batching covers the ordering rules.

Every capability response reports usage in the x-input-chars and x-input-tokens headers. x-input-chars is the number of input characters. x-input-tokens is the input tokens billed for this call. Cost scales with everything you send, text plus labels, questions, or schema, at $0.04 per million input tokens and $0 per output token. See Pricing.

The same job, both ways

A chat client extracting a reservation:

from openai import OpenAI
client = OpenAI(base_url="https://api.milliseconds.ai/v1", api_key="any-string")
completion = client.chat.completions.create(
    model="decision-machine-1",
    messages=[{"role": "user", "content": "Book Nobu for 4 on Friday."}],
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "reservation",
            "schema": {
                "type": "object",
                "properties": {
                    "restaurant": {"type": "string"},
                    "party_size": {"type": "integer"},
                    "day": {"type": "string"},
                },
            },
        },
    },
)
print(completion.choices[0].message.content)

That returns the JSON as a string:

{"restaurant":"Nobu","party_size":4,"day":"Friday"}

The native call returns the same result as an object, and accepts a batch:

curl -s https://api.milliseconds.ai/v1/decision-machine-1/extract \
  -H 'content-type: application/json' \
  -d '{
    "texts": ["Book Nobu for 4 on Friday.", "Table for 2 at Kura on Sunday."],
    "schema": {
      "type": "object",
      "properties": {
        "restaurant": {"type": "string"},
        "party_size": {"type": "integer"},
        "day": {"type": "string"}
      }
    }
  }'

{
  "results": [
    {"data": {"restaurant": "Nobu", "party_size": 4, "day": "Friday"}},
    {"data": {"restaurant": "Kura", "party_size": 2, "day": "Sunday"}}
  ]
}

Two texts, one request, one results array in input order. The chat surface needs two round trips for the same work.

Keep the OpenAI surface when

• An agent framework or SDK speaks OpenAI and you cannot change it.
• You route tools by description and one tool call per turn is enough.
• You want a drop-in swap behind an existing base_url, with no client changes.

The facade and the native endpoints run the same models. The facade adds a translation layer, not a different decision.

Migration checklist

Next

• Choosing a capability — the decision table, including the near-miss pairs.
• Decisions and probabilities — what each returned number means.
• Batching — how texts spreads across inference slots.