Executive summary
Mibyan begins with a K2.6 foundation and is adapted for Arabic professional work. The work focuses on language fit, constraint retention, structured outputs, bilingual operating contexts, and a controlled service boundary. We evaluate the result as a system: quality, latency, reliability, and recoverability are reported together. We deliberately distinguish what we publish from what is operationally sensitive. The report describes behavior and method, but not private customer data, credentials, internal hosts, or live routing configuration.Continued pretraining and fine-tuning
Mibyan is developed with a focus on Arabic and practical work. The data and task mix emphasizes Modern Standard Arabic, Gulf terminology, Arabic-English code switching, business writing, structured outputs, and instruction following. The goal of fine-tuning is not simply to make Arabic text fluent. It is to improve the complete behavior users need: understanding an underspecified request, preserving constraints, choosing a useful structure, and producing an output that can be reviewed and edited.Adaptation principles
Model-system boundary
The model is exposed through the stable public identifiermibyan-4.1 and an OpenAI-compatible contract. The public boundary is intentional: applications integrate against a consistent interface while the service can improve routing, serving, safety controls, and observability behind that boundary.
This is not obscurity for its own sake. Publishing operational endpoints or private routing details would not make a customer integration more reproducible; it would weaken the service boundary. Reproducibility belongs in the evaluation artifact: versioned prompts, datasets, settings, metrics, and aggregate outcomes.
Real-world evaluation
Public leaderboards are useful signals, but they often contain short prompts, narrow answers, or tasks that do not represent a real work session. Mibyan evaluation should therefore include held-out tasks derived from real Arabic workflows: reports, plans, extraction, bilingual rewriting, calculations, and multi-step agent tasks. Each release should be evaluated with the same harness across Mibyan and selected frontier references. The harness must record the model ID, prompt version, dataset version, sample count, decoding settings, tools, judge rubric, and failure categories.
The graphic shows the evaluation structure, not numerical model results. Published scores belong on the benchmark page only after the corresponding run is complete and reproducible.
Performance and cost
For an interactive platform, quality is only one part of performance. Report quality alongside time-to-first-token, total latency, streaming stability, error rate, token usage, and cost per accepted output. For agentic workloads also report steps, tool-call success, recovery rate, and time to completion. The useful comparison is a Pareto view: how much quality a model delivers for a given latency and cost on the tasks your users actually perform. A general frontier model may lead on breadth while Mibyan may be the better fit for Arabic professional work or a controlled API workflow. For the engineering treatment of this trade-off, see efficient serving. A lean footprint is meaningful only when the workload, concurrency, quality, and reliability conditions are disclosed alongside it.Safety and responsible use
Mibyan is intended to support people and applications, not replace controls around consequential decisions. Product teams should use the model inside a system that has scoped access, request correlation, rate and budget limits, validation for structured outputs, and an escalation path for uncertain or high-impact work.Production use
Use the public model IDmibyan-4.1 through the OpenAI-compatible API.
Production readiness also requires project-scoped keys, rate and budget controls, request correlation IDs, usage logs, retries with backoff, and application-level validation for structured outputs.