Inference on Pioneer: native, OpenAI, and Anthropic APIs

Once you have a trained model — or want to use a base model directly — you run inference by sending a request to the Pioneer API. The model_id field accepts either a base model ID (like fastino/gliner2-base-v1) or the job ID (a UUID) returned from a completed training job (like 3fa85f64-5717-4562-b3fc-2c963f66afa6). Pioneer routes the request to the right deployment automatically. Pioneer supports three request formats: its own native format, an OpenAI-compatible format, and an Anthropic-compatible format. All three reach the same underlying models, and all three accept your API key the same way: either an X-API-Key header or an Authorization: Bearer <key> header — whichever your SDK sends by default works, no per-format configuration needed.

The chat-shaped endpoints (/v1/chat/completions, /v1/responses, /v1/messages) reject requests for a pretrained (non-instruct) base decoder model with a 400 — use the model’s -Instruct variant, or call /v1/completions with a raw prompt instead.

Pioneer native format

Use POST /inference with the Pioneer schema format. This is the most expressive option and gives you full control over extraction tasks.

curl -X POST https://api.pioneer.ai/inference \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "text": "Apple announced the MacBook Pro at WWDC in Cupertino.",
    "schema": {
      "entities": ["organization", "product", "event", "location"]
    },
    "threshold": 0.5
  }'

Schema structure

The schema field is a dictionary with optional keys. Include only the keys that apply to your task.

Key	Type	Description
`entities`	`string[]`	Entity type labels for named entity recognition (NER).
`classifications`	`object[]`	Classification tasks, each with a `task` name and `labels` list.
`structures`	`object`	Named structure definitions for JSON extraction.
`relations`	`object[]`	Relation definitions linking extracted entities.

Decoder models

For decoder models (LLMs), replace schema with "task": "generate":

curl -X POST https://api.pioneer.ai/inference \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model_id": "nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-BF16",
    "task": "generate",
    "messages": [                                                                                                     
        {"role": "user", "content": "Summarize the following article in two sentences."}
      ]
  }'

OpenAI-compatible format

Pioneer exposes an OpenAI-compatible endpoint at https://api.pioneer.ai/v1. Point any existing OpenAI SDK or integration at this base URL and use your Pioneer API key — no other changes required.

curl -X POST https://api.pioneer.ai/v1/chat/completions \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "messages": [
      {"role": "user", "content": "Extract entities from: Apple launched the iPhone."}
    ],
    "schema": {"entities": ["organization", "product"]}
  }'

Available OpenAI-compatible endpoints:

Method	Endpoint	Description
`POST`	`/v1/chat/completions`	Chat completions
`POST`	`/v1/completions`	Text completions
`POST`	`/v1/responses`	Responses API
`POST`	`/v1/embeddings`	Create embeddings
`GET`	`/v1/models`	List available models (callable without auth for the public catalog)
`GET`	`/v1/models/:model_id`	Retrieve a single model’s metadata

/v1/models and /v1/models/:model_id are shared infrastructure — the same two routes also serve the Anthropic-compatible SDK’s models.retrieve(...) calls.

When using the OpenAI Python or Node SDK, pass Pioneer-specific fields like schema via the extra_body parameter. For example:

client.chat.completions.create(
    model="3fa85f64-5717-4562-b3fc-2c963f66afa6",
    messages=[{"role": "user", "content": "Extract entities from: Apple launched the iPhone."}],
    extra_body={"schema": {"entities": ["organization", "product"]}}
)

Anthropic-compatible format

Pioneer also exposes an Anthropic-compatible endpoint. Set your SDK’s base_url to https://api.pioneer.ai/v1 and use your Pioneer API key in place of an Anthropic key — the Anthropic SDK sends it as x-api-key, which Pioneer accepts the same as the other two formats.

curl -X POST https://api.pioneer.ai/v1/messages \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "max_tokens": 1024,
    "messages": [
      {"role": "user", "content": "Extract entities from: Apple launched the iPhone."}
    ],
    "schema": {"entities": ["organization", "product"]}
  }'

The OpenAI-compatible and Anthropic-compatible endpoints both support streaming (stream: true). The native /inference endpoint does not support streaming — use one of the compatible formats if you need token-by-token output.

Prompt caching

Prompt caching cuts cost and latency on repeated prompt prefixes, but how you enable it depends on the model family:

