Lothera/Thero-1-Flash

⚡ Thero-1 Flash

Fast. Capable. Open.

Açık Ağırlıklar, Bağımsız Zekâ.

A compact language model fine-tuned for conversational AI, coding assistance, and structured tool-use workflows.

---

🌟 Overview

Thero-1 Flash is a language model developed by Lothera Intelligence, based on Qwen3.5-4B and fine-tuned for practical assistant workloads.

The model focuses on Turkish and English conversations, coding assistance, structured outputs, and tool-oriented interactions.

Thero-1 Flash is the first release in the Thero model family, with an emphasis on making capable AI systems accessible to developers and researchers.

Key Features

• ⚡ Compact Model: A 4B-class model designed for a range of hardware configurations.
• 🇹🇷 Turkish & English: Supports multilingual conversations and technical assistance.
• 🛠️ Tool-Use Training: Fine-tuned on examples involving structured tool interactions and function-calling patterns.
• 💻 Coding Assistance: Supports code generation, debugging, explanations, and refactoring.
• 💬 Conversational AI: Suitable for assistant applications and experimental agent workflows.
• 🌐 Open Weights: Distributed for research and development, subject to the applicable license.

Performance depends on the task, inference configuration, hardware, and evaluation methodology. The capabilities described here should not be interpreted as independently verified benchmark results.

---

📊 Model Details

Attribute	Specification
Model Name	Thero-1 Flash
Developer	Lothera Intelligence
Model Family	Thero
Base Model	Qwen/Qwen3.5-4B
Model Size	Approximately 4B-class
Model Type	Fine-tuned causal language model
Primary Languages	Turkish, English
Training Method	Supervised Fine-Tuning (SFT)
Intended Tasks	Conversation, coding, structured outputs, tool-use
Framework	Hugging Face Transformers

Intended Use

Thero-1 Flash is intended for:

• General-purpose conversational assistants
• Turkish-language AI applications
• Code generation and debugging
• Structured response generation
• Tool-using assistant prototypes
• Lightweight agent workflows
• Research into compact language models

---

🚀 Quickstart

Installation

Install the required dependencies:

pip install -U torch transformers accelerate

Load and Run

import torch
from transformers import AutoTokenizer, AutoModelForCausalLM

model_id = "LotheraAI/Thero-1-Flash"

tokenizer = AutoTokenizer.from_pretrained(model_id)

model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype="auto",
    device_map="auto",
)

messages = [
    {
        "role": "system",
        "content": (
            "You are Thero-1 Flash, a helpful and precise "
            "AI assistant developed by Lothera Intelligence."
        ),
    },
    {
        "role": "user",
        "content": (
            "Merhaba! Kendini tanıt ve neler yapabildiğini açıkla."
        ),
    },
]

inputs = tokenizer.apply_chat_template(
    messages,
    tokenize=True,
    add_generation_prompt=True,
    return_tensors="pt",
    return_dict=True,
).to(model.device)

with torch.inference_mode():
    outputs = model.generate(
        **inputs,
        max_new_tokens=256,
        do_sample=True,
        temperature=0.7,
        top_p=0.85,
        repetition_penalty=1.05,
    )

new_tokens = outputs[0, inputs["input_ids"].shape[1]:]

response = tokenizer.decode(
    new_tokens,
    skip_special_tokens=True,
)

print(response)

Compatibility note: The model repository must contain a compatible tokenizer and chat template. Follow the base model's documented loading requirements if additional configuration is necessary.

---

🛠️ Tool-Use & Function Calling

Thero-1 Flash is fine-tuned on examples involving structured tool interactions and function-calling patterns.

In a tool-enabled application, the model proposes a function call, the application validates and executes it, and the result is returned to the model.

The model does not execute Python functions by itself. The surrounding application is responsible for tool execution, argument validation, and access control.

End-to-End Function Calling Example

The following example demonstrates the complete application-side loop using a local demonstration function. It does not require a weather API or external network access.

The model must generate a recognizable tool-call structure for the example to execute successfully. The code deliberately stops with an informative error if the model returns ordinary text instead.

import json
import torch

