Evidence at a glance
A Longer Context Is Both a Capability Claim and a Test
Mirendil, an AI research lab, has released its first model, Fern 0.1. It is a coding model pretrained from scratch for AI research and development, with a context window of up to ten million tokens. Mirendil translates that capacity into about 23 megabytes of code, or roughly half a million lines, and compares it to holding a codebase on the scale of Megatron-LM in context. Fern is currently available only through hosted early access, with no open weights or quantized builds announced.
The important question raised by the launch is not simply how much text a model can accept. It is whether putting more of the working material in front of a model changes what it can do. A repository, training logs, and days of agent traces might fit into one context, potentially reducing the need for intermediate chunking and summaries. But capacity is an input condition, not a synonym for task competence, and Fern’s reported results make that gap visible.
The Window Extends Farther, but Equal-Length Prediction Is Not Better
Mirendil tested whether a larger window helps next-token prediction on its own repositories. It concatenated repositories into a 42.9-megabyte stream and measured loss in bits per byte, where lower is better. Fern’s loss fell from 0.246 with a 32-kilobyte window to 0.155 with 16- and 23-megabyte windows. That is evidence that more context continued to help on this particular prediction task.
The same experiment also limits any claim that Fern predicts better than its peers. At a one-megabyte window, Kimi-K3 scored 0.140 while Fern scored 0.165, so Kimi-K3 had lower loss. The other models were measured only up to about one million tokens, near their advertised context limits. Fern’s distinction here is that its curve extends farther, not that it wins at equal context length. The reported windows are measured in bytes, so 16 or 23 megabytes should not be mistaken for 16 or 23 million tokens.
Retrieval Holds Up Better Than Reasoning Across Materials
Mirendil also evaluated Mirendil-Base, the base model before Fern 0.1’s post-training, on the RULER long-context benchmark. The setup used greedy decoding, turned thinking off, and required exact matches. Its five tasks included single-needle retrieval, multi-key retrieval, variable tracking, and multi-hop question answering. Single-needle retrieval scored 100 percent at every tested length from 32K to 10M tokens, showing that the model could retrieve a specified item from very long inputs under this benchmark’s conditions.
Performance was not equally stable across tasks. Multi-hop HotpotQA fell to 45 percent at 10M tokens, and variable-tracking scores shifted across context lengths. The sample count matters: each 10M-token cell used only 20 examples, compared with 100 at other lengths. Those results should therefore not be treated as a precise, stable estimate of performance at the extreme. Finding one fact and reliably combining several pieces of evidence are different kinds of work.
Coding Benchmarks Separate Capacity from Deliverability
Fern is intended not only to read repositories but also to support coding agents that run commands repeatedly until tests pass. The available evidence is much less encouraging on that kind of work. In Mirendil’s own comparison table, Fern 0.1 scored 6.1 percent on Terminal Bench 4.0, while Claude Opus 5.5 scored 66.4 percent. Mirendil characterizes Fern as mid-pack against open-weight models and well behind frontier models, although the supplied material does not include a complete set of scores that would allow every comparison to be checked independently.
This contrast is a reason not to equate seeing an entire repository with being more likely to deliver a working change. Long logs and code may reduce information loss caused by context truncation, but they do not automatically solve command selection, error diagnosis, plan revision, or tool use. For a task that requires repeated operations until tests pass, end-to-end success is closer to the measure that matters in delivery than the accuracy of a single retrieval. The evidence supports Fern’s long-context claim, but does not show that this advantage has become stronger end-to-end coding.
The Training Story Offers Clues, while Access Still Limits Judgment
Fern is built on Mirendil-Base, which the company says one researcher pretrained in three and a half months. Total compute spending was under $10 million, including experiments, agent token use, and data processing. Mirendil says AI agents wrote more than 99 percent of the code, while the researcher chose what to try and when to intervene. The training data came from GitHub, public code, webpages, and public datasets. The company says it used no distillation, synthetic data, or licensed data, and wrote the code from scratch in PyTorch and JAX.
This account describes the training path Mirendil has chosen to disclose, but it cannot by itself establish model quality, data coverage, or a cost advantage that others can reproduce. Fern 0.1 is the smallest of three planned models, and its parameter count is disclosed only as a range of 0.1 to 0.5 trillion. The exact count and number of active parameters are not public. Mirendil says pretraining is more than 80 percent complete for Base-Large and more than 20 percent complete for Base-XL.
For engineering teams, the practical choice is to treat Fern as a long-context candidate to evaluate by task, not as an assumed replacement for an existing coding model. If the workload is finding information in a large repository, reading training logs, or reviewing long agent traces, assess whether it reduces the cost of chunking, summarizing, and manually assembling context. If the goal is autonomous code changes that pass tests, measure end-to-end success and failure modes separately, and examine access costs and data boundaries. Hosted earl