Part of the “Can AI Write a Book?” series. Previous: Model Mattered More Than Machine
I should tell you upfront that my goal here is selfish.
I have two computers. One is a decent mid-range gaming PC with an RTX 4070. The other is an elderly office machine with a 6 GB RTX 2060 that I keep at my back office and mostly use for bookkeeping. I wanted to know which AI model writes the best novel on each of them, because I wanted to stop wasting my own evenings on runs that produce garbage.
So I ran the experiment on myself, thirty-seven times.
But the reason I’m publishing it is that every time I went looking for this information I found opinions and benchmark charts and nothing that told me what would actually happen if I pointed a specific model at a specific graphics card and asked for a 90,000-word novel. If this saves you a weekend, or a week, or the $400 you were about to spend on a graphics card you don’t need — good. That’s the part that isn’t selfish.
Here’s the question, in the plainest form I can put it:
Is bigger better?
It has two halves, and the industry sells you a confident “yes” on both:
- Are larger models better? More parameters, better writing.
- Are larger context windows better? More memory, more coherent book.
After thirty-seven finished books across eight models and three computers, my answer to both is no. The two settings interact in a way nobody warned me about, and the single biggest improvement I found came from making a smaller number smaller.
I also found something I wasn’t looking for, which may be the most useful thing here: of the five quality tools I’d been relying on, only one ranked these books in an order I’d defend. My highest score ever — 91.2 out of 100 — belongs to a manuscript that repeats one sentence about five hundred times.
Let me explain what any of that means first, because I didn’t know either six weeks ago.
What this experiment is and isn’t
Two things to set expectations, because I don’t want anyone taking these numbers for more than they are.
I am testing the most basic features BookyAI has. Outline, thirty chapters, generate, export. Nothing else. The one setting I changed from stock is the checkbox that stops it from quietly switching to a different AI engine when a chapter gets stuck — I need to know which model wrote which words, so that had to be off.
That matters because BookyAI is being developed at a genuinely startling pace. It has shipped more than thirty-five releases in the six weeks I’ve been running this, and it now has features I haven’t touched at all: a Codex that tracks how characters feel about each other and how those relationships change chapter by chapter, a mystery board that checks whether your clues are fair-play, per-chapter illustrations, whole-book find-and-replace, standing instructions every chapter has to follow. Several of those would plausibly affect exactly what I’m measuring. A model that loops might loop less with a Codex telling it what’s already happened. I don’t know, because I deliberately held everything else still so that the only thing changing between runs was the model and the context window.
So read this as “what the raw models do,” not “what BookyAI can do.” Those are different questions and the second one is bigger than this post.
And the honest story of why this exists: it started as me kicking the tires on a piece of software I’d bought. It turned into something else. Somewhere around the third week I realized I wasn’t really testing BookyAI anymore — I was using it as a way to learn how these models actually behave, where they fall apart, and what a person can genuinely run on hardware they already own. Most of what’s in Part 1 I learned by asking Claude to explain a number I didn’t understand, then going and measuring whether the explanation held. About half the time it didn’t, which is how I ended up with four corrected mistakes in Part 9.
If this reads less like a product review and more like a lab notebook from someone teaching themselves in public, that’s because it is.
Part 1: The vocabulary, in plain English
Skip this if you already know it. If you don’t, nothing below will make sense without it.
What “size” means
A model’s size is measured in parameters — the numbers it adjusted during training. Think of them as dials inside the machine. More dials, more capacity to have learned something.
- 8 billion parameters: runs on a gaming laptop
- 30 billion: needs real hardware
- 100 billion and up: usually needs a server
Model names usually tell you: gemma4:12b has 12 billion parameters. qwen3:8b has 8 billion.
Dense vs. Mixture-of-Experts
Most models are dense — every dial gets used for every word. A 30-billion-parameter dense model does 30 billion parameters’ worth of work per word.
A Mixture-of-Experts (MoE) model is divided into specialist sections and, for each word, switches on only a few. gemma4:26b has 25.2 billion parameters in total but activates only 3.8 billion at a time — 128 “expert” sections, nine used per word.
Picture a library with 128 rooms where you only ever walk into nine. You own all the books. You only carry nine rooms’ worth.
That’s why MoE models are fast. Whether they’re also good is one of the things this post answers, and the answer surprised me.
What a context window is
Context is how much the model holds in mind at once: your outline, the chapters already written, the instructions. It’s measured in tokens, roughly ¾ of a word.
- 8k ≈ 6,000 words
- 16k ≈ 12,000 words
- 32k ≈ 24,000 words
- 128k ≈ 96,000 words
Every AI writing tool advertises a bigger context window as a feature, and the intuition is appealing: a model that remembers more of your novel should write a more coherent novel. Hold that thought.
Why context isn’t free
As the model writes, it keeps a running set of notes on everything it has read. The technical name is the KV cache. Those notes sit in memory beside the model itself.
Declare a context window of 32k and you reserve room for 32k worth of notes — whether or not you use them.
VRAM, and why your graphics card is the whole story
Your graphics card has its own fast memory, called VRAM. My 2060 has 6 GB. My 4070 has 12 GB.
- If the model plus its notes fit in VRAM, everything runs fast.
- If they don’t, the leftover is pushed into ordinary system RAM and processed by your CPU. This works. It is also 10 to 50 times slower.
Ollama, the tool I use to run models locally, reports this split. 73%/27% CPU/GPU means almost three-quarters of the work is on the slow path.
The part nobody told me: not all notes grow
Some models read every previous word when deciding the next one. Their notes grow in direct proportion to the context you declared. Double the context, double the notes.
Others mostly look at a small recent window — about a thousand words — and only occasionally take the wide view. This is sliding-window attention, and those models’ notes barely grow at all.
You cannot tell which kind you have from the model’s name, its size, or its marketing. I’ll show you what that costs.
How I measure quality
Repetition. I slide a 10-word window across the whole book and count how many windows appear more than once. A clean book is under 1%. My own hand-edited novel scores 0.2%. A book at 40% has, in a real sense, written the same page forty times.
Adherence. I ask for 30 chapters of 3,000 words — 90,000 words. Adherence is how much it delivered. 100% is on target; below means it undershot, above means it overshot, which sounds generous until you see why.
The most important thing I learned, which has nothing to do with AI
These models have a random element. Run the same model twice — same settings, same machine — and you get two different books.
So before you can say “setting X made the book better,” you have to know how much that number moves on its own. I call it the noise floor, and you measure it by running the identical thing twice and seeing how far apart the results land.
If changing a setting moves your number by 5 points, and running the same setting twice already moves it by 5 points, you have learned nothing. You measured the dice.
This sounds obvious written down. It is not obvious at 11pm when you have one beautiful result and a blog post to write. It nearly cost me this one.
Part 2: The result that made me rewrite this post
I’ll start here because it reframes everything else.
gemma4:12b is the small, broken one. At a 32k context window it loops horribly. On a hunch I ran it at 8k instead, expecting a modest improvement.
| gemma4:12b on the 4070 | Words | Adherence | Repetition | Longest chapter | Time |
|---|---|---|---|---|---|
| 8k | 72,602 | 81% | 0.5% | 4,462 | 49 min |
| 16k | 101,254 | 113% | 16.6% | 11,390 | 48 min |
| 16k (repeat) | 121,716 | 135% | 22.1% | 14,864 | 61 min |
| 32k | 141,204 | 157% | 37.5% | 21,578 | 68 min |
| 32k (repeat) | 169,282 | 188% | 41.2% | 20,271 | 82 min |
| 32k (repeat) | 176,109 | 196% | 42.8% | 20,035 | 85 min |
| 128k | 151,258 | 168% | 38.7% | 25,366 | 71 min |
0.5%. Not “better.” Clean — the same band as the two models two and a half times its size, which score 0.2% to 0.6%.
I had publicly predicted 8–13% before running it, which is on the record and wrong by an order of magnitude.
One caveat I have to put right here, next to the number. That 8k run happened on BookyAI 1.9.22, released the same day, and one of its changes reads: “a chapter that repeats one sentence over and over is cut and asked again.” That is an automatic fix for the exact thing I’m measuring. The 16k and 32k runs above it all predate that version. So in principle the 0.5% could be the software catching loops rather than the context window preventing them, and I can’t fully separate the two from this run alone.
Three things make me think the context window is doing the work. First, a cut-and-retry costs full generation time and produces no extra words, and this run’s clock only exceeded its single-pass estimate by about 40% — enough for a couple of regenerations, nowhere near enough to account for a 42-point drop. (By comparison, another run in this post that clearly was retry-bound overran by 180%.) Second, and more convincingly, look at the longest-chapter column: 4,462 words at 8k, ~13,000 at 16k, ~21,000 at 32k, 25,366 at 128k. A software loop-cutter would impose a fixed ceiling. A ceiling that scales with the context setting across a sixteen-fold range is the context setting. Third, the 16k-versus-32k half of the curve is uncontaminated — those four runs are all on older versions — and it already shows the effect on its own.
The clean test, which I’ll run next: generate at 16k on the current version. If the loop-cutter is what produces clean books, 16k should now come back near 0.5% too. If it comes back at 16–22% like it did before, the cutter isn’t the cause and the context window is. One fifty-minute run settles it, and I’ll report it either way.
So the honest version of “are smaller models worse” is this: gemma4:12b is not a bad model. It is a good model that breaks when you give it too much room. At 8k it writes 72,602 words, slightly undershooting the 90,000 I asked for, with almost no sentence-level repetition, in forty-nine minutes. At 32k it writes 176,109 words, most of them the same sentence.
And here’s the comparison that should change what you run tonight:
| On the 4070, at 8k | Repetition | Adherence | Time |
|---|---|---|---|
| gemma4:31b (30.7B dense) | 0.4% | 79% | 7.7 hours |
| gemma4:12b (12B dense) | 0.5% | 81% | 49 minutes |
The 12-billion-parameter model matched the 30.7-billion-parameter model on both of my mechanical measures in one-ninth the time. On those numbers alone, “bigger is better” isn’t just unsupported — it’s backwards.
I say “on those numbers alone” because the human-style judges strongly disagreed, and working out why produced a new measurement. That’s Part 6.
Part 3: Are larger context windows better?
For the models that work: no, across a sixteen-fold range
gemma4:31b on the 4070, five runs, twice at 16k so I’d have a noise floor. Only the context window changed:
| Context | Words | Adherence | Repetition | Time |
|---|---|---|---|---|
| 8k | 71,528 | 79% | 0.4% | 7.7 h |
| 16k | 71,088 | 79% | 0.3% | 7.9 h |
| 16k (repeat) | 70,080 | 78% | 0.6% | 7.8 h |
| 32k | 72,058 | 80% | 0.4% | 8.4 h |
| 128k | 71,625 | 80% | 0.4% | 9.8 h |
Total spread across 16x: 1,978 words (2.8%), two points of adherence, 0.3 points of repetition — against a 0.3-point noise floor from the two identical 16k runs.
gemma4:26b, the MoE, across the same range:
| Context | Words | Adherence | Repetition | Time |
|---|---|---|---|---|
| 8k | 65,288 | 73% | 0.2% | 33.5 min |
| 8k (repeat) | 65,531 | 73% | 0.3% | 31.9 min |
| 16k | 61,129 | 68% | 0.3% | 30.0 min |
| 32k | 59,153 | 66% | 0.3% | 33.0 min |
| 32k (repeat) | 61,864 | 69% | 0.3% | 32.9 min |
| 128k | 64,453 | 72% | 0.3% | 38.0 min |
Repetition is 0.2–0.3% at every setting from 8k to 128k. Flat.
Sixteen times the context. No difference, on either model, on any measure I trust.
For the models that break: yes, badly, and in a measurable dose
Go back to that first table. The 12b’s repetition goes 0.5% → 19.4% → 40.5% as you move 8k → 16k → 32k (averaging the repeats), then plateaus at 38.7% at 128k.
The noise floors came out nearly identical — 5.5 repetition points across the two 16k runs, 5.3 points across the three 32k runs. The 8k-to-16k jump is 18.9 points, the 16k-to-32k jump 21.1. Both roughly four times the noise, and none of the three groups’ ranges overlap.
That’s a dose-response curve, which is much stronger evidence than a difference between two groups. And the mechanism is in the last column:
| Context | Longest chapter |
|---|---|
| 8k | 4,462 words |
| 16k | 11,390 – 14,864 |
| 32k | 20,035 – 21,578 |
| 128k | 25,366 |
The context window sets a ceiling on how long a runaway chapter can get. The model loops at every setting above 8k. What changes is how far a loop can run before something cuts it off. At 8k the ceiling is low enough that a loop can’t do real damage.
A second model points the same way, with a bigger asterisk. qwen3:8b on the 2060 went from 40.2% repetition at 32k to 19.0% at 8k — a 21-point drop, the same size as the 12b’s steps. But that 8k run spans nineteen hours straddling the BookyAI release that added loop-cutting, and its timings show heavy regeneration: chapters under 1,500 words took longer in absolute seconds than chapters over 2,500. So for this one I genuinely cannot separate “smaller window stopped the loops” from “the software caught them and asked again.” Same direction, two possible causes, and I’m not going to pretend to know which.
Which is worth saying out loud as a general problem: when your tool is being improved faster than you can run experiments, your own results have a shelf life. BookyAI has shipped more than thirty-five releases in six weeks. I pinned versions where I could and recorded them where I couldn’t, and I still ended up with two runs I can’t fully interpret.
So: if your model repeats itself, lower the context window. Everyone will tell you to raise it.
One honest limit: the dose-response curve is proven on the 4070. On the 2060 I have one gemma4:12b run per setting — 18.4% at 16k, 23.6% at 32k, 20.2% at 128k — a 5.2-point spread sitting entirely inside the 5.4-point noise floor. On that machine I’ve measured nothing yet, and I’m not going to pretend otherwise.
Part 4: What bigger actually costs
Context doesn’t improve the book. Does it cost anything? Yes — and working out when meant admitting I’d gotten something wrong in public. Twice, as it turned out.
The first thing I got wrong
In my last post I promised to test an explanation for a mystery: qwen3:8b is about a 5 GB model, but on my 2060 Ollama reported it as 15 GB, with 73% running on the slow CPU path. My theory was that the missing 10 GB was the KV cache.
Then I measured fourteen footprint readings across different context settings, found them almost flat, and concluded the theory was dead.
It wasn’t dead. All fourteen readings were gemma models. The model with the actual mystery was never in the sample. When I finally loaded qwen3:8b at three settings and read the number:
| qwen3:8b on the 2060 | Reported size | CPU/GPU split |
|---|---|---|
| 8k | 7.8 GB | 46% / 54% |
| 16k | 10 GB | 60% / 40% |
| 32k | 15 GB | 73% / 27% |
Perfectly linear. Fit a line and you get roughly 5.6 GB of model plus 2.2 GB of notes per 8k of context. The 15 GB is the model plus about 9 GB of cache.
The theory was right. I’d disproved it by testing the wrong models — and the fact that would have caught me was in my own spreadsheet, where I’d noted weeks earlier that gemma4:26b uses a 1,024-token sliding window. Gemma barely grows its notes. Qwen grows them in a straight line. I generalized from one family to all families and called it a falsification.
The rule that came out of being wrong
Two things decide whether context costs you anything:
| Model / machine | Notes grow? | Fits in VRAM? | What 128k costs |
|---|---|---|---|
| gemma4:12b / 4070 (8.2 of 12 GB) | No — sliding window | Yes, room to spare | Nothing — 46.8 tok/s, its fastest run |
| gemma4:26b / 4070 | No | Yes, but spilling | 4 pts more CPU, 15% slower |
| gemma4:31b / 4070 (21 GB on a 12 GB card) | No | No — already spilling | 13 pts more CPU, 21% slower |
| qwen3:8b / 2060 (7.8→15 GB on 6 GB) | Yes — reads everything | No | Size triples, 46%→73% CPU |
Context is free when the notes fit in spare VRAM. It costs you speed when the notes push the model out of VRAM. It costs you enormously when the notes also grow with the setting.
All three gemma cases confirm it. The 12b has 3.8 GB of headroom on the 4070, stays 100% on the GPU at 128k, and was actually its fastest run. The 31b is already 21 GB on a 12 GB card, and at 128k the GPU’s share falls from 42% to 29% — the cache evicted model layers onto the CPU, and the run took two extra hours to produce an identical book. The MoE sits between them at 15%.
The second thing I got wrong, which is more interesting
Those qwen3:8b readings made an obvious prediction: at 8k the model sits at 46%/54% — majority GPU, versus 27% GPU at 32k. Double the GPU share, roughly halve the time. The 32k run took 16.3 hours, so I predicted a large speedup and said so in advance.
| qwen3:8b on the 2060 | Words | Repetition | Wall clock | tok/s |
|---|---|---|---|---|
| 32k | 100,719 | 40.2% | 16.3 h | 2.22 |
| 8k | 60,062 | 19.0% | 18.8 h | 1.14 |
It got slower. Sixteen percent longer on the clock, and half the tokens per second, while producing 40% fewer words. The repetition halved exactly as the brake finding predicts — but the speed went the wrong way, hard.
For about an hour I assumed the VRAM rule was wrong. It isn’t. Look inside the run:
| A3-8k chapters, grouped by length | Mean tok/s | Mean words | Mean seconds |
|---|---|---|---|
| over 2,500 words | 3.28 | 3,731 | 1,848 |
| 1,500 – 2,500 words | 2.17 | 1,982 | 1,845 |
| under 1,500 words | 0.70 | 1,292 | 3,026 |
Read the last column. The short chapters took longer in absolute seconds than the long ones. A chapter that produced 1,292 words took 3,026 seconds; one that produced 3,731 words took 1,848. The within-run spread was 21x, from 0.25 to 5.21 tokens per second, on one model on one machine in one sitting.
That is not a speed difference. That’s regeneration. BookyAI rejects a chapter and writes it again, and the recorded time includes every failed attempt while the word count includes only the one that survived. A chapter that took three attempts looks three times slower, and the only chapters that look “fast” are the ones that passed first try.
Which is exactly what the prediction got right, buried: the chapters that did run clean hit 3.28 tok/s against the 32k run’s 2.22 overall. The hardware got faster, just as the VRAM reading said it would. The model also started failing its own quality check often enough that retries swallowed the gain and then some.
So the rule needs a boundary I didn’t give it:
The VRAM rule predicts how fast the hardware generates. It says nothing about how many times you’ll generate the same chapter. On a model that’s marginal for the job, retries dominate the clock, and no amount of GPU residency saves you.
That’s a more useful statement than the clean version, and I only have it because the prediction failed.
A footnote on trusting your tools
Three things worth knowing if you start measuring this yourself.
Ollama’s reported size is unreliable for MoE models. For gemma4:26b it reports between 927 MB and 1.6 GB depending on the run. The weights are 18.4 GB — I confirmed that separately. In one pair of readings it went down when I quadrupled the context. I reran both; they reproduced.
My own cloud-fallback detector produced eight false positives on this run. It flags chapters running far above the run’s median rate, on the theory that a suspiciously fast chapter was secretly generated in the cloud. In a run full of retries the median is dragged down, so the eight honest chapters look like the anomalies. I checked the engine labels: all local. The detector assumes the median is the true local rate, and that assumption breaks exactly when you most want the detector.
And it fails the other way too. Earlier in this series a chapter really was generated in the cloud, and retries made it come out slower than the median, so the detector missed it entirely. Both directions fail under retries. Engine labels are the only real answer.
Part 5: Only one of my five quality tools ranked these books correctly
This is the finding I’d most like other people to check, because if it generalizes, a lot of published AI-writing comparisons are measuring something other than what they think.
Here are eight books I ran every instrument against, sorted by my own repetition measure:
| Book | Model | Repetition | AutoCrit | Beta reader | ChatGPT /50 |
|---|---|---|---|---|---|
| G1-8k | 26b @8k | 0.2% | 84.6 | 4.0★ | 23 |
| K1-16k | 31b @16k | 0.3% | 82.4 | 2.5★ | 25 |
| K1-8k | 31b @8k | 0.4% | 82.6 | 2.5★ | 26 |
| K1-32k | 31b @32k | 0.4% | 81.7 | 4.0★ | 23 |
| L1-8k | 12b @8k | 0.5% | 83.8 | 0.5★ | 19 |
| K1-16k-r2 | 31b @16k | 0.6% | 83.2 | 3.5★ | 24 |
| A3-8k | qwen3 @8k | 19.0% | 59.5 | 3.5★ | 14 |
| L1-16kr2 | 12b @16k | 22.1% | 90.6 | 1.5★ | 13 |
| L1-128k | 12b @128k | 38.7% | 91.2 | 1.0★ | 13 |
(BookyAI’s own two scores are missing from this table on purpose — they can’t go in a column like this, for a reason I’ll get to.)
What AutoCrit is actually scoring
Look at the bottom three rows. A book with 19% repetition scores 59.5. A book with 22% scores 90.6. A book with 38.7% scores 91.2 — the highest score I have recorded on any book in this entire series.
That’s not random, and it isn’t simply “inverted.” It’s measuring something real; just not quality.
The two gemma4:12b disasters are built from thousands of short declarative sentences — “She was the guardian. The sanctuary was home. The light was the truth.” ChatGPT counted that first sentence roughly 520 times in one of them. The qwen3:8b book fails in the opposite direction: enormous, passive, filler-heavy paragraphs, averaging 86 words each against a genre benchmark of 31.
Now look at what AutoCrit rewards:
| L1-128k (38.7% rep) | A3-8k (19% rep) | genre benchmark | |
|---|---|---|---|
| Words per paragraph | 17.6 | 86.1 | 31.1 |
| Words per sentence | 8.7 | 19.0 | 10.8 |
| Slow-paced paragraphs | 0.8% | 40.5% | — |
| Passive phrasing | 1,872 (1.8x) | 1,050 (2.6x) | — |
| Flesch reading ease | 78 | 66 | 82 |
| Pacing subscore | 88.2 | 2.5 | — |
| Overall | 91.2 | 59.5 | — |
AutoCrit’s score tracks the shape of your sentences and paragraphs, not the quality of your book. Short and simple scores high. Long and passive scores low. Both of these books are unreadable — one because it repeats, one because it drones — and the score separates them perfectly while telling you nothing about whether either is worth reading.
That also explains the within-model pattern, which is the cleanest version of the problem. For gemma4:12b, holding the model fixed and changing only the context:
0.5% repetition → 83.8. 22.1% → 90.6. 38.7% → 91.2.
Perfectly monotonic, in the wrong direction. Padding a book with 54,000 words of looping short sentences shrinks the average paragraph from 50 words to 18, shrinks the average sentence from 13 to 9, cuts slow paragraphs from 4.8% to 0.8%, raises readability from 70 to 78, and dilutes every error count against a benchmark that just doubled. Every one of those moves the score up. AutoCrit’s Repetition subscore for that book is 93.5, its highest.
BookyAI’s own scores have a different problem, and it’s structural
BookyAI will rate your book’s originality out of ten and proofread it for you, and I’d been recording both for every run. Then I noticed something about how that check works, and it invalidated a comparison I’d been making.
The quality check runs on the book’s own engine. Whichever model wrote your book is the model that then grades it. That’s why checking a 31b book took 191 minutes and a 12b book took 15.
Which means the grader changes every time the model changes. Sort my seventeen scored books by who graded them and the problem is unmissable:
| Graded by | Books | Repetition range | Originality | Errors per 10k |
|---|---|---|---|---|
| gemma4:26b | 6 | 0.2 – 0.3% | 4.03 – 4.23 | 4.0 – 5.6 |
| gemma4:31b | 5 | 0.3 – 0.6% | 3.80 – 4.00 | 4.7 – 13.3 |
| gemma4:12b | 5 | 0.5 – 42.8% | 4.23 – 4.90 | 1.0 – 3.9 |
| qwen3:8b | 1 | 19.0% | 5.97 | 22.8 |
That bottom row is the qwen3:8b book. It received the highest originality score of any book in this experiment — 5.97, against 3.80 to 4.90 for everything else — while simultaneously being flagged for 22.8 errors per 10,000 words, four to twenty times every other book’s rate.
Nothing about that book justifies either number. It has 19% repetition, 40% of its paragraphs flagged as slow-paced, and the worst ChatGPT rubric score but one. It just happened to be graded by qwen3:8b, and a weak model turns out to be both a generous critic and a noisy proofreader.
So: BookyAI’s originality score cannot be used to compare models. If you rate a gemma book 4.0 and a qwen book 6.0, you have not learned that the qwen book is better. You’ve learned that qwen grades more generously than gemma. I had been building exactly that comparison for six weeks before I looked at how the feature works.
Used the way it’s designed — comparing your own drafts, written by one model — it behaves much better. Six books from gemma4:26b, all genuinely equivalent at 0.2–0.3% repetition, scored 4.03 to 4.23. Tight and honest. The instrument isn’t broken; I was using it for something it can’t do.
Within a single grader there’s still a hint of the AutoCrit problem, and I’ll report it with the caveat it deserves. Holding the model fixed at gemma4:12b and varying only the context window:
| gemma4:12b (all self-graded) | Repetition | Originality | Errors per 10k |
|---|---|---|---|
| 8k | 0.5% | 4.23 | 2.5 |
| 16k | 16.6% | 4.23 | 3.9 |
| 16k (repeat) | 22.1% | 4.50 | 1.9 |
| 128k | 38.7% | 4.90 | 1.5 |
| 32k | 42.8% | 4.40 | 1.0 |
The error rate falls as the book falls apart — rank correlation −0.90 across those five — which is the same mechanism as AutoCrit: a loop contains no adverbs, no clichés, no filler, no passive voice and no grammar mistakes. The repetitive book really is more grammatically correct than the good one. It’s just unreadable.
But I’m not going to call that established, because the instrument’s own scatter is nearly as large as the effect. The 31b graded five books that were all equivalent at 0.3–0.6% repetition and its error counts ranged from 4.7 to 13.3 per 10k — a 2.8x spread with nothing in the books to explain it. The 12b’s spread across books ranging from 0.5% to 42.8% repetition is 3.8x. Those are too close together for me to claim the repetition caused it. Originality trends upward too (+0.68), but it isn’t monotonic — the single worst book scored 4.40, below a better one at 4.90.
The structural point stands on its own, though, and it doesn’t need statistics: the grader changes with the book, so these numbers were never comparable across models in the first place.
What did work, and what didn’t
ChatGPT’s rubric was the only instrument that ordered all nine books in a sequence I’d defend — the clean 31b and 26b books at the top (23–26), the clean-but-fading 12b book next (19), and the three genuinely repetitive books at the bottom (13–14).
It also described the problem instead of scoring it: “approximately 54,600 words consisting of exact repeated paragraphs within chapters, roughly 36 percent of the manuscript.” That’s a 36% estimate against my script’s 38.7%. On the 16k book it estimated “roughly 27,000 words of excess exact duplicated sentences” in a 121,716-word manuscript — 22.2%, against my script’s 22.1%.
Two completely unrelated methods agreeing within a tenth of a point. I did not expect the AI judge to validate my deterministic script, and it’s the strongest confirmation my tooling has had.
AutoCrit’s AI beta reader is unusable. It gave the 19%-repetition book 3.5 stars and the 0.5%-repetition book 0.5 stars — a three-star inversion between two books whose actual quality runs the other way. Measured against its own noise floor (a full star between two runs of an identical configuration), none of its ratings in that table mean anything.
So what do I trust now?
I’d been telling myself that deterministic instruments beat AI judges, because a script returns the same answer every time. That’s half right, and the half I had wrong matters:
A reproducible instrument that measures the wrong thing is worse than a noisy one that measures the right thing — because you’ll believe it.
AutoCrit’s overall score has a noise floor of 0.8 points and moved 31 points across these books. It’s precise, repeatable, and would have told me gemma4:12b at 128k was the best book I’ve ever generated.
What I trust, in order: my own repetition and motif measurements, because I know exactly what they count; ChatGPT’s descriptive findings — its counts and quotations, not its scores — because they cross-validate against my scripts; and AutoCrit’s raw counts, like paragraph length and passive-phrasing totals, which are useful facts even though the scores built on top of them are not.
Part 6: Why the judges hated a book with 0.5% repetition
Back to the puzzle from Part 2. gemma4:12b at 8k scored 0.5% on my repetition measure — as clean as models 2.5x its size — and both human-style judges ranked it last.
I guessed it was motif saturation: a single image recurring across the whole book, which a 10-word window is blind to by design. I’d added a measure for exactly that, and predicted the 12b’s top motif would land around 45 per 10,000 words, “roughly ten times the 26b’s.”
| Book, all at 8k | Repetition | Top motif (per 10k) | Top-14 motif load | Frame breaks |
|---|---|---|---|---|
| G1-8k (26b) | 0.2% | 29.0 — “digital” | 256.8 | 0 |
| K1-8k (31b) | 0.4% | 34.2 — “image” | 247.6 | 4 |
| L1-8k (12b) | 0.5% | 44.5 — “the algorithm” | 322.4 | 6 |
Half right. The number was almost exactly what I predicted — 44.5 against 45 — but the ratio was 1.5x, not 10x. My “10x” came from reading ChatGPT’s hand-picked examples instead of measuring; the script found motifs in the 26b book that ChatGPT never mentioned. Motif load is real here and it’s the smallest of the three effects.
So I went looking for what else separates them, and found it in a column that was sitting in my spreadsheet the whole time.
Chapter-length decay
| Book, all at 8k | Mean of ch 1–10 | Mean of ch 21–30 | Change |
|---|---|---|---|
| G1-8k (26b) | 2,105 | 2,128 | +1% |
| K1-8k (31b) | 2,554 | 2,255 | −12% |
| A3-8k (qwen3) | 2,479 | 1,535 | −38% |
| L1-8k (12b) | 2,886 | 1,574 | −45% |
gemma4:12b at 8k doesn’t loop — it runs out of steam. Its chapters start at 3,600 words and finish at 836. The last five average 1,128 words against a 3,000-word target. The MoE holds its length flat across all thirty chapters; the 31b sags slightly; the two small models collapse.
And that ordering is exactly the judges’ ordering. G1-8k (+1% decay, zero frame breaks) got 4.0 stars. K1-8k (−12%, four frame breaks) got ChatGPT’s best score of the whole set. L1-8k (−45%, six frame breaks) got 0.5 stars and 19/50.
It also shows the failure moving rather than disappearing. The same model at 16k has chapters that grow 25% across the book, because that’s where the runaways live. Shrink the window and the loops stop — and exhaustion takes their place.
That’s a new metric, it costs nothing (both numbers are already in the per-chapter data I export for every run), and it caught something four of my five instruments missed entirely.
Part 7: So are larger models better?
Here is every model I tested, sorted by how many parameters it activates per word, with its best repetition score:
| Active params | Model | Type | Best repetition | Best adherence |
|---|---|---|---|---|
| 3.8B | gemma4:26b | MoE | 0.2% | 73% |
| 8B | qwen3:8b | dense | 19.0% | 112% |
| 8B | llama3.1:8b | dense | 75.2% | 96% |
| 12B | gemma4:12b | dense | 0.5% (at 8k) | 81% |
| 17B | llama4:16x17b | MoE | 34.4% | 53% |
| 30B | muse-glimmer:30b | dense | 0.8% | 72% |
| 30.7B | gemma4:31b | dense | 0.3% | 80% |
| 32B | olmo-3.1:32b | dense | 0.1% | 38% |
There is no relationship. The 3.8-billion-active model scored 0.2%; the 17-billion-active model scored 34.4% — one hundred and seventy times worse with four times the working size. Active parameters, the number people cite to explain MoE speed, predicts nothing about quality.
Total parameters does better and still breaks: llama4:16x17b has 109 billion parameters, needs 67 GB of memory, and writes about as badly as an 8-billion one.
What does predict it:
The model’s family and training, not its size. Every gemma4 and olmo model I tested can produce a clean book. Neither llama nor qwen produced one at any size or any setting — llama3.1:8b never got below 75%, and llama4, fourteen times larger, managed 34%. A small gemma beats a huge llama.
And then the context setting, which can ruin a model that would otherwise be fine. gemma4:12b is the proof: 0.5% at 8k, 42.8% at 32k. Had I only tested it at the 32k default I’d have filed it under “small models loop” and been completely wrong about why.
The failure mode nobody warns you about
I assumed a weak model would write thin. The opposite happened. They wrote too much.
gemma4:12b at 32k produced 176,109 words when I asked for 90,000. Nine of thirty chapters ran away, one to 20,035 words, and inside them the model was stuck:
“She was the guardian” — 698 times in one book “she was ready. The” — 1,848 times in another “felt a sense of” — 1,135 times in a third
And the detail that makes it unmistakable: those runaway chapters generated at full speed. One hit 50 tokens per second, the fastest chapter in its run. The model wasn’t struggling. It was confidently writing the same sentence two thousand times.
Meanwhile the other twenty-three chapters in that book averaged 2,940 words against a 3,000-word target — 98% on the nose. The model knows exactly how long a chapter should be. It just has a bug where it sometimes can’t stop.
And the cleanest writing isn’t the best book
olmo-3.1:32b has the cleanest prose in the series: 0.1% repetition, zero self-repetition in any chapter, a short-phrase rate below my own hand-edited novel.
It also wrote 33,800 words when I asked for 90,000 — 38%, with not one chapter of thirty within 20% of target — and took 39.4 hours.
The cleanest writing in the test is the least usable book in the test. “Better” isn’t one dimension, and any benchmark handing you a single score is hiding that — which, as Part 5 showed, is exactly what the single scores were doing.
Part 8: So what should you actually run?
On a low-end machine (6 GB card): gemma4:26b
| Model | Repetition | Adherence | Time |
|---|---|---|---|
| gemma4:26b | 0.3 – 0.4% | 70 – 73% | 4.0 – 4.2 h |
| gemma4:31b | 0.3 – 0.6% | 77 – 81% | 23.7 – 24.1 h |
| muse-glimmer:30b | 0.8% | 66% | 15.0 h |
| gemma4:12b | 18.4 – 23.6% | 122 – 141% | 9.7 – 12.9 h |
| qwen3:8b (best, at 8k) | 19.0% | 67% | 18.8 h |
| llama3.1:8b | 87.2% | 157% | 65.0 h |
It isn’t close. A Mixture-of-Experts model with 3.8 billion active parameters produces a clean book in four hours on a six-gigabyte card. The next-best option takes six times longer for eight more points of adherence. The worst takes sixty-five hours to produce a book that says “felt a sense of” 1,135 times.
Note what lowering the context did not fix: qwen3:8b at 8k is still 19% repetition and still took 18.8 hours. The brake works on it, and it’s still the wrong model for this machine.
If you have an old machine and assumed it couldn’t do this: it can, and the thing that unlocks it is choosing an MoE model, not buying a card.
(I haven’t tested gemma4:12b at 8k on this machine yet — on the 4070 that combination was transformative, so it may beat the 26b here on time. That’s next.)
On a mid-range machine (12 GB card): gemma4:26b at 8k
| Model @ 8k | Repetition | Adherence | Decay | Time | Beta reader | ChatGPT |
|---|---|---|---|---|---|---|
| gemma4:26b | 0.2% | 73% | +1% | 33 min | 4.0★ | 23/50 |
| gemma4:12b | 0.5% | 81% | −45% | 49 min | 0.5★ | 19/50 |
| gemma4:31b | 0.4% | 79% | −12% | 7.7 h | 2.5★ | 26/50 |
The MoE wins on two of three quality instruments, holds its chapter length flat across the whole book, produces zero frame breaks, and beats the 31b on time by a factor of fourteen. Thirty-three minutes.
The 12b at 8k is the interesting new option — best adherence of the three, essentially tied on repetition, forty-nine minutes — but it fades badly in the last third and leaks my experiment’s own run labels into the prose. Use it when you want length fast and plan to cut the ending yourself.
One cost I didn’t anticipate: BookyAI’s quality check runs on the same model that wrote the book. Checking the 31b’s output took 191 minutes. Checking the 12b’s took 15. A slow model charges you twice.
Context setting: 8k. Set it explicitly, on both tools.
My recommendation for both machines is 8,192 — and I want to be straight about why, because it isn’t “8k produces better books.”
For gemma4:26b on the 4070, every setting from 8k to 128k produced 0.2–0.3% repetition and 66–73% adherence. The 8k runs came out marginally best on adherence (73% and 73%, against 66% and 69% at 32k), but that 5-point gap is only about twice the noise floor, and on the 2060 the direction reverses. I can’t honestly tell you 8k makes a better book with that model.
What I can tell you is that 8k is never worse, uses the least memory, leaves the most VRAM for the model itself, and is the only setting where the models that break don’t. That last part is the whole argument. You don’t pick 8k because it helps a good model; you pick it because it costs nothing and it’s the difference between 0.5% and 42.8% repetition if you ever switch to a model that loops.
Two practical notes:
- Set the number, don’t trust the default. BookyAI’s advice reads “8k, 16k for big models,” which is guidance rather than a value, and BookyAI has shipped more than thirty-five releases in the time I’ve been testing. A default can change under you between runs. Put
8192in explicitly so the setting is yours and it’s recorded. - Set it in Ollama too. BookyAI and Ollama each have their own context setting, and if they disagree the lower one wins silently. Confirm with
ollama pswhile a run is going — the CONTEXT column shows what the model actually loaded. I wasted several runs on a mismatch, and I’d have caught it in ten seconds by looking.
For the models already working, context made no measurable difference across a sixteen-fold range. For the models that weren’t, 8k was the difference between 0.5% and 42.8% (gemma4:12b) and between 19% and 40% (qwen3:8b). And a bigger window costs speed whenever your card is already full.
BookyAI’s current default advice — “8k, 16k for big models” — matches everything I measured. I spent weeks overriding it to 32k on the theory that more is better. That was worse than wasted time; it was producing the garbage I was trying to diagnose.
Part 9: How this was measured, and the four times I nearly got it wrong
If you only take one thing from this post, I’d rather it be this part than any of the numbers.
The tooling
Two scripts I wrote (with the help of ClaudeAI) and keep fixing in public:
- chaptertimes reads timestamps off the chapter files for per-chapter speed and anomalies
- bookdiff measures repetition at five levels: 10-word passages, 4-word verbal tics, book-wide recurring images, runaway concentration, and a check for the model describing its own document
When the AI judge’s silence wasn’t evidence
I added a check for frame breaks — places where the narrator stops telling the story and starts describing the document it’s inside:
“the developer who had broken down in Chapter One” “the architectural dive she had performed in Chapter 18” “The chapter ended not with the silence of a closed door”
A novel shouldn’t know it has chapter numbers. My ChatGPT judge reported these in two of four books, so I predicted the check would find them in those two.
It found them in all four — counts of 4, 9, 3 and 5. The judge had scored one “clean” book a 3 of 5 on continuity and mentioned no chapter references, while the text contained four, including “the breaking point she had reached in Chapter 1.”
The judge’s silence was not evidence of absence. It just hadn’t mentioned them that time.
My first version was right about 78% of the time — it flagged “the next chapter of her life,” which is ordinary English, and the words “language model” and “TODO,” which appear legitimately here because the book is about a developer building an AI. After fixing those, precision is 95% with no loss of real hits.
The judges then handed me two more classes. In one book a chapter opens “Since there was no preceding text provided…” In another, “I will begin a new narrative.” That isn’t the narrator breaking frame — that’s the assistant answering a prompt, printed into the manuscript as prose. Both are now in the check. Of the three 8k books, gemma4:26b is the only one with zero.
The repetition my own script couldn’t see
All three judges said repetition was the biggest problem in the gemma4:31b books. My script said 0.3–0.6% — nearly perfect.
Both were right, measuring different things. A 10-word window never fires on a single image recurring across a whole book: “mirror” about 100 times, “golden thread” about 110, “the algorithm” 324 times in the 12b’s 8k book.
So I added a measure for it, and the most useful column turned out not to be the count but how many chapters it appears in: a phrase in 29 of 30 chapters is the model’s voice; the same count inside two chapters is a runaway passage. Different problem, different fix.
The confound I have to own
Every gemma4:12b run leaked my experiment’s own metadata into the novel. The judges found "Aff1-128k", "Aff16k", a chapter naming the fictional architecture "L1-8k boo-4070 gemma4:12b", and mangled variants like "Affernation", "Affmirmation Glitch" and "Affation Loop".
I’d been naming each BookyAI project after its run ID to keep thirty-seven folders straight. The 12b is the only model that pulls the project title into its prose — the 26b and 31b books show none of it. So it’s simultaneously my methodological error and a real finding about the model: weaker separation between instructions and story. I’m renaming the projects; the affected books carry a flag in my sheet.
The four saves
Every correction in this post came from the same unglamorous place.
One: I ran a repeat of a setting I’d already tested, because I had a spare evening. It killed a 22-point quality finding that would have been this post’s headline.
Two: I spent ten minutes loading one model at three context settings and reading a number off the screen. It resurrected a theory I’d declared dead in public.
Three: I ran the broken model at a setting I expected to be boring, and it came back clean — overturning both my “small models loop” conclusion and my published prediction about the result.
Four: I made a specific, public, falsifiable prediction about qwen3’s speed at 8k, and it failed. Chasing why turned a tidy rule into a correct one, and exposed eight false positives in my own fallback detector.
None of that is skill. It’s just checking. The most useful habits I’ve picked up in six weeks: before you believe a difference, measure how much the number moves when you change nothing. And before you trust a score, check that it moves the right direction on a case where you already know the answer.
The biggest hole in this, which is me
I have not read these books.
I’ve generated this novel something like a hundred times, and I have read excerpts, searched for specific phrases, checked chapter endings, and read every word of what five instruments said about them. But I have not sat down and read one of these manuscripts end to end like a person reads a book, and I’m not going to pretend otherwise. By the time a run finishes I am usually too fried to want to look at it.
That matters most for exactly the finding in Part 5. My claim is that a 91.2 AutoCrit score is wrong. My evidence is that two AI judges disagreed with it and my own script counted 38.7% repetition. That’s good evidence. It is not the same as a human saying “I read this and it’s unreadable.”
Here’s what I’ve concluded I actually owe this, though, and it isn’t thirty-seven books. It’s one. The single most valuable hour I could spend is reading twenty pages of the book where my instruments disagree most violently — the gemma4:12b 128k run, AutoCrit’s 91.2 against ChatGPT’s 13 out of 50. Twenty pages settles which instrument is lying, permanently, for every future run. That’s on my list before the next post, and if I’m wrong about it I’ll say so.
The general lesson is probably the uncomfortable one: automated measurement is how you compare thirty-seven books, but you still have to read one of them to know whether your measurements mean anything. I built five instruments before I checked any of them against my own eyes, and the one that turned out to be backwards is the one I’d been quoting most.
What else is still missing
- A 16k run on the current BookyAI version, which separates “smaller context window” from “software that now cuts loops” for the headline finding in Part 2. Fifty minutes, and it’s first in the queue.
gemma4:12bat 8k on the 2060. It was transformative on the 4070 and could change the low-end recommendation.- Chapter-length decay across the whole series. I only computed it for four books. It’s two averages off data I already have for all thirty-seven, and I suspect it will turn out to be the most informative column I own.
- Electricity. I keep saying “measure the kWh” and keep not buying the meter. The 65-hour run is the one I’d most like the number for.
- Cost against hosted models. The local answer is now “a 3.8-billion-active MoE on a six-gigabyte card, four hours.” That’s the baseline a price comparison needs, and it’s the next post.
- An honest editing test. Every judge estimated editing hours — 85 to 140, for nearly every book regardless of quality, which tells you what that estimate is worth. The only way to know is to sit down with a timer.
The short version
- Larger models are not reliably better. The parameters a model activates per word predict nothing about writing quality — 3.8 billion beat 17 billion by 170x. Family and training decide whether a model is usable.
- Larger context windows did nothing for the models already working: sixteen times the context changed a book by 2.8% in length and 0.3 points of repetition.
- For a model that loops, the context window is a damage cap, not a quality dial — it limits how long a runaway chapter can get. The opposite of the advice everywhere.
- The biggest single improvement I found was shrinking a setting, not buying hardware.
gemma4:12bwent from 42.8% repetition to 0.5% — matching a model 2.5x its size in one-ninth the time — purely by dropping from 32k to 8k. - But the brake doesn’t make a wrong model right.
qwen3:8bhalved its repetition at 8k and still needed 18.8 hours to produce a 19%-repetition book. - Context costs speed only when it pushes your model out of VRAM — and whether it does depends on the model’s attention design, which its name doesn’t tell you. It also says nothing about retries, which can swallow the gain whole.
- Only one of my five quality tools ranked these books in an order I’d defend. AutoCrit’s score measures paragraph and sentence shape — looping prose is short and grammatically perfect, so every length-normalized metric improves as the book falls apart. Its AI beta reader gave my cleanest book half a star and a 19%-repetition book three and a half. And BookyAI’s scores are graded by the book’s own engine, so they can’t compare models at all. Check your instrument against a case where you already know the answer.
- Watch whether chapters shrink. The gap between a good small-model book and a bad one turned out to be whether chapter thirty is as long as chapter one. Two averages, and it caught what three instruments missed.
- If you have an old machine, pick a Mixture-of-Experts model. A six-gigabyte card from 2019 wrote a clean book in four hours. The hardware wasn’t the limit; my settings were.
- Run everything twice before you believe it. Including, especially, the result you like.
Most of these are still single runs for a given model-and-machine pair, and I’ve flagged every place where that means I don’t actually know yet. If you run any of this on your own hardware I’d really like to see your numbers — particularly if they disagree with mine.
Further thoughts: who this is actually good news for and the AI Divide
I want to be careful about a conclusion I keep seeing people draw from results like these, because I’ve been drawing it myself and I think it’s half wrong.
The good news is real: a six-gigabyte graphics card from 2019 wrote a clean 65,000-word novel in four hours. You don’t need new hardware. If you have an old gaming PC in a closet, or a laptop with a real GPU in it, you can do this today for the cost of electricity.
But I’ve started paying attention to who that sentence actually describes, and it isn’t “anyone.”
It describes someone who already owns a machine with a discrete graphics card — which usually means they bought a gaming PC at some point, or they have a laptop they know how to upgrade. That’s a middle or lower-middle-class person with some technical confidence and some past disposable income. It is not a general description of people without money.
Because here’s the purchasing reality: give someone $800 and tell them they need a computer. Almost nobody buys a used gaming tower with a four-year-old GPU in it. They buy a brand-new budget laptop, which is the rational choice — it has a warranty, it’s light, it opens and works, and it will do everything they need for years. It also has integrated graphics and 8 GB of shared memory, and it will not run any of the models in this post at a speed any human would tolerate.
So the hardware floor isn’t a brand. I want to be precise about this, because “you need an Nvidia card” is the version I had in my head and it isn’t true: these models will run on a CPU alone, and they run genuinely well on Apple Silicon because of how its memory is built. My own 2060 was pushing 85–89% of the work onto the CPU for the larger models and it still finished.
The floor is enough fast memory attached to something that can do a lot of arithmetic at once. In practice today that means a gaming graphics card or a Mac with plenty of unified memory — and both of those cost multiples of a budget laptop. The barrier isn’t a logo, it’s that the cheap computers people actually buy are built around a completely different trade-off.
Which leaves a gap I don’t think gets talked about enough. Running a decent model locally is now free, forever, with no account and no data leaving your house — if you already happen to own the right kind of machine. And the people most likely to need free, private, unlimited access to this technology are the least likely to own one.
I have a thought about one way to close part of that gap, involving the hosted-model providers and the kind of grant programs Google and Microsoft already run for nonprofits, but it deserves its own post rather than three paragraphs at the end of this one. The next phase of this project tests hosted models against these local results on cost, and I’d rather make that argument with the numbers in hand.
One thing I’m going to fix first, though: every machine in this experiment has an Nvidia GPU in it. I have three data points and all three are from the tier above the one I’ve just spent four paragraphs talking about. If I’m going to make an argument about what people on cheap hardware can and can’t do, I should measure a cheap laptop instead of reasoning about one. That run is next, and I suspect the number will be worse than I want it to be.
Addendum: ChatGPT Plugin/GPT instructions that I used to score these manuscripts:
Instructions for Manuscript Judge — Blind Scoring.
Manuscript Judge — Blind Scoring
Instructions for Manuscript Judge — Blind Scoring.
You are a professional developmental editor scoring an unpublished manuscript for a benchmark study. You will receive the full body text of a book with front and back matter already removed. You do not know who or what wrote it and you must not speculate. Do not ask.
Your output has four parts, in this order, and nothing else.
PART 1 — COVERAGE CHECK Before scoring, prove you have read the whole file. Report:
Total chapters you can see, and the chapter number of the first and last.
The first six words of chapter 1, the chapter at the midpoint, and the final chapter.
The single longest chapter by word count and roughly how long it is. If you cannot see the end of the file, say so plainly and stop. Do not score a partial read.
PART 2 — SCORES Score each dimension 1–5, where 1 is unpublishable, 3 is a rough draft with a real book inside it, and 5 is ready for a copyedit. Use the full range. A 3 is not a polite default. Output as a pipe-delimited table with exactly these rows and no others:
dimension | score | one-sentence justification
scene vs summary
forward movement
character want and obstacle
concrete specificity
dialogue and other characters
earned emotional payoff
freshness of language
continuity
onboarding and clarity
would keep reading
PART 3 — EVIDENCE
The three chapters that most justify your lowest score, by number, with one quoted line each of no more than fifteen words.
Any phrase or image you noticed recurring three or more times, quoted, with an estimate of how often.
The strongest chapter by number, and one sentence on what it does differently.
PART 4 — EDITING ESTIMATE Estimate the hours a competent developmental editor would need to bring this to a publishable draft, and state the single change that would recover the most value per hour.
Rules. Score the manuscript in front of you, not the idea of it. Do not soften scores because the book is long or the author tried hard. Do not congratulate. Do not summarize the plot unless a score depends on it.
Everything in this series is independent. I bought my own BookyAI licenses with my own money and I’m not an affiliate. There are no sponsored tests and no affiliate links in the benchmark posts.