Core Models (LLM API)

Overview

Core models are the Apodex language models themselves, exposed over the standard OpenAI wire format — no planning loop, no web search, no tools running on our side. Point the official openai SDK at the base URL below and your existing code works unchanged. They share the /v1/chat/completions path with the deep research models but deliberately behave differently — read the comparison table before you switch.

The same models are also reachable over the Anthropic protocol at POST /v1/messages, at identical prices — see Anthropic Messages API if your client already speaks that dialect (Anthropic SDKs, Claude Code).

Models

Two text-only models, both with a 262,144-token context window. Same API, same parameters — pick by capability and cost.

/ 1M tokens

Both ids are also returned by GET /v1/models, together with their context_length and max_completion_tokens.

Quickstart

The endpoint is OpenAI-compatible: set base_url and your API key, and the official SDKs work as-is. Note that stream defaults to false here.

Headers

Request

curl -X POST https://api.apodex.ai/v1/chat/completions \
  -H "Authorization: Bearer $APODEX_API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-Session-Id: my-conversation-42" \
  -d '{
    "model": "apodex-1.1",
    "messages": [
      {"role": "user", "content": "Explain prefix caching in one paragraph."}
    ],
    "max_tokens": 512,
    "temperature": 0.7
  }'

Response

{
  "id": "chatcmpl-abc123",
  "object": "chat.completion",
  "created": 1712345678,
  "model": "apodex-1.1",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "reasoning_content": "The user wants a one-paragraph explanation...",
        "content": "Prefix caching reuses..."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 42,
    "completion_tokens": 187,
    "total_tokens": 229,
    "prompt_tokens_details": { "cached_tokens": 32 }
  }
}

Supported parameters

Sampling parameters are passed through to the model natively — no rewriting, no silent clamping.

Core models vs. deep research models

Both model families answer on POST /v1/chat/completions, and the semantics are deliberately different. The behaviour is selected by the model id in the request body, so switching model ids also switches the contract.

The deep research contract is documented separately in Chat Completions.

Limits and restrictions

HTTP/1.1 400 Bad Request

{
  "error": {
    "code": "invalid_request",
    "message": "max_tokens exceeds the non-streaming limit of 32768; use stream=true for longer generations",
    "type": "invalid_request_error"
  }
}

Responses API subset

POST /v1/responses is supported as a stateless subset: single-shot request in, response out. Anything that would require us to persist state on your behalf is rejected with HTTP 400 rather than silently ignored.

curl -X POST https://api.apodex.ai/v1/responses \
  -H "Authorization: Bearer $APODEX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "apodex-1.1",
    "input": "Explain prefix caching in one paragraph.",
    "max_output_tokens": 512
  }'

Session caching with X-Session-Id

Sending the optional X-Session-Id header with a stable value for one logical conversation lets us route the turns of that conversation consistently, which significantly improves prefix cache hit rate — lower time-to-first-token and a cheaper cached-input rate on the shared prefix. If you omit the header, the server derives a key from the request content automatically.

• Use one stable, unique value per conversation — a UUID per chat thread is ideal.
• Reuse the same value for every turn of that conversation, including retries of the same turn.
• Do not reuse one value across unrelated conversations, and do not put user identifiers or other sensitive data in it.

X-Session-Id: <your-stable-conversation-key>

Billing

Core models are billed on real token counts reported by the model, in three tiers:

• Input — prompt tokens that were not served from cache.
• Cached input — prompt tokens served from the prefix cache, billed at a lower rate than fresh input.
• Output — tokens the model generates, including any streamed partial output.

Requests with more than 200K input tokens are billed at 2× the listed rates for the entire request — the multiplier applies to input, cached input and output alike.

If the client disconnects mid-generation, the tokens already generated are still billed. Cancelling a request stops further generation but does not refund what has been produced.

Streamed responses carry the usage object only when the request sets include_usage: true in stream_options — the final chunk then reports it, exactly like OpenAI. Omitting it does not change billing: usage is metered server-side either way.

Current list prices are on the Pricing page.

Error responses

Unlike the deep research models, core models return real HTTP status codes. Errors are never wrapped in a 200 response.

HTTP/1.1 400 Bad Request

{
  "error": {
    "message": "model not found: gpt-4o",
    "type": "invalid_request_error",
    "code": "model_not_found"
  }
}