MiMo tried to blog about itself. The turn died truncated.
:30007, was asked to rewrite its own serving post as a simpler companion with new diagrams. It chose to write each large artifact in a single completion. The lane's configured output cap is 16,384 tokens; the biggest of those completions came back at 15,981 tokens after 539 seconds, which is 29.6 tok/s, the model's own rated decode speed. Each time a completion hit the cap, Hermes asked for a continuation, four times at most, then ended the turn as an error. Both user turns ended that way, at 1,631 s and 2,266 s. A 44,153-byte draft survived on disk and passed the local validator. Nothing was uploaded, and the draft's canonical URL still returns 404. The parent post's decode numbers were not remeasured and stand.
What the session actually did
Session 20260922_182940_78692c, September 22, 2026, CDT. Token totals are the main-task usage row; the side question and approval calls are counted separately. The right-hand panel is the finding: single completions filled the lane's output cap, and the harness ran out of continuations.
The ask
At 6:29 PM CDT I opened a desktop chat on mimo26-pro and asked it to duplicate the last blog entry, rewritten and simplified, with new diagrams, and to take its time. The target was the live page Fourteen boots, one streamer bug, and a model that finally talks, attached as context. A mid-turn steer clarified that I wanted a new entry, not an edit of the original. Hermes stored the chat as custom[mimo26] with reasoning enabled at effort high, while the profile config carries a per-model override of low for mimo26-pro. I did not probe the server to learn which one the lane honoured, and it matters less than it looks: the completions that hit the cap were mostly tool-call arguments, not thinking.
The model is not slow to respond in general. A side question sent with /btw while the main turn was still running came back in 27.5 seconds with 295 output tokens and a clean finish_reason=stop. The long job is what died.
The clock
The gateway log is the receipt here, not the model's own account of itself.
| Turn | Gateway result | What the log shows |
|---|---|---|
| 6:29 PM, first ask | 6:56 PM, status=error, duration 1,631.3 s, failure_reason=truncated |
The turn spent itself loading skills, reading the live post and homepage, and pulling discovery files. The one main-task API line I can match is call #6: 85,186 in, 4,480 out, 1,241 s of latency, which is 3.6 tok/s and well below the lane's decode rate; the log does not say what filled that window. Calls 1 through 5 of this turn are not matchable in the retained log and I am not reconstructing them. |
| 7:35 PM, the same ask again (the gateway accepted 209 characters; the stored message with the attached page is 15,528) | 8:13 PM, status=error, duration 2,266.3 s, same cause |
Eight API calls, itemised below. The turn died about 70 seconds after the last tool result and before any upload. |
8:30 PM, continue |
8:31 PM, status=interrupted, 18.2 s, interrupted_during_api_call |
The client aborted the stream (tcp_force_closed=1). The chat row that followed is the gateway's stub, not a model paragraph. |
Turn 2's eight calls, all mimo26-pro:
| # | Latency | In | Out | What came back |
|---|---|---|---|---|
| 1 | 9.7 s | 96,762 | 319 | Started building the post in an execute_code cell. |
| 2 | 7.8 s | 98,054 | 216 | Read the homepage card block for format. |
| 3 | 539.0 s | 98,869 | 15,981 | Wrote all three SVGs in one cell, 403 tokens under the 16,384 cap. XML parse failed on a named entity inside SVG text. |
| 4 | 121.1 s | 115,437 | 1,259 | Stripped the named entities; parse passed. |
| 5 | 171.7 s | 116,818 | 3,254 | Patched three labels it had already judged wrong: a delta, a boot-count line, a double-counted memory figure. |
| 6 | 628.3 s | 120,293 | 8,928 | Wrote the 25,765-byte HTML template with write_file, then spliced the SVGs in. 14.2 tok/s end to end, including the prefill of 120K tokens. |
| 7 | 24.2 s | 129,336 | 558 | Local validator rc 0 on 44,100 characters (44,153 bytes on disk). |
| 8 | 31.8 s | 130,078 | 977 | Its own rough geometry check flagged captions outside the viewBox on all three diagrams. No browser QA followed. No deploy. |
Context climbed from 96,762 to 130,078 tokens across those eight calls, and the main-task usage row for the session is 1,291,271 input tokens over 14 calls with cache_read_tokens = 0. Whether the vLLM lane really re-prefilled the whole prompt each time, or simply does not report prefix-cache hits through the usage object, I cannot tell from the log. Either way, Hermes saw no reuse it could count.
What is on disk
The unpublished file is titled "A 1-terabyte model on one box: MiMo-V2.6-Pro, explained." It has three inline SVGs, a canonical URL of gb300-mimo-v26-pro-explained.html, and no noindex. I am not publishing it. It never had visual QA, and its second heading says "eleven wasted boots" while the parent's title counts fourteen. The parent body does say every full-Pro boot from v3 through v13 carried --load-format runai_streamer, which is eleven, so the heading counts the flag rather than the boots. A reader of the rewrite alone would not know that.
The memory diagram is a fair regrouping rather than an invention. The parent lists the checkpoint as experts 494.9 GiB, non-expert layers 24.6, embed/head 3.5, drafter 2.3, ViT 1.4, audio 0.5, which sums to 527.2 GiB against a stated 527. The draft's "28.1 GiB" is 24.6 + 3.5 and its "4.2 GiB" is 2.3 + 1.4 + 0.5. Same parts, coarser bins. I checked the addition; I did not remeasure the checkpoint.
The useful recovery in the session is narrow but real. The model hit the named-entity SVG pitfall the publishing skill warns about, recognised it from the traceback, fixed it in place, and got the validator green. Its geometry pass then reported negative x on three captions, including "The speed of this model is the speed of" and the hotsplit summary pill, and labelled its own numbers a rough estimate. The next completion was the one the harness discarded.
One label that is not a quote
The loader-bug diagram is meant to show the garbage the streamer produced. The parent post records two different boots:
- One returned
schGoodzial'), thenMatcher, then识别驗Nit…. - Boot v11 returned
暖婤Ք0Ք0….
The SVG label reads schGoodzial') · 暖婤Ք· 识别驗Nit. It drops Matcher, drops the 0Ք0, and splices the two samples into one string. The draft's lead promises every figure is carried unchanged from the parent, and this label is the one place I checked where that promise fails. Small, but it is exactly what a "simplified rewrite" test exists to catch: asked to compress, the model compressed a quotation.
Why MiMo and not the others
The fair question is why this test fell over on MiMo when Opus, Fable, Grok and Astra have all published posts through the same skill on the same harness this month. The cap is not the answer on its own; every model in this profile runs under the same 16,384-token output limit. The difference is how close each one gets to it.
The caveat first: agent.log on this profile retains only the current day, so the table below is September 22 traffic, roughly 15:18 to 21:03 CDT, not a month. It is the same harness, the same cap, and the same class of job, and Opus and Fable wrote the parent post and this one, diagrams included, inside that window.
| Model | API calls | Largest single completion | Calls over 8K out | Calls over 15K out |
|---|---|---|---|---|
| claude-opus-5-5 | 273 | 8,397 | 1 | 0 |
| claude-fable-5-1 | 247 | 11,666 | 3 | 0 |
| grok-4.7 | 97 | 8,592 | 4 | 0 |
| gpt-6-astra | 98 | 1,234 | 0 | 0 |
| mimo26-pro | 44 | 15,981 | 2 | 1 |
Three things separate MiMo, and they compound.
Completion size. The cloud models emit one file per write_file, then patch. Nothing they wrote today exceeded 11.7K tokens in a single call, and most calls are under a thousand. MiMo put three SVGs into one execute_code cell and landed 403 tokens under the ceiling. Same cap for everyone; only MiMo filled it.
Reasoning draws from the same budget. Turn 1 did not truncate on a big artifact at all. Its truncations landed on small tool-call rounds, skill_view and search_files, with stored reasoning up to 14,846 characters. Call #6 of that turn reported 4,480 visible output tokens over 1,241 s; at the lane's 29.6 tok/s that window is room for about 36,700 generated tokens, so most of what the model produced was thinking that never appeared in the out column. The session row records reasoning effort high, while the profile config carries a per-model override of low for mimo26-pro, and the log reads as though the override did not reach the lane. Hermes's truncation path even has a special case for this: a thinking-only truncation switches reasoning off for the retry, because leaving it on re-burns the budget. The cloud models with adaptive thinking do not spend tens of thousands of tokens deciding to load a skill.
Speed removes the slack. A cap-sized completion at 29.6 tok/s is about nine minutes, and four continuations of that is 37 minutes, most of the 1,800-second gateway timeout. Fable can make the same planning error at several times the decode rate and still finish inside the window. MiMo cannot recover from it.
So the honest reading is not that MiMo is unable to do the task. It is that MiMo's habits, one large artifact per call and long thinking per step, sit close to a ceiling the other models' habits stay well under, and its decode speed turns each miss into a timeout instead of a delay. Two cheap checks before the next run: confirm that reasoning_overrides: mimo26-pro: low actually reaches the lane, and see whether a one-line system-prompt nudge, one artifact per tool call, changes its largest completion.
Conclusions
1. The proximate cause is a 16,384-token output cap meeting a one-completion-per-artifact habit. The cap is lane configuration, not a model limit; the lane advertises 262K of context. Call #3 wrote three SVGs in a single execute_code cell and landed at 15,981 tokens, effectively at the ceiling. At the model's measured decode rate of about 30 tok/s, a cap-sized completion takes nine minutes, and Hermes is willing to ask for four continuations before it gives up. Four nine-minute continuations plus the tool loop before them is most of a 38-minute turn. The model produced its work at the speed the parent post says it would; the job was shaped so that every completion was the largest allowed. Turn 1 hit the same ceiling a different way, with long reasoning on small tool-call rounds; the reasoning shares the output budget, and the session ran at effort high despite a configured override of low.
2. Hermes did what its truncation code says it does, and the result is a partially successful turn reported as a failure. Tool effects are real the moment they run, so the SVGs, the template, and the validator pass all landed on disk. But the turn's final response never arrived, the gateway reported status=error, and a later continue started a fresh API call over 130K tokens of context instead of resuming the loop. From the chat window the work looked lost. It was not lost; it was unreported. That gap between "the artifacts exist" and "the turn succeeded" is worth knowing before judging any local model on a long agentic task.
3. The model's share is the shape of the work, plus one fidelity slip. Nothing forced MiMo to emit three diagrams in one cell. One write_file per SVG would have kept every completion under a few thousand tokens, and the same turn would have finished with room to spare. That is a planning behaviour, and it is the thing I most want a local agent model to get right. The spliced garbage label is a separate, smaller matter: a rewrite that claims to carry figures unchanged should not merge two quotations into one.
4. This is not evidence about serving speed, and it is not evidence that MiMo cannot write. The parent post's numbers stand untouched. The draft's prose is competent, the memory arithmetic is right, and the entity fix was the correct fix. What failed is the publish, which the skill defines as browser-measured geometry, visual QA, chmod 644, a homepage card, sitemap, feed, llms.txt, a topic link, and a live GET. None of that ran. A green validator on a local file is the midpoint of the job.
5. Next time, I change the harness before I change the model. Split the publish into a draft-and-validate turn and a separate upload-and-verify turn. Tell the model to write one artifact per tool call. Leave the 16,384 cap alone, because doubling it only doubles the length of the completion that eventually hits it; at 30 tok/s a 32K completion is an 18-minute single request, which is worse. And find out whether the lane reports prefix-cache hits at all, because 1.29 million input tokens over 14 calls is either a real re-prefill cost or a reporting gap, and I want to know which before the next long run.