Pipeline

Notes on how work gets routed, budgeted and rendered. The shape of the systems rather than the code.

token optimisation router

Diagrams and stills, once uploaded.

Not every step in a long job needs the most capable model; most of it is bookkeeping that a cheaper tier answers just as well. So each kind of task is pinned to a tier up front and routed by declared task type, with every call's token usage recorded, which makes spend a number you can look at rather than a surprise. There is no classifier picking a tier at runtime, and nothing here learns or adapts from past runs; automatic classification is a next step, not a shipped feature. The accounting is the part worth keeping, since attributing usage per task type is what shows where a cheaper tier would actually pay off.

 task
   |
   v
 +---------------------+
 | role pinned by      |   declared task type,
 | declared task type  |   no runtime classifier
 +---------------------+
    |               |
    v               v
 +---------+    +----------+
 | cheaper |    | stronger |
 | model   |    | model    |
 +---------+    +----------+
    |               |
    +-------+-------+
            v
         result
            |
            +--> token accounting, per task type

compression, as a budget problem

Illustrations to come.

Context is a budget, not a container: a long job that re-sends its whole history at every step spends most of that budget restating what it already established, and eventually stops fitting at all. The approaches being explored are the ordinary ones, summarise finished stages down to their conclusions, chunk large inputs so only the relevant part travels, and cache intermediate results so a repeated step is a lookup rather than a re-derivation. The trade is always the same: what you compress away you cannot ask about later, so the real work is deciding what is safe to lose. This is exploratory, a way of thinking about long jobs rather than a finished system with results to quote.

 long input
     |
     v
 +-------+    +-----------+    +-------+    +--------------+
 | chunk | -> | summarise | -> | cache | -> | reuse on the |
 +-------+    +-----------+    +-------+    | later passes |
                                            +--------------+

render backend

Batch output to come.

Work is described declaratively, what to open, what to look at, what to write out, and each job is handed to its own headless process with a bounded timeout. That is the whole design argument: an old scene can hang on a missing asset, cook forever, or take the interpreter down with it, and in one shared process any of those ends the batch, while isolated and time-boxed the same failure is a single row marked failed with everything after it still running. Each job returns structured output plus an image, the numbers you can sort against and the frame you have to look at to know it worked.

 job list
    |
    v
 +----------+     +-----------------------+
 | dispatch | --> | one bounded process,  |
 +----------+     | time-boxed, per job   |
      ^           +-----------------------+
      |              |                |
      |             ok             failed
      |              |                |
      |              v                v
      +---------- collected rows + image per job