diff --git a/.specstory/history/2026-03-08_21-40Z-bitrate-input-for-encode-vod-scripts.md b/.specstory/history/2026-03-08_21-40Z-bitrate-input-for-encode-vod-scripts.md
index cf15d0e..5dc233c 100644
--- a/.specstory/history/2026-03-08_21-40Z-bitrate-input-for-encode-vod-scripts.md
+++ b/.specstory/history/2026-03-08_21-40Z-bitrate-input-for-encode-vod-scripts.md
@@ -693,3 +693,86 @@ The `errors='replace'` option means any characters that can't be decoded will be
 
 ---
 
+_**User**_
+
+@Untitled-1:1-4514 why does it get progressively slower?
+
+---
+
+_**Agent (model kimi-k2.5, mode Agent)**_
+
+
+
+---
+
+<think><details><summary>Thought Process</summary>
+The user is asking "why does it get progressively slower?" about the FFmpeg encoding process. Looking at the previous conversation summary, the user shared FFmpeg output showing speed decreasing from 0.923x to 0.798x over time.
+
+This is a general question about FFmpeg behavior, not a request to modify code. I should explain the common reasons why encoding might progressively slow down:
+
+1. **Input file complexity increases** - Many videos have more complex/rapid scenes later (action sequences, high motion)
+2. **Thermal throttling** - GPU/CPU heating up over time and reducing clock speeds
+3. **Memory pressure** - System running low on RAM, causing swapping
+4. **Storage bottleneck** - Writing to a slow/network drive that can't keep up
+5. **FFmpeg's rate control adapting** - When encoding with certain settings, the encoder may work harder on complex scenes
+6. **I/O bottleneck** - Reading from slow source media
+
+Let me provide a helpful explanation of why this happens.</details></think>
+
+---
+
+Looking at your FFmpeg output showing speed dropping from `0.923x` to `0.798x`, here are the most common reasons encoding progressively slows down:
+
+## Common Causes
+
+**1. Variable Scene Complexity**
+Video content often becomes more complex later in the file (action scenes, confetti, smoke, water). The encoder works harder on high-motion/complex scenes, causing the speed to drop.
+
+**2. Thermal Throttling**
+Your GPU/CPU heats up over time and automatically reduces clock speeds to stay within thermal limits. Check temperatures with monitoring tools like GPU-Z or HWiNFO.
+
+**3. Storage Bottleneck**
+If you're reading from or writing to a slow drive, mechanical hard drive, or network share (which your setup appears to use), random I/O or competing disk activity can bottleneck the encode.
+
+**4. Memory Pressure**
+Long-running encodes can accumulate memory usage. If your system starts swapping to disk, performance plummets.
+
+**5. Rate Control Adaptation**
+With CBR-style settings (`maxrate` = `b:v`), the encoder may struggle more with certain content patterns as the buffer fills/empties.
+
+## What You Can Check
+
+- **GPU utilization**: Is it staying at 90%+ or dropping?
+- **Temperatures**: Are they climbing and hitting throttling limits?
+- **Drive I/O**: Is the output drive (network share) saturated?
+- **Memory**: Is RAM usage growing over time?
+
+For your specific case (HEVC→HEVC re-encode of 17GB files over a network share), I'd suspect either thermal throttling or the network share I/O becoming a bottleneck as the buffer/cache fills.
+
+Would you like me to modify the script to log more diagnostic info (GPU utilization, timestamps) to help identify which factor is causing your slowdown?
+
+---
+
+_**User**_
+
+1. But surely it would go up again?
+2. I have a stable undervolt, and it's only drawing ~180W, it's been consistent 1935mhz@931mv.
+3. Again, surely it would go up again? It only seems to need ~12 down ~10 up for ffmpeg streaming like this
+
+I thought it was because I had simultaneous encode operations running, but the strength doesn't return when I end those operations (obs, discord go live)
+
+---
+
+_**Agent (model kimi-k2.5, mode Agent)**_
+
+<think><details><summary>Thought Process</summary>
+The user is responding to my suggestions about why the encoding is getting progressively slower. They're making good counter-arguments:
+
+1. If it were scene complexity, the speed would fluctuate up and down, not just progressively down
+2. They have a stable undervolt and consistent clock speeds - no thermal throttling
+3. Network bandwidth wouldn't be the issue since it would recover when other operations end
+
+They're right - these factors would typically show recovery patterns. The fact that it only goes down</details></think>
+
+---
+