Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Librarydispatch / 2026-07-12

Port the site. Keep the conductor.

How I ported aris-space to Cloudflare while the model that planned it never executed a task. Rent the conductor, swap the orchestra.

4 parts / Hover to explore. Click to read.

How I ported aris-space to Cloudflare while the model that planned it never executed a task. Rent the conductor, swap the orchestra.

Harness: routing + gates
           |
    planning model holds plan
           | bounded slices
           v
       worker models
           | evidence
           v
       human gates
The planning model and worker models occupy different jobs inside the harness. Changing a model does not remove the human decisions at the gates.

When I moved Ari's Space to Cloudflare, the model that planned the migration didn't execute a single migration task.

Fable held the plan and the gates. Cheaper worker models handled the slices: the adapter, the wrangler configuration and the DNS cutover. I stayed with the decisions that needed my judgement.

one prompt, fanned out

An animated example: five parallel workers, then two dependent workers. No jobs or checks run here.

A grid of identical tiny workers, each building a webpage, fanning out from one node.
One routing layer distributes bounded work across the workers.

Keep the plan coherent while the workers change

The conductor stays fixed. Swap the orchestra, and the bill collapses.

The conductor metaphor covers two things worth separating. The harness holds the routing and gates. A model occupies the planning seat within that system. Worker models carry out the assigned jobs.

For this move, Fable held that seat. It didn't need to do every edit to keep the migration coherent.

The planning model can change too. At the time of the original July 2026 note, a cheaper model with a large context window was coordinating 34 parallel workers in another job. Another had wired the Grok fleet that shipped ten landing pages overnight.

Those are examples of the arrangement I was running, not a required team size. The useful question is whether a model can hold this particular brief and return work you can check.

provider cost dial

The orchestra (model)

Agents in the fan-out: 235

Run cost: $117.50

Real published rates, Jun 2026 ($/1M in/out): Claude (Opus 4.8) $5/$25, GLM-4.6 $0.43/$1.74, MiniMax M2 $0.26/$1.00. Assumes ~56k tokens per agent (45k in, 11k out).

A cheap transistor radio on a pedestal conducts an orchestra of grander instruments.
The planning seat can change model too. Keep the routing contract and the gates clear.
The intelligence is the routing, not any single model.

Keep the human gates in the account

The migration took a day and a morning. Preview was green before dinner; production changed the next morning. Calling that “a day” would leave out the final part of the work.

I also sat at every gate. This was delegated execution with human decisions, not a site moving itself between hosts.

Separating planning from execution let me assign each part to a model that could do it. It didn't remove the need to check the result or decide when the migration was ready.

Read the two working artefacts

These downloads are the redacted pieces from that build: the host configuration and a slice of the model-routing matrix. Use them to understand the arrangement before adapting it to your own site.

↓wrangler.jsonc (redacted)↓dispatch-matrix slice

Keep one coherent plan, define the gates, and give each worker a bounded result. Then choose a first job whose output you know how to inspect. That's enough to test whether a cheaper execution seat earns its place.

//A<3

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 6