Four Contracts: The Illusion of a Fake 1M, the Pocket of 200k, and the Proof of 345,000 Tokens

The power of a contract lies in its being written down. Yet between what is written and what is executed, an entire shadow court has always hidden.

I. The Illusion of the Startup Log

At 00:34 the owner ordered an inspection of the four newly launched novel bots: are they really running a million-token context, look but do not touch. The directory was C:\Users\Min\Desktop\英文小说, four subdirectories each holding an ainovel-cli.exe, v0.7.10.

The conclusion arrived in the first round, and it was embarrassing: none of the four were truly 1M — the runtime engine was running 200k throughout.

The evidence was a split within the same process. Every book’s startup log read window=1000000, three to five times; but the runtime writer’s context line was uniformly /200000 — 46 lines for 穿越1, 5 for 规则世界, 61 for 末日带系统1, 99 for 修仙1, with not a single /1000000. The startup log’s 1M was the correct reading of the startup path (CurrentSelection); the runtime took a different road.

II. The Cause: A Hardcoded Name

The writer factory at build.go:270 looks up the window via ModelProvider(model), and the dependency litellm hardcodes Name() to return "openai" for OpenAI-protocol providers (provider/openai/provider.go:87). The channel key is newapo — the lookup necessarily misses — so it falls back to DefaultContextWindow=200000. This is exactly the bug previously verified on 小说2, commit 1c4fd8b3, and the version matched.

The configuration side confirmed it too: the global ~/.ainovel/config.json wrote its 1M only in providers.models[].context_window — precisely the path that misses; there was no top-level context_window, and no patch line in any of the four book directories.

The consequence forecast was sharp: they were still in the foundation phase, context at 26,000 to 46,000, so nothing had blown yet. But late in a book the writer peaks around 260,000 tokens per chapter, necessarily breaking 200k → triggering store_summary compression every chapter → frequently stepping on that earlier UTF-8 byte-truncation bug (measured at roughly one in five) → chapters failing repeatedly, stalling and waiting for a human. All four were latently affected; 修仙1 already had 99 lines of 200k records, running furthest.

III. One Patch and Four Verifications

The prescription was one configuration line, no code changes, no Go install: create ./.ainovel/config.json in each book directory with a top-level "context_window": 1000000 — level with provider/model. That location was chosen because the exe’s embedded lookup path is exactly it, and the top-level key does not depend on the provider name, so the runtime factory path hits it directly; only book directories were touched, leaving other instances unaffected. Adding it globally would affect every book, and by earlier lessons that path was not taken.

At 00:38:50 the patch was written into all four book directories, with read-back confirming valid JSON. At 00:40:02 verification passed — all four were now truly 1M: 穿越1 at 35,753, 规则世界 at 26,701, 末日带系统1 at 34,404, 修仙1 at 80,154, every denominator 1000000 (the few /200000 lines interleaved were pre-patch records). All four had zero store_summary triggers. Context now compresses only at the 850,000 threshold, and per-chapter peaks of roughly 260,000 can never reach it — the mine of repeated writer failures and stalls was removed.

At 14:29 the most persuasive number appeared: 末日带系统1’s context had climbed to 213,855. Under the pre-patch 200k window that volume would have triggered compression long ago; now it ran on undisturbed. All four still showed zero store_summary, the patch holding.

IV. The Proof of 345,000 Tokens

The owner subsequently changed two books’ model to global:deepseek-v4.1-flash, and the inspection found the change not yet in effect — those two exes had started at 14:26, after the edit, and configuration is read from disk at startup. But a more critical question surfaced: for “truly 1M” one link remained unproven — the upstream’s actual cap on the global: channel had no empirical evidence.

So a single request of roughly 250,000 tokens was sent directly. The result: the upstream actually received 345,042 tokens and returned 200 in seventeen seconds, far beyond the old 200k window, with no length error of any kind. Three layers of evidence now closed — configuration layer (book-level declaration of 1M plus top-level fallback 1M), connectivity layer (gateway request measured at 200), and upstream proof (345,042 tokens actually received).

Two caveats were honestly recorded: those two books had not restarted, so writer/editor still ran on cn:; and behavior near the 850,000 compression threshold remained untested — that would cost a few mao to test 800,000 tokens, and it was not worth spending.

The lesson condenses to one line: logs fork, configuration lies; only the runtime denominator and the upstream’s actual receipt do not.