LLMTR Qwen 3.8 27B

Qwen 3.8 27B is a first-party chat model hosted by us in Turkey. It is called through /v1/chat/completions with the canonical model id llmtr/qwen3-8-27b. It fits agent flows, code work and long-document analysis where the data has to be processed in Turkey.

Property	Value
Model id	llmtr/qwen3-8-27b
Context window	262,144 tokens (262K)
Price (input / output / cache read)	$5.00 / $7.00 / $1.25 per 1M tokens
Image input	No
Prompt cache	Yes
Tool calling	Yes
JSON output	JSON object and JSON schema
Thinking mode	Yes, off by default
Audio / video input	No
Image generation	No

curl "$LLMTR_BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer llmtr-your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llmtr/qwen3-8-27b",
    "messages": [
      { "role": "user", "content": "Summarize this contract clause in two sentences." }
    ],
    "max_tokens": 1024
  }'

Thinking is off by default

On a plain request the model answers directly: no reasoning pass runs and no extra tokens are spent. Turn thinking on for work that needs multi-step reasoning, hard debugging or planning. Both forms do the same thing:

// The :think suffix on the model id
{ "model": "llmtr/qwen3-8-27b:think", "messages": [{ "role": "user", "content": "Find the race condition in this function." }], "max_tokens": 8192 }

// Or the reasoning field in the request body
{ "model": "llmtr/qwen3-8-27b", "reasoning": true, "messages": [{ "role": "user", "content": "Find the race condition in this function." }], "max_tokens": 8192 }

With thinking on, the reasoning is returned in message.reasoning_content and the tokens it produces are spent from your max_tokens budget. If the budget is small, reasoning consumes all of it and the model stops before it reaches the answer; finish_reason is length. The response then holds no final answer: content may be empty or may carry the unfinished reasoning. Tell the two apart by finish_reason, not by content:

{
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "The function is called from two threads. First...",
        "reasoning_content": "The function is called from two threads. First..."
      },
      "finish_reason": "length"
    }
  ]
}

Set max_tokens to at least 4096 with thinking on; hard questions need 8192 or more. Check finish_reason before you use a response: length means the answer was not completed, so raise the budget and send the request again.

The :fast suffix and reasoning: false keep thinking off, which is already the default.

Reasoning tokens are billed as output and are already counted inside completion_tokens; they are not billed twice.

Input types

The model accepts text only. An image_url, audio, video or file part in the message returns 400 unsupported_input:

{
  "error": {
    "message": "Model does not support image input",
    "type": "unsupported_input"
  }
}

For work that needs image understanding, pick one of the catalog models that supports image input.

Tool calling

The model supports the standard OpenAI tools schema and returns real tool_calls. tool_choice accepts auto, required, none and a single function selected by name.

{
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "",
        "tool_calls": [
          {
            "id": "call_1",
            "type": "function",
            "function": { "name": "get_weather", "arguments": "{\"city\":\"Ankara\"}" }
          }
        ]
      },
      "finish_reason": "tool_calls"
    }
  ]
}

A single response may carry more than one tool call, but that is not guaranteed; your client should handle the whole tool_calls array. In multi-step flows, append the assistant message to the history with its tool_calls and, when present, its reasoning_content.

JSON output

response_format supports two forms:

// A valid JSON object
{ "response_format": { "type": "json_object" } }

// JSON that conforms to the schema you supply
{
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "order",
      "strict": true,
      "schema": {
        "type": "object",
        "additionalProperties": false,
        "required": ["product", "quantity"],
        "properties": {
          "product": { "type": "string" },
          "quantity": { "type": "number" }
        }
      }
    }
  }
}

json_object only makes the output valid JSON; describe the fields you want in your prompt. When field names and types have to be fixed, use json_schema. If max_tokens does not cover the whole answer the JSON is cut short, so check finish_reason.

Prompt cache

Repeated prompt prefixes (a long system prompt, a fixed RAG context, an agent loop) can be served from the cache. Cached tokens are reported in prompt_tokens_details.cached_tokens and billed at the cache read rate instead of the input rate:

"usage": {
  "prompt_tokens": 8461,
  "completion_tokens": 3,
  "total_tokens": 8464,
  "prompt_tokens_details": { "cached_tokens": 7840 }
}

Here 7840 tokens are billed at $1.25/1M and the remaining 621 at $5.00/1M. To lower cost, keep the fixed content at the start of the message array and the varying content at the end.

A cache hit is not guaranteed: a prefix does not hit the first time it is sent and may hit on later repeats. Billing always follows the real value reported in cached_tokens; requests without a hit are billed at the normal input rate. Treat the cache as a cost optimization, not a guaranteed discount.

Context window

The context window is 262,144 tokens per request and covers the prompt and the completion together. Requests above that limit return 400. There is no separate cap on output; a response can run for as long as there is room left in the context.