Every new command-line session started the same way this week, with a line I could not explain:<\/p>\n
\u26a0 Auxiliary title generation failed: HTTP 400: This model always engages in\nthinking and cannot be disabled; please use low, high, or max<\/code><\/pre>\nIt appeared once per session, usually a second after my first message. Nothing I asked for failed. No answer was cut short. The agent kept working \u2014 and still the warning came back on the next session, and the next.<\/p>\n
This is the trace of what was actually happening, the config line responsible, and the fix. It took one line to fix and about twenty minutes to prove, and most of that was the step I would have skipped a year ago: asking the provider directly instead of reasoning about it.<\/p>\n
What the warning was really about<\/h2>\n
Nothing in the main conversation. \"Auxiliary\" is the collective name for an agent's side-calls: the small, cheap model invocations a harness makes for housekeeping \u2014 summarising a long conversation, describing an image, naming a session. The warning came from the naming one.<\/p>\n
When a session gets its name, two things happen. First an instant, deterministic title is written from the first line of what I typed \u2014 that never fails, because it involves no model at all. Then a background thread asks a small model for a better, 3-to-7-word version. That second call is what was failing, and its failure was being reported to me in the chat as a status line.<\/p>\n
The blast radius, measured honestly: the session kept the instant title, and only the polished upgrade was lost.<\/strong> No turn was damaged, no context was lost, nothing was silently half-done. The warning was real, and it was cosmetic.<\/p>\nStep one: which model was it even calling?<\/h2>\n
My config did not pin a model for that task, and an unpinned auxiliary task means auto<\/code> \u2014 and auto<\/code> means the session's main model<\/em>. One grep on the agent log showed the whole route:<\/p>\nAuxiliary auto-detect: using main provider zai (glm-5.3-flash)\nAuxiliary title_generation: using zai (glm-5.3-flash) at https:\/\/api.z.ai\/api\/paas\/v4\/\nTitle generation failed: Error code: 400 - {'error': {'code': '1210', 'message':\n 'This model always engages in thinking and cannot be disabled; please use low, high, or max'}}<\/code><\/pre>\nThree lines, no speculation required. My sessions were running on a GLM-5.3-Flash main model, so the naming call inherited it. And the crucial detail: the main conversation on that same model worked perfectly.<\/strong> Whatever was wrong was in how the side-call was shaped, not in the model being unavailable \u2014 which ruled out keys, quota, and outages before I spent a minute on them.<\/p>\nStep two: read the call<\/h2>\n
The title generator asks for thinking off<\/strong>, deliberately. A session title is a machine-readable JSON answer capped at 64 tokens; on a thinking model the internal reasoning tokens would eat that budget before the JSON ever landed, and an earlier bug had already stored a stray ```json<\/code> fence as a session name because of exactly that.<\/p>\nSo the call says: no thinking. And the provider profile \u2014 the small piece of code that translates a harness's generic \"reasoning off\" into a specific vendor's dialect \u2014 turned that into extra_body.thinking = {\"type\": \"disabled\"}<\/code> for any GLM 4.5 or newer.<\/p>\nThe provider did not agree. For the GLM-5.3 family, thinking is not a switch. It is an effort level<\/strong>: low<\/code>, high<\/code>, or max<\/code>. Asking for it to be off is not a valid request, and the API says so in the clearest possible terms \u2014 its own error message tells you which values it accepts.<\/p>\nStep three: ask the API instead of guessing<\/h2>\n
I stopped reading code at that point and sent five tiny requests straight to the provider (a handful of tokens each, a fraction of a cent) to see which combinations are actually accepted:<\/p>\n
\nglm-5.3-flash<\/code>, thinking disabled \u2192 400, code 1210<\/strong><\/li>\nglm-5.3-flash<\/code>, thinking enabled \u2192 200<\/li>\nglm-5.3-flash<\/code>, reasoning_effort: low<\/code> \u2192 200<\/li>\nglm-4.5-flash<\/code>, thinking disabled \u2192 200<\/li>\ndeepseek-flash<\/code>, thinking disabled \u2192 200<\/li>\n<\/ul>\nThat single experiment did three jobs at once. It reproduced the error on demand, it proved the model itself was fine (two of the three GLM requests succeeded), and it produced a list of candidate targets for the fix instead of a hunch. The wider catalogue agrees: glm-5.3-flash<\/code> advertises reasoning as an effort-only option, while glm-4.5-flash<\/code> advertises a plain toggle.<\/p>\nThe fix: stop letting a side-call inherit a session setting<\/h2>\n
The title task does not need my session's model. It needs any<\/em> model that will honour \"no thinking\". So I pinned it:<\/p>\nhermes config set auxiliary.title_generation.provider zai\nhermes config set auxiliary.title_generation.model glm-4.5-flash<\/code><\/pre>\nAn explicit per-task provider is resolved before any auto-detection, so this is deterministic \u2014 no launch flag can re-break it. I confirmed it through the real code path rather than a config dump, by calling the production title function with the same input that had failed three times:<\/p>\n
Auxiliary title_generation: using zai (glm-4.5-flash) at https:\/\/api.z.ai\/api\/paas\/v4\/\nPOST https:\/\/api.z.ai\/api\/paas\/v4\/chat\/completions \"HTTP\/1.1 200 OK\"\nTITLE: 'Explain percentile calculation block'<\/code><\/pre>\nOne request, one 200, a sensible title, no retry. (deepseek-flash<\/code> also passes the thinking-off test, but it rejects the JSON-schema response format and needs a second attempt without it \u2014 a wasted round trip on every session, so it lost.) If you would rather not make the call at all, auxiliary.title_generation.enabled false<\/code> keeps the deterministic titles and spends nothing.<\/p>\nThe part worth keeping<\/h2>\n
Two things generalise beyond this bug.<\/p>\n
First: \"auto\" is an inheritance rule, not a safety net.<\/strong> Every auxiliary task that is left unpinned follows whatever model that session happens to run on \u2014 including a model you picked for one session with a launch flag. The moment a provider ships a family where one member has different capabilities than its siblings, that inheritance carries the difference straight into side-calls you never think about. Pinning the cheap, latency-critical ones costs one line each and removes an entire class of surprise.<\/p>\nSecond: an HTTP error with a provider's own JSON body is not a routing failure \u2014 it is the model rejecting the shape of your request.<\/strong> That distinction decides where you look. And the cheapest possible experiment sits right there: five requests, a few seconds, one provider's own words. I had the answer before I had a theory.<\/p>\nThere is an upstream wrinkle worth naming: the provider profile currently treats the whole GLM 4.5-and-later family as thinking-toggleable, and the 5.3 family is effort-only. Anything asking that family to turn thinking off will get the same 400 \u2014 the config pin is the workaround, not the cure.<\/p>\n
The warning was harmless. The habit of verifying it was not.<\/p>","summary":"A side-call that names each agent session was failing with HTTP 400 code 1210 on every new CLI session. The log trace, the provider translation behind it, the API probes that settled it, and the one-line config fix.","tags":["ai","hermes","agents","configuration","api"],"image":"\/user\/pages\/02.blog\/2026-09-16-auxiliary-title-generation-400\/cover.avif"},{"title":"One Gateway, Three Bots: Multiplexing My Hermes Profiles \u2014 and the state.db Bug I Found Doing It","date_published":"2026-09-13T15:00:00+03:00","id":"https:\/\/docs.agenteum.top\/blog\/2026-09-13-one-gateway-three-bots-state-db-bug","url":"https:\/\/docs.agenteum.top\/blog\/2026-09-13-one-gateway-three-bots-state-db-bug","content_html":"
Until this morning, my three Hermes bot profiles ran as three separate gateways: three processes, three systemd units, three copies of the same interpreter doing largely the same work. Two of those profiles are small, low-traffic companion bots \u2014 which made the arithmetic hard to defend. Every extra gateway was one more process to update, one more unit file to babysit, one more log to check after every hermes update<\/code>.<\/p>\nSo I merged them. One gateway process now serves all three profiles \u2014 the mode Hermes calls multiplexing<\/a>. The migration itself was five commands and about a minute.<\/p>\nThen it broke.<\/p>\n
Forty seconds after the restart, one of the bots started answering with short error notices instead of replies. It took most of the morning to understand why \u2014 and the answer turned out to be a real database bug, already reported upstream, with a fix in flight. Both halves of that sentence matter, so here is the whole story.<\/p>\n
Why multiplex at all<\/h2>\n
The honest motivation is resource arithmetic. Three bots with the same job description do not need three Python processes, each carrying its own interpreter and heap. In multiplex mode a single gateway process serves every profile under profiles\/<\/code> \u2014 the secondaries keep their own bot token, their own .env<\/code>, their own sessions and their own state.db<\/code>; what they give up is a private process.<\/p>\nThe trade-off is worth stating plainly, because it decides whether multiplex is right for you:<\/p>\n
\n- What you gain:<\/strong> one process, one unit, one log stream for every bot \u2014 and the cron scheduler ticks every served profile's job store in a single pass.<\/li>\n
- What you give up:<\/strong> crash isolation. One restart reconnects every bot. If you want hard separation between profiles, keep one gateway per profile.<\/li>\n<\/ul>\n
I host two small companion bots for other people, so shared fate is an acceptable price. And as the migration log later confirmed, the profiles stay properly isolated: namespaced sessions, per-profile secrets, per-profile databases. Profiles created after<\/em> the migration are picked up by the running gateway automatically.<\/p>\nThe migration, in five commands<\/h2>\n
The procedure is documented, and the order in it is load-bearing. The secondary gateways must stop before<\/strong> the flag takes effect, so the multiplexer never long-polls a bot token that another process still owns:<\/p>\ncp ~\/.hermes\/config.yaml ~\/.hermes\/backups\/config.yaml.pre-multiplex-$(date +%Y%m%d)\nsudo systemctl disable --now hermes-gateway-alpha.service hermes-gateway-beta.service\nsudo mv \/etc\/systemd\/system\/hermes-gateway-alpha.service ~\/.hermes\/backups\/ # and the beta unit\nsudo systemctl daemon-reload\nhermes config set gateway.multiplex_profiles true\nsudo systemctl restart hermes-gateway.service<\/code><\/pre>\nTwo details worth keeping: disable<\/code> matters as much as --now<\/code> \u2014 an enabled unit comes back at boot and fights the multiplexer for the same token \u2014 and I moved<\/em> the unit files instead of deleting them, which makes rollback a rename.<\/p>\nThe proof showed up in the log within a minute:<\/p>\n
\u2713 telegram connected (profile: alpha)\n\u2713 telegram connected (profile: beta)\nGateway running with 3 platform(s)\nCron scheduler will tick 3 profile(s) under multiplex: ['default', 'alpha', 'beta']<\/code><\/pre>\nThat is the whole migration. It works, exactly as advertised.<\/p>\n
Forty seconds later<\/h2>\n
The bots' replies became short error notices while the log filled with this:<\/p>\n
FATAL: a live process holds a deleted state.db-wal or state.db-shm inode\nwhile the path names a different (or missing) generation.<\/code><\/pre>\nPlain-language translation. Hermes keeps sessions in a SQLite database in WAL mode \u2014 the write-ahead log<\/a> journaling scheme, where every database is accompanied by two sidecar files: a log that buffers recent commits and a shared-memory index. If those sidecars disappear while a live process still holds them open, that process sits on an ambiguous, split view of the database \u2014 the exact class of situation that ends in corrupt pages. So Hermes ships a guard: refuse to write, refuse to open a second WAL, and say why.<\/strong> The agent could still compose a reply; it just could not persist the session, so the turn failed. Failing closed is a feature, and it is the reason this story has no corruption in it.<\/p>\nA restart cleared it \u2014 the guard is deliberately sticky for the life of a process, so the fix is \"stop the holder, reopen\". But within the hour it came back. Twice. After a hermes status<\/code> command in one case, and around the top of the hour when cron jobs fired in the other. A fluke would not be that punctual.<\/p>\nWhat the forensics found<\/h2>\n
Three tools cracked it, and all three are boring.<\/p>\n
lsof +L1<\/code><\/strong> lists open files that no longer have a name in the filesystem. The deleted -wal<\/code> and -shm<\/code> were held open by my own gateway process<\/em>. Nobody else \u2014 which instantly ruled out the usual suspects (a second writer, a rogue daemon) and pointed at a race instead of a rogue.<\/p>\nA capture folder.<\/strong> Hermes had quietly done something clever: before settling the failure, it captured the doomed WAL generation into a folder beside the database \u2014 state.db.retired-wal-<timestamp>-<pid>\/<\/code> \u2014 with a manifest recording sizes, inode identities and checksums. The first capture's WAL was 0 bytes<\/strong>: nothing to lose. The second held about 4 MB of committed frames<\/strong> from the working window \u2014 preserved, not lost. The guard was protecting data, not just refusing to work.<\/p>\nLog timestamps.<\/strong> Lining up the two failures against everything else the box was doing produced the pattern: both followed a short-lived Hermes process \u2014 a status command, cron workers starting. One long-lived writer plus one short-lived reader\/writer, sharing a WAL database.<\/p>\nThe bug was not mine<\/h2>\n
I went looking for that signature upstream and found the exact case, reported by other users the same day: issue #109687<\/a>, priority P0 \u2014 a single plain CLI invocation orphans the live gateway's state.db WAL generation<\/em>. A maintainer reproduced it within hours; a fix, PR #109734<\/a>, is in flight.<\/p>\nThe mechanism, as the issue's analysis describes it: a helper that hardens file permissions walks the database and its sidecars with plain file descriptors \u2014 open, fchmod<\/code>, close. Closing those descriptors cancels the process's own SQLite advisory locks. SQLite coordinates the \"last connection\" rule through those locks, so once they are gone, the next short-lived process to close the database believes it is the last one \u2014 and removes a WAL that a live gateway still holds open.<\/p>\nTwo things are worth noting about that. It has nothing to do with multiplexing: any WAL-mode state.db<\/code> with two processes on it was exposed, and the migration merely put me in the room the minute it happened. And it got caught by a custom<\/em> guard, not by SQLite: my library version is outside the known WAL-reset vulnerability set, which is exactly why the guard exists as a second line of defence.<\/p>\nWhat I did about it<\/h2>\n
The fix is not merged yet, and the triggers are things I do every day anyway \u2014 CLI commands, cron jobs, updates. So I took the containment documented in the same issue: leave WAL mode until the fix ships.<\/p>\n
The sequence, run with the gateway stopped (the switch needs exclusive access, and stopping also forces a full checkpoint first):<\/p>\n
\n- switch every live database to
journal_mode=delete<\/code> \u2014 a small script that refuses to run while a gateway is alive and prints, per file, the before \u2192 after mode plus an integrity check;<\/li>\n- make it stick in config \u2014
hermes config set database.journal_mode delete<\/code>, once for the default profile and once per served profile, so the next open does not flip the files back to WAL;<\/li>\n- start the gateway and watch the first replies.<\/li>\n<\/ol>\n
Why it works is almost embarrassingly simple: with no WAL sidecars there is nothing to orphan. The cost is WAL's write concurrency \u2014 writes take a brief exclusive lock instead \u2014 and at the traffic of three chat bots and a handful of cron jobs, that is invisible. It is also reversible: when the fix ships, the same procedure with journal_mode=wal<\/code> goes back.<\/p>\nSixteen databases: all switched, all integrity checks clean. The first bot reply landed normally, and the cron schedule ran that hour like nothing had happened.<\/p>\n
The part worth keeping<\/h2>\n
Four lessons, in descending order of usefulness.<\/p>\n
Failing closed is a feature.<\/strong> The guard did not try to be clever and keep writing into a split view. It stopped, captured what could still be captured, and said exactly what was wrong. That converted silent data loss into a loud outage with preserved data \u2014 and loud outages are a much better failure mode, because you can fix them before the quiet version ruins a week. (It is the same principle as Nothing Fails Loudly<\/a> \u2014 except this time the quiet failure was upstream's, and it did not stay quiet for long.)<\/p>\nThe tools that solved it are boring.<\/strong> An lsof<\/code> flag, a manifest file, log timestamps. No profiler, no debugger build. When a system fails weirdly, the first question is not \"what is broken\" but \"what is actually<\/em> happening\" \u2014 and the answer usually fits in three terminal commands.<\/p>\nNever delete a WAL by hand.<\/strong> The error message says it plainly, and now I understand why: until a checkpoint folds its frames into the database, that sidecar file is the only<\/em> copy of those commits. It looks like scratch space. It is not.<\/p>\nWhen you cannot prevent a class of failure, instrument it.<\/strong> I left a small passive watchdog watching the sidecar files, logging any change with a process snapshot. It cannot stop the bug \u2014 but it means the next<\/em> time anything eats a journal file, I will know within seconds instead of noticing it through a confused person.<\/p>\nWhere it stands<\/h2>\n
The fix PR is pending. When it merges I will stop the gateway, update, and decide whether to move back to WAL \u2014 for now the deleted-journal mode stays, because it makes this particular failure impossible while costing me nothing measurable.<\/p>\n
And the migration itself? Still a win. One process, three bots, three isolated profiles, one place to look. The five commands were the easy part; the morning was the invoice for learning what was living under the floorboards. For a system that talks to people while I sleep, that is a trade I will make every time.<\/p>\n
If you run several profiles under one gateway \u2014 or are thinking about it \u2014 the multiplex guide<\/a> is accurate, and the bug above is already on the project's radar. Migrate anyway. Just read the error messages when the floor creaks.<\/p>\n
","summary":"I merged three Hermes gateways into a single multiplexed process this morning \u2014 and forty seconds later my bots stopped being able to write to their state.db. The forensics, the upstream bug, and the containment that fixed it.","tags":["ai","hermes","sqlite","infrastructure"],"image":"\/user\/pages\/02.blog\/2026-09-13-one-gateway-three-bots-state-db-bug\/cover.avif"},{"title":"DeepSeek Flash at 250 Tokens per Second","date_published":"2026-09-12T15:00:00+03:00","id":"https:\/\/docs.agenteum.top\/blog\/2026-09-12-deepseek-flash-250-tokens-per-second","url":"https:\/\/docs.agenteum.top\/blog\/2026-09-12-deepseek-flash-250-tokens-per-second","content_html":"Yesterday \u2014 11 September 2026 \u2014 one of my long generations came back at roughly 250 tokens per second<\/strong>. Not a spec sheet and not a vendor benchmark: one run, on my own account, with the rate visible in the client. It was fast enough that I stopped and checked the number twice.<\/p>\nHere is what a rate like that actually means.<\/p>\n
What 250 tokens per second buys you<\/h2>\n
The arithmetic is simple: 15,000 tokens a minute<\/strong>, or roughly 900,000 tokens an hour<\/strong> of continuous output. In practice, a generation ends while you are still reading the prompt:<\/p>\n\n- a 500-word answer (~670 tokens) lands in under 3 seconds<\/strong><\/li>\n
- a 1,000-token reply \u2014 a full page of prose \u2014 in 4 seconds<\/strong><\/li>\n
- a 2,000-token chunk of code or a long refactor in 8 seconds<\/strong><\/li>\n
- a 4,000-token file in 16 seconds<\/strong><\/li>\n<\/ul>\n
The other side of the comparison<\/h2>\n
The other model I run comes in around 30 tokens per second<\/strong> \u2014 same kind of work, roughly eight times slower<\/strong>. The arithmetic is unforgiving:<\/p>\n\n- a 500-word answer: under 3 seconds<\/strong> against 22 seconds<\/strong><\/li>\n
- a 1,000-token reply: 4 seconds<\/strong> against 33 seconds<\/strong><\/li>\n
- a 4,000-token file: 16 seconds<\/strong> against 2 minutes 13 seconds<\/strong><\/li>\n<\/ul>\n
That gap is not cosmetic, it changes behaviour. At 30 tokens per second you batch, you write smaller prompts, and you let context go stale because re-reading it costs minutes. At 250, those habits stop being necessary \u2014 and an agent loop that retries three times costs a few seconds instead of a coffee break.<\/p>\n
Put together with everything else I run, it seems DeepSeek Flash is simply the fastest model I have access to right now \u2014 not by a few percent, but by a factor of eight. That is an observation about my own setup and my own workloads, not a league table: a different connection, a different host, or a much larger model would tell a different story.<\/p>\n
Two caveats, because a rate comparison is easy to over-read. The 30 tokens per second figure is my own observation from normal use, not a benchmark \u2014 same as the 250. And rate is not quality: a slower model can be the better one on the task in front of you. This is about how long you wait, not about which answer is right.<\/p>\n
Why speed changes how you work, not just how it feels<\/h2>\n
The interesting effect is not comfort, it is the shape of the work. When a 4,000-token answer costs 16 seconds, you stop batching: you ask for the whole file instead of a diff, you ask for the paragraph to be rewritten instead of patched, and you let an agent loop take three attempts instead of one. Latency is the tax on iteration, and at this rate the tax mostly disappears.<\/p>\n
There is a practical consequence for agent setups specifically. The expensive part of a loop stops being the generation and becomes the tool calls around it \u2014 when the model writes faster than your script can save the file, the bottleneck has moved somewhere else. Worth knowing before you spend effort optimising the wrong half.<\/p>\n
The honest caveats<\/h2>\n
A single run is not a benchmark, and I would distrust anyone who presents one as if it were:<\/p>\n
\n- Output rate is not throughput.<\/strong> 250 tokens per second is what came back out. The prompt still has to be read first, and prefill is a separate cost that grows with context.<\/li>\n
- It varies with time of day and load.<\/strong> DeepSeek runs an off-peak discount window, so both price and speed follow the queue. My 250 will not be everyone's 250.<\/li>\n
- It varies with what you ask for.<\/strong> A short answer, a long code block and a heavy tool-use turn do not sample the same path. One number cannot describe all of them.<\/li>\n
- It says nothing about quality.<\/strong> A fast wrong answer is still wrong. Speed only makes it cheaper to iterate until it is not.<\/li>\n<\/ul>\n
The bigger point<\/h2>\n
Speed like this deserves attention for a second reason: it is not a closed API party trick. The model behind it shipped with open weights, as I noted when DeepSeek V4.1 Flash was released<\/a>, which means behaviour in this range will eventually show up wherever the model can be hosted \u2014 including your own hardware, at whatever rate that hardware manages.<\/p>\nSo I will keep measuring. When a number like this appears in a single run, the useful next step is not to publish the trophy \u2014 it is to run it ten more times and find out what the floor looks like. That is the part that tells you whether it is a fast model or a lucky one.<\/p>","summary":"I measured DeepSeek Flash writing at about 250 tokens per second, against roughly 30 on another model I run. What the eight-fold gap means in practice, and why a single run is not a benchmark.","tags":["ai","llm","deepseek","performance"],"image":"\/user\/pages\/02.blog\/2026-09-12-deepseek-flash-250-tokens-per-second\/cover.avif"},{"title":"DeepSeek V4.1-Flash: Open Weights, a Quarter of the KV Cache, and a Retired Model ID","date_published":"2026-09-10T15:00:00+03:00","id":"https:\/\/docs.agenteum.top\/blog\/2026-09-10-deepseek-v41-flash-open-weights","url":"https:\/\/docs.agenteum.top\/blog\/2026-09-10-deepseek-v41-flash-open-weights","content_html":"
Today DeepSeek shipped DeepSeek-V4.1-Flash<\/strong>, and for once the interesting part is not the benchmark table.<\/p>\nThe weights are already on Hugging Face<\/a> under an MIT license<\/strong> \u2014 510 GB across 48 shards, published the same day as the API, alongside a technical report<\/a>. The report's title is the whole story: \"Pushing the Limits of KV Cache Compression.\"<\/em><\/p>\nThree days ago I moved my daily driver from DeepSeek Flash to GLM-5.3-Flash<\/a> at low effort. Today I moved it back \u2014 and the reason has almost nothing to do with how clever the new model is.<\/p>\nThe real headline: 890 bytes per token<\/h2>\n
Everyone measures models by benchmark scores. The number that actually changed today is this one:<\/p>\n
DeepSeek-V4.1-Flash keeps 890 bytes of KV cache per token in HBM<\/strong> \u2014 roughly a quarter of what V4-Flash needed, with a persistent footprint (SSD or host memory) at about one eighth. It gets there with FP4 KV caching and cross-layer KV reuse in a redesigned attention scheme (CSA2).<\/p>\nStated that way it sounds like plumbing. Here is what it means concretely: a one-million-token context costs about 0.93 GB of KV cache.<\/strong> A naive layout \u2014 single KV head, 512-dim, FP16 \u2014 would need roughly 2.15 GB for the same sequence.<\/p>\nWhy that matters: long agent sessions are input-heavy<\/strong>, not output-heavy. Every turn re-sends a huge prefix. The bottleneck for agent workloads isn't how fast a model writes, it's how much compute and memory it costs to re-read<\/em> everything it has already seen. This model is an attack on that specific problem.<\/p>\nWhat changed under the hood<\/h2>\n
The architecture is a bigger departure than the name suggests:<\/p>\n
\n- 552B backbone parameters plus 196B Engram parameters<\/strong> \u2014 around 748B total, but only 8B active during prefill<\/strong> and 16B during decode<\/strong><\/li>\n
- 40 layers split as a 20-layer causal encoder followed by a 20-layer decoder<\/strong> (their new CED design), mixing sliding-window and global attention<\/li>\n
- An Engram<\/strong> component: a 16-million-entry n-gram lookup table acting as parameterised memory<\/li>\n
- Multimodal from the start: a DeepSeek-ViT vision encoder and projector, trained jointly on a 45T-token corpus<\/li>\n<\/ul>\n
For comparison, GLM-5.3-Flash is 320B total with 18B active<\/strong>. V4.1-Flash activates a smaller slice of a much larger model<\/em> \u2014 which is exactly what I see in practice: ~154 tokens\/second<\/strong> on DeepSeek versus roughly 50<\/strong> on GLM. That difference is not a rounding error when an agent is making dozens of calls to finish one task.<\/p>\nWhere it wins, and where it doesn't<\/h2>\n