Mirendil has released its first model. Fern 0.1, announced October 26, 2026 at 8:00 am PT in Introducing Fern, supports a context window of up to 10 million tokens, which the company says is about 23 MB of code or half a million lines at once. It is the post-trained follow-up to Mirendil-Base, the model that one researcher built in 3.5 months for under $10M, according to the company.
The launch is a good test of how to read a long-context claim. The headline number is a spec, and what matters is how well the model uses that window. This post lays out what Mirendil published, what the page does not contain, and what to ask before building on a 10M-token model.
TL;DR
| Question | Answer |
|---|---|
| What is Fern 0.1? | Mirendil's first model, Mirendil-Base after a short round of post-training |
| Context window | Up to 10M tokens (about 23 MB of code, per Mirendil) |
| Size | 0.1 to 0.5T parameters |
| Input | Text and code |
| Built for | Focused, high-volume agentic tasks |
| Access | Early-access request; listed as coming soon |
| Benchmark numbers in the announcement text | None readable; "more comprehensive long-context results are coming soon" |
| Larger models | Base-Large (0.5 to 2T) over 80% through pretraining; Base-XL (2 to 10T) over 20% |
What Mirendil says Fern is
Mirendil describes itself as "a frontier lab building systems that excel at AI R&D" and frames Fern as the first of three models. The page calls it the company's "most efficient model", aimed at the unglamorous work of anyone building AI: auditing training data, debugging a training run from its logs, and reading agent traces end to end.
The "Mirendil grove" table lists:
- Fern 0.1 (latest): base Mirendil-Base, 0.1 to 0.5T parameters, up to 10M context, text and code in, access coming soon.
- In pretraining, 80%+: a model on Mirendil-Base-Large, 0.5 to 2T parameters, "more capable, for harder and longer-running work."
- In pretraining, 20%+: a model on Mirendil-Base-XL, 2 to 10T parameters, "our most capable model, for the most demanding work."
Fields for context, input, intended use and access are blank for the two larger models. Mirendil says new Fern versions "ship frequently," so 0.1 should be read as a first checkpoint.
"Context is intelligence": the argument
The announcement makes a clear case for why context length matters. Capability grows with compute, and compute can go into parameters or into context. More parameters hold more static knowledge and support more sophisticated reasoning steps. A larger window lets a model use more task-specific information: its own past experience, more specifications and instructions, more documents and code, and more data directly.
Mirendil says Fern's architecture, training and serving can support 10M tokens at once, and cites its own scale comparisons: about half a million lines of code (a Megatron-LM-sized codebase), dozens to hundreds of complete agent traces, or days of an agent's work all in context together.
A long folded ribbon passing through a ring, illustrating a long-context window holding an entire codebase for a 10M token model
It also says it first shows that "more context helps even with next-token prediction," then runs "a basic test of effective access to the long context with a standard benchmark (RULER)." It promises more comprehensive long-context results soon. In the page text we could read, there are no values for either test: footnote 1 defines bits per byte as cross-entropy per byte so tokenizers can be compared fairly, and nothing numeric follows. If the numbers live in interactive charts, they were not extractable by our tools.
What the announcement does not give you
This is the part to keep in mind before sharing the 10M figure as a capability claim.
| Item | Status in the announcement text |
|---|---|
| Agentic benchmark names and scores | Not given; page says Fern was evaluated on agentic benchmarks |
| RULER score and context lengths tested | Not given |
| Comparison models | Not given |
| Bits-per-byte by context length | Not given |
| Pricing, API, rate limits | Not given; access coming soon |
| Architecture details (how 10M is supported) | Not given beyond "architecture, training and serving" |
| Independent evaluation | None that we found |
The last point is a reminder from the earlier Mirendil episode. Baseten's statement that Mirendil-Base-Large had the lowest bits per byte on private codebases was a vendor's own post with no published scores, as our claimed-versus-verified write-up detailed. The same discipline applies here.
Why long-context claims need a second look
A context window is a ceiling on input length, not a measure of how much the model can use. Developers have seen advertised windows far exceed effective ones. Earlier 10M-token announcements, including Pokee's 28B agentic model, prompted the same questions: does retrieval accuracy hold at the end of the window, does it degrade with distractors, and what does latency and memory cost at that length?
For Fern specifically, three things would turn the spec into evidence:
- Needle-style and multi-hop scores at 1M, 5M and 10M tokens, not just the maximum. RULER is a standard benchmark for this, and Mirendil says it ran it.
- Agent tasks where long context is the point. Debugging from logs, scanning a pretraining shard for duplicates and benchmark contamination, or explaining a full agent trace are Mirendil's own examples, and each can be scored against a retrieval-plus-small-window baseline.
- Serving cost. Attention and KV-cache memory at 10M tokens are heavy. Pricing and latency will say whether the window is practical or a demo. Our study of what a harness actually buys in tokens shows how much of agent cost is context re-reading, which cuts both ways here: fewer tool calls, but enormous prompts.
The use cases Mirendil names
Mirendil lists six uses, which are worth testing in a pilot:
- Larger repos. Work across codebases that do not fit smaller windows.
- Agentic coding. Run commands, read output and continue until tests pass.
- Research code. Specialised for training loops, data pipelines and evaluations.
- Debugging from logs. Work through long logs and stack traces to find where a run went wrong.
- Analysing full traces. Read an entire agent or training trace end to end and explain what happened.
- Auditing training data. Scan a whole pretraining shard for duplicates, benchmark contamination and junk.
The common thread is AI-R&D work, consistent with the company's goal of automating the research loop. For background on that thesis, see our explainer on recursive self-improvement and Jack Clark's 2027 forecast discussion, which mentions Mirendil.
What this means if you build with models
If you work on training pipelines or evals. The data-auditing and trace-reading uses are the most interesting, since they are tasks where retrieval struggles and where a long window could be a real advantage. Request early access and design a test with known planted duplicates or contamination so you can measure recall.
If you build coding agents. Treat 10M tokens as an option, not a default. Retrieval and indexing tools remain cheaper for most tasks, as our piece on a 2B local code-search agent that cut Claude Code tokens by 34 percent illustrates. The question for Fern is where it beats that approach.
If you track the open versus closed gap. Mirendil says nothing yet about open weights, licensing or API pricing. Our overview of the open-weight gap is a useful frame when numbers do appear.
How Fern fits the Mirendil timeline
Mirendil's news page lists four posts, which makes the sequence easy to follow: the lab's founding announcement, a post about scaling self-accelerating AI with Google, the October 21 post on pretraining at scale without a pretraining team, and now Fern. In five days the story moved from "we trained a base model cheaply" to "here is a post-trained model with a headline spec." That pace fits the company's stated bet that AI doing AI research compresses cycles, and it is also why the verification gap matters: each step is announced before outsiders can test the previous one.
The practical consequence for a reader deciding whether to spend time on it is simple. Fern 0.1 is a checkpoint from a short round of post-training, so its agentic scores, whenever they arrive, will describe an early version. Larger Mirendil models are still in pretraining, so conclusions about the family should wait. Early-access users should ask Mirendil three concrete questions: which context lengths were tested and with what accuracy, what the per-request cost and latency are at 1M and 10M tokens, and whether outputs and prompts are retained for training. Those answers, more than the headline window, decide whether a pilot is worth the engineering time.
What to watch next
- Mirendil's promised long-context results and any benchmark tables for Fern 0.1.
- Whether Baseten or another partner serves Fern, and at what price.
- Third-party RULER-style tests at the full 10M length.
- Progress on Base-Large and Base-XL, and what context those models support.
- Whether new Fern versions change the architecture claims.
Bottom line
Fern 0.1 is a real model release from a lab that has been unusually open about its process, and a 10M-token window is a meaningful engineering claim. What is published today is a spec sheet and a thesis, with no numbers we could read. Until Mirendil's results or independent tests appear, the sensible stance is interest without commitment: sign up for access, plan a measured pilot, and avoid repeating "10M tokens" as if it were a benchmark score. We will update this post when results land.
Details reflect Mirendil's October 26, 2026 announcement and may change; Mirendil says new versions ship frequently.
Related reading
- Mirendil-Base: one researcher, 3.5 months, under $10M, claimed vs verified
- Pokee-Isaac 28B: a 10M-token agentic model
- What is recursive self-improvement?
- Jack Clark on RSI by 2027 (Import AI 476)
- What a harness buys in tokens
- ColGrep: a 2B local code-search agent
- Open-weight models and the frontier gap
- Official: Mirendil
