What happened
Mirendil published an announcement for Fern on October 26, 2026, calling it the company’s first model. Fern 0.1 is described as having been pretrained from scratch and then finished with a short round of post-training. Mirendil says new versions will ship frequently, while the current access status is “Coming soon”; the announcement offers an early-access request rather than a generally available product.
The initial model is listed as Fern 0.1, based on Mirendil-Base, with a stated size range of 0.1–0.5 trillion parameters. It accepts text and code and is intended for “focused, high-volume agentic tasks.” Mirendil also describes two larger models that remain in pretraining: Mirendil-Base-Large, at 0.5–2 trillion parameters, and Mirendil-Base-XL, at 2–10 trillion parameters. The company does not state context windows, inputs, access terms, pricing, or workload claims for those larger variants.
The central claim is a context window of up to 10 million tokens. Mirendil says its architecture, training, and serving stack can support that length, and estimates the capacity as roughly 23 MB of code or about half a million lines of code at one time. The company compares that scale with the Megatron-LM library, dozens to hundreds of complete agent traces, or days of an agent’s work. Its argument is that parameter count supplies more static knowledge, whereas a larger context can expose a model to more task-specific material: specifications, instructions, documents, code, data, and prior work traces.
Mirendil presents Fern as useful for work across larger repositories, command-running coding loops that continue until tests pass, research code for model training and evaluation, debugging from long logs and stack traces, full-trace analysis, and pretraining-data audits for duplicates, benchmark contamination, and junk. The announcement says it first examines whether added context helps next-token prediction, then uses the RULER benchmark as a basic effective-long-context test. It says more comprehensive long-context results are forthcoming. No benchmark scores, throughput figures, latency, pricing, API specification, or public availability date are provided in the supplied announcement.
What the archive adds
We have not covered this before; it opens a new thread.
Trend signal
No supplied New Runtime pattern is a sufficiently direct fit. Fern’s claim concerns model context capacity; the announcement does not establish a durable change in agent harnesses, protocols, verification, or runtime boundaries.
Why it matters
For teams building agents, the claimed context length points at a different operating model from aggressively narrowing every task to small retrieved excerpts. A system that can reliably retain a large repository, extensive logs, or many prior traces may reduce the handoffs needed to reconstruct state across a long-running job. That could be valuable in debugging, training-data inspection, and codebase-wide analysis, where omitted context is often the source of incorrect conclusions.
This matters particularly where an agent’s history is itself evidence. A debugging agent may need the sequence of commands, outputs, configuration changes, and test failures rather than only a handful of retrieved fragments. Similarly, an audit workflow may need to compare material across a large shard without repeatedly selecting a new subset. Those are plausible applications, but they are workflow hypotheses made possible by the announced capacity, not outcomes the source demonstrates.
But a large window is not automatically useful context. Teams need a model that can locate relevant evidence, follow instructions amid distractors, and return a verifiable result at an acceptable cost and latency. Fern is therefore notable as an announced capability direction, not yet as a demonstrated replacement for retrieval, task decomposition, or review workflows. Even if the maximum window is available, builders will still need boundaries on what the agent can act on and checks that its conclusions are grounded in the supplied material.
Limits and uncertainty
The source is Mirendil’s own product announcement, and the supplied material contains no independent testing. It does not provide the actual RULER result or other benchmark scores, comparisons with competing systems, details of the evaluation setup, pricing, rate limits, latency, throughput, hardware requirements, or API behavior. “Up to 10 million tokens” does not establish how well the model attends to material throughout that range, especially on realistic mixed code, logs, and documents.
The announcement also does not specify when early access will begin, who will qualify, or whether the listed parameter ranges represent released checkpoints rather than planned model classes. It does not say how input size affects output quality, response time, or cost. The listed use cases are company descriptions, not reported deployments or measured customer results. Until users can test the model on full working repositories, traces, and logs, the effective usable context remains unknown.
Skill to build now
Create a repeatable long-context evaluation pack from work your team already does: one large repository task, one production-log investigation, and one multi-step agent trace. For each, define the evidence the system must cite, a concrete completion test, and the time and cost budget. This will let you compare a very-long-context model against retrieval and task decomposition when Fern or similar systems become accessible, rather than treating window size as a proxy for useful performance.
Include distractor material and an explicit check for citations to the right files, log lines, or trace steps. Run the same pack with a retrieval-based workflow and a decomposed workflow. The comparison should measure not only whether an answer sounds complete, but whether it identifies the evidence, reaches the correct result, and stays within an operating budget.
Reader takeaway
Fern is an early-access announcement for a model that claims up to 10 million tokens of context and targets agentic code, trace, and data-analysis work. The claim is potentially consequential for large-state workflows, but builders should wait for access, measured effective-context performance, and operating costs before changing architecture decisions.
Open question
Can Fern retrieve and reason over the right evidence across a 10-million-token real-world workload at a cost and latency that make it preferable to retrieval and decomposition?