GreenPT

GreenPT is an Utrecht-based platform that states it runs its models inside the European Union. The LLMTR catalog carries its chat, embedding and reranking rows, all addressed with the greenpt/ prefix.

The model list, context windows and current prices live in the model catalog. This page covers the behaviour that does not show up there and that directly affects your requests. What this page says about the provider's behaviour was measured by sending requests to GreenPT directly, not copied from its model card. What it says about LLMTR's own behaviour (the refused image request, the filled-in top_n) comes from the gateway code and its unit tests; it has not been verified through an end-to-end gateway call.

Use model ids exactly as the catalog spells them. Some ids end in -eu; those rows are distinguished because we also serve the same model through another provider.

Data-transfer consent

GreenPT rows cannot be called until your account has granted the data-transfer consent. Without it every request returns 403 provider_consent_required and never reaches the upstream; chat, embeddings and reranking all pass through the same gate.

Consent is given, and withdrawn, from the "Data-transfer consents" card in Settings. It is account-level: granted once, it applies to every API key on that account.

The reason: the content of a request you send to a GreenPT model is transferred to GreenPT to produce the response, and GreenPT processes it on your behalf. Account details such as your name and e-mail are not transferred. GreenPT requires that you are entitled to transfer that content and have given your own users any notice they are owed; the checkbox is the record of that. See GreenPT's data-processing page for the details.

Chat

curl "$LLMTR_BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer llmtr-your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "greenpt/glm-5.3-flash-eu",
    "messages": [
      { "role": "user", "content": "Summarise this stack trace in three points." }
    ],
    "max_tokens": 512
  }'

Every chat row supports tool/function calling, verified over a full two-turn loop. Streaming is supported too, and the final frame carries a complete usage block.

Keep max_tokens generous

Most chat rows reason whether you ask them to or not, and those hidden tokens bill as output. Output costs two to six times input here, so a short question can be more expensive than you expect.

A narrow budget can also leave the answer completely empty: in measurement several rows spent an entire 256-token budget on reasoning and returned no content, then answered correctly once the budget was raised. This matters most in flows where you expect a tool call.

For batch work where output cost has to be predictable, prefer the rows that spend no reasoning tokens: greenpt/qwen3-235b-a22b-instruct-2507, greenpt/qwen3-coder-30b-a3b-instruct-eu, greenpt/mistral-small-3.2-24b-instruct-2506, greenpt/mistral-medium-3.5-128b, greenpt/pixtral-12b-2409, greenpt/llama-3.3-70b-instruct-eu, greenpt/green-l and greenpt/green-l-raw.

Sending images: check the capability in the catalog

Image behaviour on this provider falls into three groups:

• Rows that genuinely process the image. They carry the image_input capability in the catalog. Images can only be sent to these.
• Rows that refuse honestly. The provider answers the request with an error.
• Rows that silently discard the image. Sent directly to the provider, the request returns 200, is billed, and the model replies that it cannot see an image; the input token count is identical to the same request without the image.

That third group is why the catalog's capability list is not copied from the provider's own page: its model card lists two rows as image-capable that turned out not to process images at all.

This does not affect you through LLMTR. Send an image to a model without the image_input capability and the request never reaches the provider: LLMTR answers 400 unsupported_input and you are not charged. The behaviour above is only visible on requests sent straight to the provider.

Rows that carry a hidden system instruction

Some rows run under a system instruction injected server-side, and that instruction is billed to you as input on every request. Base cost measured on a one-word request:

Row	Input tokens	Instruction-free equivalent
greenpt/green-r	8,082	greenpt/green-r-raw (72 tokens)
greenpt/green-l	2,489	greenpt/green-l-raw (8 tokens)
greenpt/glm-5.2-ponytail	580	greenpt/glm-5.2-eu (17 tokens)
greenpt/glm-5.2-honey	354	greenpt/glm-5.2-eu (17 tokens)
greenpt/glm-5.2-caveman	303	greenpt/glm-5.2-eu (17 tokens)

If you write your own system prompt, use the instruction-free equivalent; you will not be paying for a style you are about to overwrite.

The glm-5.2-* rows are the same model under different software-assistant instructions. In measurement caveman was terse and technical, honey answered first and elaborated second, and ponytail wrote the least code. The base, lite and ultra variants of each family did not separate; nothing indicates a quality ladder between them. Some of these rows may introduce themselves as another company's assistant; the model you are billed for, and the one producing the answer, is GLM-5.2 in every case.

Embeddings

curl "$LLMTR_BASE_URL/v1/embeddings" \
  -H "Authorization: Bearer llmtr-your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "greenpt/green-embedding",
    "input": ["merhaba dunya", "hello world"]
  }'

See Embeddings for the shared request and response shape.

Reranking

curl "$LLMTR_BASE_URL/v1/rerank" \
  -H "Authorization: Bearer llmtr-your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "greenpt/green-rerank",
    "query": "LLM platform hosted in Turkey",
    "documents": ["LLMTR is a platform.", "A cat is a mammal."],
    "top_n": 2
  }'

Two behavioural differences:

• You may omit top_n; LLMTR fills the field in for you using the document count.
• truncation is not accepted and is refused with an explicit error. The provider does not shorten a long document — it fails the whole request — so split documents before sending them.

See Reranking for the shared shape.

Rate limit

600 requests per 300 seconds; the sustainable rate is roughly 2 requests per second. In measurement three concurrent requests were enough to hit the limit. Queue on your side for high-concurrency workloads.