API Transition: Responses

The New API (https://llm-server.ai.t-systems.net/v1) introduces a standardized response structure across different model providers. This improves consistency while preserving the core fields used by standard chat completion integrations: choices, message, finish_reason, and usage remain available.

Example: Successful Response

Legacy API

{
  "id": "chatcmpl-example",
  "object": "chat.completion",
  "model": "gpt-6.1-sol",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Hello!"
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 10,
    "completion_tokens": 3,
    "total_tokens": 13
  }
}

New API

{
  "id": "chatcmpl-example",
  "object": "chat.completion",
  "model": "gpt-6.1-sol",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Hello!"
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 10,
    "completion_tokens": 3,
    "total_tokens": 13
  },
  "extra_fields": {}
}

Note

These examples are simplified to illustrate the common response format. Actual responses may contain additional fields depending on the selected model and request.

The value of response.model may also differ from the requested model identifier for some providers.

What Changes?

Aspect	Legacy API	New API
Response structure	Provider-oriented response format	Standardized chat completion format
Standard fields	choices, message, usage, etc.	Same core fields
Token usage	Original provider usage information	Usage details may vary by provider; zero-valued optional fields may be omitted
Optional fields	May include explicit null or empty values	Some optional fields may be omitted
Response model	Typically the requested model identifier	May contain the provider-reported model name, which can differ from the requested identifier
Provider-specific metadata	Generally preserved	May be normalized or omitted
Additional information	Provider-specific fields	Optional diagnostic metadata, including latency information

Token Usage Details

Standard token usage fields remain available, but additional usage details depend on the selected model and provider. For example, some providers return detailed completion token breakdowns, while others expose different usage fields or omit optional details entirely.

Fields such as completion_tokens_details, reasoning_tokens, or provider-specific token categories should therefore be treated as optional. Zero-valued usage details may also be omitted rather than returned explicitly as 0.

Applications that track token consumption should account for these differences when processing usage information.

Additional Response Metadata

The New API may include additional diagnostic information through the extra_fields object. Depending on the request and model, this may include:

• Latency information — helps understand request processing time.
• Routing information — provides additional details about how the request was processed.
• Provider response metadata — additional information when available.

These fields are optional and should not be treated as part of the required standard response structure.

What You Need to Check

For standard integrations: Applications that primarily use choices, message, finish_reason, and the common token usage fields generally require minimal changes to response parsing.

For model identification: Review code that assumes response.model always matches the requested model name.

For strict response validation: Allow optional fields to be absent and support additional response metadata.

For token accounting: Review provider-specific usage fields and do not assume that every provider returns identical token breakdowns.

For provider-specific integrations: Review any code that depends on nonstandard response fields.