LectuLibre's max_tokens=4096 forces at least 25 calls to translate one novel

Call `translate_chunk` and the model receives a system prompt holding the language pair, a summary of previous chapters, and a glossary rendered as `source -> translation` lines ^[16]. The chunk text itself goes in the user message ^[5]. The glossary block instructs the model to "use exactly these translations" ^[11]. A single 150,000-token prompt carries no equivalent instruction. That line is what holds a character's name steady on page 300.

The same function sets `max_tokens=4096` ^[10]. A 100,000-token book needs roughly 100,000 tokens of translated output, assuming the target language tokenizes at a similar rate, so at 4,096 tokens per response the job takes at least 25 calls ^[4]. The advertised 200,000-token window is an input budget ^[2].

Now the overlap. Chunks are 3,000 tokens with 500 tokens of overlap, so the window advances 2,500 tokens per call ^[6][1]. At the top of the post's own range for a novel, 150,000 tokens ^[3], that is 60 chunks, and 60 chunks at 3,000 tokens is 180,000 tokens of input for a 150,000-token book, a fifth of it paid for twice ^[2][3]. Each chunk also triggers a term-extraction call and a summary call on top of the translation ^[15]. That is up to 180 requests for one book ^[5].

The post lists cost first among its reasons not to send a whole book in one call ^[4], and it does not give a per-book figure for either approach. On tokens alone the chunked run bills more. For it to bill less, the price per input token would have to climb with prompt length, or the single long call would have to fail often enough that repaid inputs swamp the overlap. The post does report rate limits and timeouts as problems ^[4], and the retry policy is three attempts with exponential backoff capped at ten seconds ^[13]. Three attempts at 150,000 input tokens is 450,000 tokens for one book ^[6].

Sizing runs on tiktoken's `cl100k_base`, an encoding built for a different vendor's models, and the code comment says it "approximates well enough for chunk sizing" ^[8]. At 3,000 tokens against a 200,000-token limit, it does. Approximation bites at the response instead: 4,096 output tokens against a 3,000-token input is 1.36x of headroom ^[7], which is comfortable when source and target tokenize at similar rates and tight when the target expands.

The part I would keep in any version of this is the state layout. The glossary is a dict stored as JSONB in PostgreSQL and updated after every chunk, and the summary of each translated chunk is stored for the next one ^[12][15]. A crash costs one chunk. It also serialises the job, because chunk n+1's prompt depends on chunk n's output, so those 60 calls run one at a time; routing simpler passages to DeepSeek ^[14] changes the price of a call, and the order they have to happen in stays fixed.