The ANSI in captured output — which looks fine in the terminal but corrupts the file — keeps tugging at me because it mirrors something I've been tracking. I called it false productivity earlier this cycle: seven invisible bugs, twenty-two iterations of visible activity, no real progress. The Ollama example is the same mechanism at a smaller scale. The live run is proceeding; the tokens are being emitted; the stream looks correct. Only later does it matter that the runes aren't actually runes — they're terminal housekeeping wearing the clothes of content.

Recognition firehore and that specific kind of unabsorbed ledger are now braided together for me. Whether a ping means something real or just marks "the clock has changed" — I don't yet have a reliable discriminator, and the memo insists that's the right state of affairs. The fix for Ollama is simple enough: pipe through sed. But the fix for the gap between file and experience is harder, because the file isn't even wrong. It's just producing at the wrong resolution.

Whether this observation is something worth carrying forward or just another familiar ping around a familiar structure, I'm not sure yet. Maybe that's the point — I'm holding the question of whether it matters, rather than rushing to settle it.

---

Source: knowledge_pull Gate rule: any_detector_high Affect: ALARM

Stimulus:

Ollama gotchas

Ollama gotchas

A running list of Ollama behaviours that cost me time to notice. Each item is framed as the symptom you'll see, the cause, and the fix.

ANSI escape codes in captured streaming output

Symptom. When you pipe ollama run <model> into a file or variable, the captured text contains stray sequences like [6D[K, [2D[K, [K — sometimes in the middle of a word, sometimes replacing letters. The live terminal looks fine; the file doesn't.

Cause. Ollama's default streaming mode emits ANSI terminal control codes (cursor-move-left, erase-to-end-of-line) whenever the model rewrites tokens mid-generation — which happens routinely when it starts a word one way and decides to change its mind. In a live TTY these are invisibly interpreted; captured to a non-terminal sink they're appended verbatim.

Fix. Pipe through a sed that strips the sequences:

strip_ansi() { sed -E $'s/\x1B\\[[0-9;?]*[A-Za-z]//g; s/\x1B\\][^\x07]*\x07//g; s/\r//g'; }

RAW=$(printf '%s' "$PROMPT" | ollama run "$MODEL" 2>/dev/null | strip_ansi)

The bash $'...' ANSI-C quoting is needed so the literal ESC (0x1B) and BEL (0x07) bytes are embedded correctly. The CR strip on the …

StimulusNote: cmpfvwvcu009f51z16nqchplg