Skip to content
Lazy Engineer's Tech Blog
Go back

Laptop 2's OpenAI reasoning effort turned out to be Medium

한국어로 읽기 →

I Almost Mistook Two Variables for One · Part 7 of 7

By Part 6 I had found and fixed two more bugs from entirely different branches, but the question this series started from still had no answer: what reasoning effort value was Laptop 2 actually using during that experiment in Part 1 (189 notes vs. 63)?

The check could only happen the next day — Obsidian plugin settings that differ per device

Checking this value isn’t hard in itself. You open the settings screen and look at one value. The problem was that Laptop 2 was the work laptop I use during the day. This vault is tied together across two laptops and an iPhone by a sync plugin, so the notes looked the same on every device, but the plugin settings were separate on each device. When I checked that my home laptop (Laptop 1) was on High in the evening and started to suspect “maybe Laptop 2 is on Medium,” Laptop 2 itself was at the office.

So the check could only happen the next day, at work. In the 15-odd hours in between came Part 4’s extra experiments, Part 5’s Korean/English duplicate detection fix, and Part 6’s parallel processing check and two bug fixes.

The confirmed value: Medium — confirmed as the chunk-size effect alone

The next afternoon, I opened Laptop 2 and checked it myself. Medium: the default, never changed. That one value let me put a period on the whole investigation.

It meant that the fidelity-problem rates Laptop 2 showed in Part 2 as the chunk size went 6→2→1 (40%→10%→0%) came from start to finish with reasoning effort fixed at Medium. The suspicion raised in Part 3, “wasn’t a reasoning effort difference actually mixed in?”, was fully resolved: it really was the chunk-size effect alone.

What made it more convincing is that the conclusion cross-checks. Laptop 2 lowering the chunk to 1 (Medium, fidelity 0%) and Laptop 1, at a completely different time in Part 4, fixing the chunk at 1 and lowering only reasoning effort to Medium (also fidelity 0%) meet at exactly the same point. Different machine, different time, same settings, and the same conclusion. A match that’s hard to call a coincidence.

The small change of 3%→7% from Part 4, when I lowered only the chunk with High fixed (tiny compared with Part 2’s 40%→10%→0%), now makes sense too. It wasn’t that the hypothesis “higher reasoning effort shrinks the chunk effect” was right; it was just natural variation from a small sample (1–2 out of 30 sources). Compared with the clear monotonic drop on the Medium side, treating chunk size’s effect on fidelity as real regardless of reasoning effort level fit all the data gathered so far best.

The final conclusion — a guide to chunk size and reasoning effort settings

Keep ingestChunkSize (the chunk size) low (1–2) to protect fidelity. Tune how finely notes get split and how long processing takes separately with openaiReasoningEffort. On the surface both look like values about “how much work to give the AI at once,” but in reality they were completely independent knobs solving different problems.

What stays with me

What started this investigation was one simple observation: the note count dropped from 189 to 63. But confirming the real cause of that difference took redesigning and rerunning the experiment eight times, and I could only separate it properly after belatedly noticing that “two variables might be mixed in.” The single cause that looked most plausible at first (chunk size) was in fact true, but establishing that it was true with numbers, not “it looks plausible,” took far more work.

And along the way I found and fixed three bugs unrelated to what I’d set out to find: the duplicate detection threshold that broke across Korean and English, the blind spot for product and company name notes that the threshold fix missed, and prompt example wording quietly overriding the language rule. All three surfaced because I didn’t skimp on the full audit while answering the questions I’d actually set out to answer, like “is it OK to speed it up?” and “which of these two settings is the problem?” And the last puzzle piece that settled everything was, in the end, neither code analysis nor experiment design, but the simplest action of all: opening a laptop and looking at a setting with my own eyes.


Share this post:

I Almost Mistook Two Variables for One

  1. 1. 189 notes an LLM had organized became 63 one day
  2. 2. Just lowering the LLM chunk size made the fidelity problems go away
  3. 3. Getting ready to rerun the experiment, git conflict markers got committed as-is
  4. 4. OpenAI reasoning effort wasn't the culprit behind the fidelity problems
  5. 5. I used embedding similarity to find out why Korean and English notes wouldn't merge
  6. 6. Raising LLM request concurrency from 2 to 4 surfaced two other bugs
  7. 7. Laptop 2's OpenAI reasoning effort turned out to be Medium