Model comparisons · 2026-09-29
Choosing a text classification model: Leyla, Leyla English and Leyla Typed Decisions
Which of Leyla's three versions fits which job? Choosing a text classification model for Turkish e-mail filtering, English text, security incidents, invoices and agent traces.
Short answer: choose by language and job
Leyla comes as three IDs, and all three work on the same endpoint, POST /v1/systemone, with the same request format. What separates them is the language of the text and the type of work. If the text is Turkish or arrives in more than one language, use llmtr/leyla. If it is English only, llmtr/leyla-english fits better. If you are making English decisions on invoices, security incidents, customer service records or agent traces, llmtr/leyla-typed-decisions is tuned for that work.
All three are hosted in Turkey, request content does not leave Turkey, and all three share one price: $0.03 per 1M input tokens, output free. The choice is therefore about accuracy and context, not cost.
The three versions compared
Context differs too. llmtr/leyla and llmtr/leyla-typed-decisions work with 1,024 tokens, llmtr/leyla-english with 512. Text past the context is cut without an error, so separate the part of a long text that the decision needs before sending it.
All three are called with the same account, the same API key and the same balance; choosing one needs no separate sign-up. You can also use more than one in a workflow: detect the language of incoming text in your own code, send Turkish text to llmtr/leyla and English invoice records to llmtr/leyla-typed-decisions. Nothing in the request changes except the model field.
| Model | Text language | Context | Suited to | Input price |
|---|---|---|---|---|
| llmtr/leyla | 100+ languages, Turkish included | 1,024 tokens | Ticket routing, e-mail filtering, tagging | $0.03 / 1M tokens |
| llmtr/leyla-english | English only | 512 tokens | General classification of English text | $0.03 / 1M tokens |
| llmtr/leyla-typed-decisions | English | 1,024 tokens | Invoices, security incidents, customer service, agent traces | $0.03 / 1M tokens |
E-mail filtering and tagging
Inbox filtering usually sees mixed languages: customers write in Turkish, suppliers in English, and automated notices use both. llmtr/leyla is the right default here, because one question set behaves the same across languages. A typical set is a noul asking whether the e-mail needs a reply, plus a choice between invoice, order, complaint and notification.
If all incoming text is English, for example on a support line that only serves international customers, try llmtr/leyla-english with the same question set. Compare the two models on the same sample before deciding; remember the context is 512 tokens, and strip signatures and quoted older messages from the text.
Security incident and invoice decisions
llmtr/leyla-typed-decisions is tuned for specific business decisions on English records. On the security side, you can ask an alert text for its severity and whether the on-call engineer should be paged now. On the finance side, you can ask whether an invoice contains a dispute or which approval step it goes to.
The body below asks an SSH alert for a severity choice and a paging decision. You still turn the probabilities into decisions with thresholds: when the probability of high severity is above your threshold you open the incident automatically, and you flag the cases in between for an analyst.
Security incident body for POST /v1/systemone
{
"model": "llmtr/leyla-typed-decisions",
"state": "Alert: 14 failed SSH logins for user admin from one external address within 3 minutes, followed by a successful login and a new cron job created at 02:14.",
"questions": {
"severity": {
"type": "choice",
"instructions": "How severe is this security incident?",
"criteria": {
"low": "noise, expected activity",
"medium": "suspicious, needs review",
"high": "likely compromise"
}
},
"needs_escalation": {
"type": "noul",
"instructions": "Should the on-call engineer be paged now?"
}
}
}Auditing agent traces
When an AI agent works by calling tools, each step's record is a short English text: which tool was called with which arguments and what it returned. llmtr/leyla-typed-decisions is tuned to decide on these records. Noul questions asking whether a step needs approval, whether it relates to the user's request, or whether it touches sensitive data suit this work.
This audit has to be fast and cheap enough not to slow the agent down; free output and $0.03 per 1M input tokens make checking every step practical. Send each step as its own request and include only the latest step's record to stay within the context.
Validate the choice on your own data
When deciding between versions, measure on your own samples rather than relying on a general ranking. Pick 50 to 100 past records whose labels you know, send the same question set to two models, and see which one gives the correct option the higher probability. Because the protocol is the same, the comparison only needs the model field changed.
If your texts do not fit the context, the Leyla family is not the right choice for that job. For long documents upstage/solar-decide offers 524,288 tokens and typesafe/jev 32,000 tokens; both are hosted outside Turkey.
Frequently asked questions
Can I use llmtr/leyla-english on Turkish text?
It is not recommended. llmtr/leyla-english is designed for English text only. For Turkish or mixed-language text, use llmtr/leyla.
Do the three versions cost different amounts?
No. All three charge $0.03 per 1M input tokens with free output. They differ in language, type of work and context length.
Do I need to change my code to switch versions?
Only the model field. The request and response format is the same across all three. If you switch to llmtr/leyla-english, the context is 512 tokens; check that your text fits.