OpenAI / GPT family — caching is automatic. You don’t need to do anything; any cache_control you send is silently ignored rather than applied, so there’s no need to strip it if you’re switching a client over from Claude.
Claude / Anthropic-style — caching is opt-in by default. Pioneer forwards your request as-is and does not add cache markers for you, so unless you add a cache_control marker on the stable part of your prompt, the prefix is not cached and you pay full input price every turn.

To cache the stable prefix on a Claude model, send the content as a block array and mark it — this works on /v1/chat/completions and /v1/responses too, not just the Anthropic-compatible endpoint:

curl -X POST https://api.pioneer.ai/v1/chat/completions \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "messages": [
      {
        "role": "system",
        "content": [
          {
            "type": "text",
            "text": "Large stable system prompt or reusable context goes here.",
            "cache_control": { "type": "ephemeral" }
          }
        ]
      },
      { "role": "user", "content": "What is prompt caching?" }
    ]
  }'

Cached tokens are billed at a discounted rate and are visible in Settings → Credits. See Prompt Caching for where to place markers, minimum sizes, rates, how to read token usage, and tips for maximizing cache hits.

Opting out of inference persistence

By default, Pioneer stores every inference — the input, output, and metadata — so it can drive evaluation, use-case clustering, and adapter training. Pass store: false to skip persistence for a specific request.

curl -X POST https://api.pioneer.ai/v1/chat/completions \
  -H "Authorization: Bearer pio_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "messages": [
      {"role": "user", "content": "Hello, world!"}
    ],
    "store": false
  }'

store: false is supported on all three request formats — native /inference, /v1/chat/completions, and /v1/messages — and works identically for streaming and non-streaming requests.

What changes with `store: false`

	Default (`store: true`)	`store: false`
Inference executes	Yes	Yes
Input/output stored	Yes	No
Evaluation run	Yes	No
Use-case clustering	Yes	No
Adapter training feed	Yes	No
Token billing	Yes	Yes
`inference_id` in response	Yes	Yes (for correlation)

Billing still applies. Token usage, COGS, and metered billing are recorded even when store: false is set — only the full request/response payload is not retained.

When to use it

Health checks — liveness and readiness probes that run continuously - Internal benchmarks — evaluations you run against your own ground truth that shouldn’t pollute user-facing inference history - Development and testing — exploratory calls during integration work where accumulating inference rows adds noise

Inference history

Pioneer records every inference call. You can retrieve past results and submit corrections to improve future training data.

# List recent inferences
curl https://api.pioneer.ai/inferences \
  -H "X-API-Key: YOUR_API_KEY"

# Get a specific inference result
curl https://api.pioneer.ai/inferences/INFERENCE_ID \
  -H "X-API-Key: YOUR_API_KEY"

# Mark as correct
curl -X POST https://api.pioneer.ai/inferences/INFERENCE_ID/feedback \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"verdict": "correct"}'

# Submit a correction
curl -X POST https://api.pioneer.ai/inferences/INFERENCE_ID/feedback \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"verdict": "incorrect", "corrected_output": {...}, "notes": "optional reviewer note"}'

# Read back the feedback you (or a teammate) already submitted
curl https://api.pioneer.ai/inferences/INFERENCE_ID/feedback \
  -H "X-API-Key: YOUR_API_KEY"

GET .../feedback returns 404 if no feedback has been submitted for that inference yet. The notes field on POST .../feedback is optional. Optional query filters for GET /inferences: limit, offset, model_id, task, project_id, training_job_id, latency_min, latency_max (ms), since, until (ISO 8601 bounds on created_at). GET /inferences/INFERENCE_ID also surfaces any human feedback already submitted (human_verdict, human_corrected_output, human_feedback_notes) inline on the record.

Get Started

Integrations

Core Concepts

API Reference

Guides

Account

Changelog

Inference on Pioneer: native, OpenAI, and Anthropic APIs

Pioneer native format

Schema structure

Decoder models

OpenAI-compatible format

Anthropic-compatible format

Prompt caching

Opting out of inference persistence

What changes with `store: false`

When to use it

Inference history

​Pioneer native format

​Schema structure

​Decoder models

​OpenAI-compatible format

​Anthropic-compatible format

​Prompt caching

​Opting out of inference persistence

​What changes with store: false

​When to use it

​Inference history

Pioneer native format

Schema structure

Decoder models

OpenAI-compatible format

Anthropic-compatible format

Prompt caching

Opting out of inference persistence

What changes with `store: false`

When to use it

Inference history