from transformers import AutoTokenizer, AutoModelForCausalLM
from jsonschema import validate, ValidationError

MODEL_ID = "LotheraAI/Thero-1-Flash"
MAX_TOOL_ROUNDS = 3

tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)

model = AutoModelForCausalLM.from_pretrained(
    MODEL_ID,
    torch_dtype="auto",
    device_map="auto",
)

# 1. Define an application-side tool.
def get_demo_weather(city: str, unit: str = "celsius") -> dict:
    """Return deterministic demonstration data, not live weather."""
    demo_data = {
        "istanbul": {"celsius": 18, "fahrenheit": 64.4},
        "ankara": {"celsius": 14, "fahrenheit": 57.2},
    }

    city_key = city.strip().lower()

    if city_key not in demo_data:
        return {
            "error": "No demonstration data available for this city."
        }

    if unit not in ("celsius", "fahrenheit"):
        return {"error": "Unsupported temperature unit."}

    return {
        "city": city,
        "temperature": demo_data[city_key][unit],
        "unit": unit,
        "source": "synthetic_demo_data",
    }


# 2. Define the function schema.
tool_schema = {
    "type": "object",
    "properties": {
        "city": {
            "type": "string",
            "minLength": 1,
            "maxLength": 100,
        },
        "unit": {
            "type": "string",
            "enum": ["celsius", "fahrenheit"],
        },
    },
    "required": ["city"],
    "additionalProperties": False,
}

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_demo_weather",
            "description": (
                "Retrieve demonstration temperature data for "
                "Istanbul or Ankara. This is not live weather."
            ),
            "parameters": tool_schema,
        },
    }
]

messages = [
    {
        "role": "system",
        "content": (
            "You are Thero-1 Flash. "
            "Use get_demo_weather when the user requests "
            "temperature data for a supported city. "
            "Never claim demonstration data is live weather."
        ),
    },
    {
        "role": "user",
        "content": "İstanbul'da sıcaklık kaç derece?",
    },
]


def generate(messages):
    """Generate a continuation of the current conversation."""
    inputs = tokenizer.apply_chat_template(
        messages,
        tools=tools,
        tokenize=True,
        add_generation_prompt=True,
        return_tensors="pt",
        return_dict=True,
    ).to(model.device)

    with torch.inference_mode():
        output = model.generate(
            **inputs,
            max_new_tokens=256,
            do_sample=False,
        )

    new_tokens = output[0, inputs["input_ids"].shape[1]:]

    return tokenizer.decode(
        new_tokens,
        skip_special_tokens=False,
    )


def parse_tool_call(text):
    """
    Parse a JSON tool call using the example protocol:

        <tool_call>
        {"name": "get_demo_weather",
         "arguments": {"city": "Istanbul"}}
        </tool_call>

    This is an application-level example protocol, not a claim
    that the model always emits this format.
    """
    start_tag = "<tool_call>"
    end_tag = "</tool_call>"

    start = text.find(start_tag)
    end = text.find(end_tag, start + len(start_tag))

    if start == -1 or end == -1:
        return None

    payload = text[start + len(start_tag):end].strip()
    call = json.loads(payload)

    if not isinstance(call, dict):
        raise ValueError("Tool call must be a JSON object.")

    if call.get("name") != "get_demo_weather":
        raise ValueError("Unknown or unauthorized tool.")

    arguments = call.get("arguments")

    if not isinstance(arguments, dict):
        raise ValueError("Tool arguments must be a JSON object.")

    validate(instance=arguments, schema=tool_schema)

    return call


# 3. Generate, parse, execute, and return tool results.
for round_index in range(MAX_TOOL_ROUNDS):
    model_output = generate(messages)
    print(f"\nModel output:\n{model_output}")

    try:
        call = parse_tool_call(model_output)
    except (ValueError, json.JSONDecodeError, ValidationError) as exc:
        raise RuntimeError(
            "The model did not produce a valid tool call. "
            "Inspect the output and adapt the parser to the "
            "model's actual chat-template format."
        ) from exc

    if call is None:
        messages.append({
            "role": "assistant",
            "content": model_output,
        })
        print("\nFinal response:\n", model_output)
        break

    arguments = call["arguments"]

    # The function is selected from an explicit allowlist.
    result = get_demo_weather(**arguments)

    # Store the proposed call and its execution result.
    messages.extend([
        {
            "role": "assistant",
            "content": model_output,
        },
        {
            "role": "user",
            "content": (
                "Tool result for get_demo_weather: "
                + json.dumps(result, ensure_ascii=False)
                + "\nUse this result to answer the original question. "
                "Do not call another tool."
            ),
        },
    ])

