ProductMar 25, 20269 min

vMira 5.2: sharper Russian, sharper code.

vMira 5.2 is a focused refresh on top of 5.1: a reworked post-training pipeline delivers measurable gains on Russian, code, and multi-step reasoning, with the same deployment footprint as 5.1. Available today across every vMira product.

VC
VCorp
Leadership
VC
VCorp
Research

vMira 5.2 is a post-training update on top of 5.1. Same base, same long-context behaviour, same multimodal capability — but a reworked post-training pipeline, an expanded set of Russian-language reasoning data, and calibration tuned for the public categories on which the model is independently evaluated. It is the strongest Russian-language vMira build we have shipped.

5.2 is a release about quality. Architecture and deployment are unchanged: the same base components as 5.1, the same pricing, the same builds. What changed is the post-training pipeline: an expanded set of Russian-language reasoning data, stricter reward filtering, and an updated alignment stage that lands meaningfully better on chain-of-thought workloads.

This post covers what improved and how to roll out 5.2 on top of an existing 5.1 integration without rewriting client code.

What changed in 5.2

Deployment is drop-in for existing customers: the same model identifier (`mira` for the base model, `mira-thinking` for the reasoning build), the same pricing, the same `model_meta` format, the same hosting regions. Improvements are concentrated in **post-training**. Three areas delivered the largest gains. **Russian-language reasoning** — the data set has been expanded with structured legal analysis and factuality checks grounded in Russian corporate and regulatory text. **Code** — coverage of instruction tasks has been broadened, and refusal calibration has been adjusted so the model proposes a working solution more often than it declares the problem out of scope. **Multi-step logic** — the alignment stage now additionally rewards traces in which intermediate claims survive the final answer.

Post-training

The pipeline is the same as 5.1, but every stage received concrete improvements. Supervised fine-tuning ran on an expanded curated mix with a higher share of Russian-language reasoning data, code tasks with verifiable tests, and targeted calibration for the public Russian-language evaluation categories. The alignment stage uses a stricter reward function that scores trace-to-answer consistency. Data preparation quality improved through tighter reward filtering.

Context and multimodality

Unchanged from 5.1: 262,144 native context tokens, extension to one million tokens for specialised workloads, the same image-input head, the same support for ordered image sequences for frame-by-frame reasoning. If 5.1 already worked for you on long documents or multimodal queries, 5.2 will work the same — only sharper on content that demands reasoning.

Compatibility with 5.1

5.2 is fully drop-in over 5.1 at the API surface. Same endpoint, same parameters, same response format, same `reasoning` block for the thinking build. Existing integrations continue to work unchanged; the one thing we recommend is re-running your eval set, because the numbers will be different on the new build (typically better). For customers who pin to a specific build hash, the old 5.1 hash remains live for another six months, so migration happens on your terms.

5.2 is a post-training update over 5.1: same base stack, reworked training pipeline, drop-in API compatibility.

Deployment

Unchanged from 5.1. The **hosted API** runs in our Moscow data centre, billed per token in rubles or dollars. **Private deployment in the Russian Federation region** is available under a separate SLA, with primary collection of personal data inside Russia in line with Federal Law 152-FZ. The **on-premise build** is a compact package that runs on a single modern Linux server with a single consumer GPU. Throughput profile and integration compatibility are unchanged from 5.1.

Where it falls short

The 5.1 limits list mostly carries over to 5.2. We logged what improved and what stayed the same:

Architecture is the ceiling. Post-training is how close the model gets to it. 5.2 is about getting closer.
VCorp research

For developers

Nothing changes at the API layer: same `mira`, same `mira-thinking`, same request signature, same `model_meta` format with a new build hash. Existing customers receive 5.2 automatically on requests without an explicit pin; those pinning to a hash continue to receive 5.1 unchanged. SDKs in Python, TypeScript, Go and Rust are updated; the release notes capture the exact deltas. Enterprise customers with private endpoints can request migration on their own schedule through their account manager.

Why post-training, not a new base model

Every two or three releases we face the same choice: a new base model or another post-training pass. 5.2 is a post-training pass, and that is a deliberate choice. A large architectural upgrade — what will become 6.0 — requires months of work and carries non-linear quality risk. A post-training pass is materially faster, has predictable deltas, and does not break existing integrations. In the Russian market, where customers are often locked to fixed-model contracts on a quarterly or semi-annual cadence, drop-in releases are what is needed right now. The larger base model is next.

Public evaluation

We ran 5.2 on the standard open Russian-language evaluation framework maintained by an independent team. Results are under moderation by the framework operators — by their process, publication happens after submission review. When they publish, we will update this post with concrete per-category numbers. Until then we deliberately withhold internal scores — our own editorial policy requires that the first published numbers be numbers from an independent evaluation.

What we did NOT improve

Post-training delivers gains exactly where it is targeted. Inference speed is unchanged — same base stack, same model in memory. Context size is unchanged — 262K native, 1M with extension. The image-input head was not retrained — improvements there will come with the next base model. If your use case is bound by one of those, 5.2 will not give you anything new.

Migration

Most customers get 5.2 automatically with no code changes — the switch is transparent on the serving side. If you have hard-coded a build hash, the old 5.1 hash remains valid for another six months and will then auto-route to 5.2. Private-deployment customers receive an updated image through their account manager on their own schedule. The on-premise build updates through the standard release mechanism; set `model: "mira-5.2"` explicitly or keep `mira` to auto-update.

Did you find this article useful?