Motif 3

Motif 3 is called through /v1/chat/completions on LLMTR. It is a text model built for agentic coding, tool-driven work and terminal-style troubleshooting, and it is currently offered free.

Model	Context	Max output	Input / Cache read / Output ($/1M)
motif/motif-3	262,144	Bounded by the context window	0 / 0 / 0

curl "$LLMTR_BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer llmtr-your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "motif/motif-3",
    "messages": [
      { "role": "user", "content": "Find the bug in this function." }
    ],
    "max_tokens": 8192
  }'

Text only

The model takes text and returns text. Image, audio and document input are rejected; a request carrying such a content part fails.

This is a point where the provider's own model listing says otherwise: it publishes a supports_vision flag for this id. The measurement, not the flag, is what this page follows — images were rejected both as base64 data URLs and as remote https:// URLs.

The output limit is the context window

The model has no separate output ceiling. The limit applies to the sum of prompt and response: together they cannot exceed 262,144 tokens.

In practice a long prompt leaves less room for the answer. A 257,160-token prompt works with max_tokens: 32 and is rejected with max_tokens: 10000.

Reasoning is always on

The model always reasons before answering, and there is no way to turn that off. The hidden reasoning tokens are counted as output.

reasoning_effort is not supported on this row. The provider rejects none, minimal, xhigh and max with a 400, and the three values it does accept — low, medium, high — did not separate under measurement; low in fact reasoned longer than high. Exposing a control that does not work would bill the caller for reasoning tokens under a setting they believe reduces them.

For the same reason this model has no :fast / :think suffixes: a suffix you believed was quieting the model would change nothing.

Tool calling

tool_choice works as auto, as required and as a named function. The model can emit several tool calls in one turn, and it reads a role: "tool" result back and answers from it. The streamed path behaves the same way.

curl "$LLMTR_BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer llmtr-your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "motif/motif-3",
    "messages": [
      { "role": "user", "content": "What is the weather in Istanbul?" }
    ],
    "tools": [
      {
        "type": "function",
        "function": {
          "name": "get_weather",
          "description": "Get the current weather for a city",
          "parameters": {
            "type": "object",
            "properties": { "city": { "type": "string" } },
            "required": ["city"]
          }
        }
      }
    ],
    "tool_choice": "required",
    "max_tokens": 4096
  }'

tool_choice: "none" is rejected on this model when tools are attached. The provider does not implement that value: instead of suppressing the tool call it writes the raw template into the reply text and returns finish_reason: stop — HTTP 200, an empty tool_calls field and an answer you cannot use.

LLMTR stops the request before it reaches the provider and returns a 400 telling you what to do instead. Because the request never enters the quota, it costs nothing against your free allowance. To disable tool use, leave tools out of the request entirely — with no tools, tool_choice: "none" is harmless and is not rejected.

Structured outputs

response_format is supported in both json_object and json_schema form. A schema given with strict: true is genuinely enforced: the model obeyed it even under a prompt that demanded keys the schema forbids and a wrongly typed value.

curl "$LLMTR_BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer llmtr-your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "motif/motif-3",
    "messages": [
      { "role": "user", "content": "Give me facts about Ankara." }
    ],
    "response_format": {
      "type": "json_schema",
      "json_schema": {
        "name": "city_facts",
        "strict": true,
        "schema": {
          "type": "object",
          "additionalProperties": false,
          "properties": {
            "city": { "type": "string" },
            "population": { "type": "integer" }
          },
          "required": ["city", "population"]
        }
      }
    },
    "max_tokens": 1024
  }'

Prompt cache

Repeated prompt prefixes come back with usage.prompt_tokens_details.cached_tokens filled in. On calls after the first, the measured cache read covered nearly the whole shared prefix.

The row is free today, so the cache does not change your bill — but it does show up in your usage records.

Parameters

n is not supported and is rejected with a 400; you cannot ask for several completions in one request.

The fields below are all accepted, but acceptance is not support — this model accepting and ignoring reasoning_effort is the proof. What could be measured was measured:

Field	Measured behaviour
temperature	Genuinely applied: at 2 the output degenerates into noise, at 0 it stays coherent. It is not a determinism control — three calls at temperature: 0 returned three different answers.
seed	Does not give reproducibility: two identical requests with the same seed returned different answers.
logprobs	Returns a populated block, but the tokens in it are the reasoning text, not the visible answer.
stop	Applied — but read the warning below.
top_p	Genuinely applied. Measured as a contrast: temperature: 2 alone degenerates the output, the same request with top_p: 0.01 stays coherent, and top_p: 1 changes nothing, as it should.
frequency_penalty, presence_penalty	Accepted; effect not measured, so this page makes no claim about them.

A stop sequence can empty the response

On this model the stop sequence is matched against the hidden reasoning, which runs first. If the model uses your stop word while thinking, generation halts there and the visible answer never begins.

"count to ten" prompt, no stop      -> "one two three ... ten"
same prompt, stop: ["five"]         -> content: ""   finish_reason: "stop"
same prompt, stop: ["seven"]        -> content: ""   finish_reason: "stop"
same prompt, stop: ["ZZQQ"]         -> "one two three ... ten"

So you get HTTP 200, finish_reason: "stop" and an empty response. Do not send a stop sequence unless you are sure the model will not think of it; on this model the safest choice is not to use stop at all.

Limits

The context window is 262,144 tokens, and as described above the output lives inside that same window.

Because the row is offered free it is subject to a request quota. The quota counts requests, not tokens: every call spends one allowance, however many tokens it used.

Calls that end in failure can spend an allowance too. A prompt over the context window, an error coming back from the provider, or a parameter this row does not support (reasoning_effort, for one) may each cost you one; account for that in retry loops.

A request that is never accepted spends nothing: an invalid body, a content type this model does not take (image, audio, document) and tool_choice: "none" sent alongside tools all fall in that group.

The window is rolling, not reset at midnight: each allowance you spend comes back individually 24 hours after its own request. When you hit the quota you do not have to wait for a new day; the Retry-After header on the response tells you when the first allowance frees. Your metered models are unaffected by this quota.

Requests are processed on third-party infrastructure abroad, and no zero-data-retention guarantee is offered for this row. Do not send sensitive data to this model.