else:
    raise RuntimeError("Maximum tool-call rounds reached.")

Install the additional validation dependency:

pip install jsonschema

Important Tool-Use Compatibility Notes

The code above illustrates the complete control flow, but it is not guaranteed to run unchanged with every checkpoint.

• The model must actually emit the <tool_call>...</tool_call> protocol used by this example.
• Some Qwen-family chat templates use different tool-call markers or special tokens. Inspect the actual model output and adapt the parser accordingly.
• The example returns tool results in a user message for portability. A model-specific implementation should use the chat template's documented tool-result format and preserve the appropriate assistant/tool message structure.
• If the model produces ordinary text instead of a tool call, the application cannot assume a function was selected successfully.
• JSON Schema validation does not replace authorization, timeouts, output-size limits, or other execution safeguards.

For production use, prefer the model's documented native tool-call format when available instead of inventing a new protocol.

---

🌐 Languages

Thero-1 Flash primarily targets:

• Turkish (tr): Conversations, explanations, and general assistance.
• English (en): Conversations, coding tasks, and technical explanations.

Performance may vary by language and task. These targets do not guarantee equal proficiency in every domain.

---

🖥️ Hardware & Deployment

Requirements depend on checkpoint precision, context length, runtime, and workload.

Deployment	Notes
GPU inference	FP16/BF16 support depends on GPU compatibility and available memory
Quantized inference	4-bit formats can reduce memory requirements
CPU inference	Possible with a compatible runtime, generally at lower throughput
GGUF	Requires a compatible GGUF conversion and inference backend
vLLM / SGLang	Compatibility must be verified for the model architecture and tool-call format

A quantized checkpoint may be more practical on consumer hardware, but memory requirements also include the KV cache, runtime overhead, and context length.

No universal minimum VRAM or generation speed is guaranteed.

---

📈 Evaluation & Benchmarks

Formal benchmark results should be published alongside reproducible evaluation configurations.

Planned evaluation areas include:

• General knowledge and reasoning
• Turkish and English instruction following
• Coding and debugging
• Tool selection and argument accuracy
• Structured output reliability
• Inference speed and memory consumption

Benchmark reports should identify the datasets, evaluation methods, model settings, and baselines used.

No benchmark score or performance advantage is claimed without supporting results.

---

⚠️ Safety & Limitations

Like other compact language models, Thero-1 Flash may:

• Generate inaccurate or fabricated information.
• Produce incorrect code or unreliable reasoning.
• Fail to follow instructions consistently.
• Generate malformed function arguments or structured outputs.
• Lose instruction fidelity in long conversations.
• Perform differently across languages and specialized tasks.

Generated code and tool arguments should be reviewed before use.

Never execute arbitrary model-generated code, shell commands, or function names without appropriate validation and authorization. Restrict tools to an explicit allowlist and isolate sensitive operations.

The model is not intended to replace qualified human judgment in high-stakes situations.

---

📜 License

Thero-1 Flash is based on Qwen/Qwen3.5-4B.

Users should review the applicable base-model license and any additional terms governing fine-tuning, redistribution, and commercial use.

The repository's license metadata must accurately represent the terms applicable to the released checkpoint. The metadata above should be verified before publication.

---

🌌 About Lothera Intelligence

Lothera Intelligence is an independent AI initiative within the Lothera ecosystem, focused on developing practical language models and AI systems.

Thero-1 Flash marks the beginning of the Thero model family, with future development guided by model quality, reproducible evaluation, and practical applications.

Organization: Lothera Intelligence

THERO-1 FLASH

Fast. Capable. Open.

_{© 2026 Lothera Intelligence}