Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product.
Last post, my four-laptop render farm lost a race against my own laptop.
I promised you the ending.
Here it is.
It involves a free farm run by strangers and a Java file called sheepit-autoupdate.jar.
The lesson I was too slow to learn
If you missed it, last time we turned four laptops into a Flamenco render farm.
It worked.
And then the farm spent almost all of its time downloading a 115 MB .blend over my 5 Mbit/s home upload, while my laptop finished the job alone.
The takeaway was one sentence:
A render farm is a file distribution problem wearing a GPU costume.
So the question for round two was not "where do I find more GPUs".
It was "who can I hand a file to once, and have it spread out without my upload being the highway".
Meet the flock
SheepIt is a free, community-powered render farm for Blender.
The deal is beautifully simple.
You install a small client on your machine.
While your machine is idle, it renders other people's frames.
That earns you points.
You spend the points to have the community render yours.
Everyone lends a machine, everyone gets frames.
I did not build a farm.
I joined a flock.
The client is a single Java jar (sheepit-autoupdate.jar, which updates itself, hence the name), and the upload side is a web page where you drop a zip.
That is the entire infrastructure I had to run.
No Samba, no tailnet, no NAT archaeology.
The file goes to one place, and it is their problem to hand it to a hundred machines.
Points: the currency of the flock
SheepIt runs on points.
You earn them by rendering other people's frames.
You spend them when you order your own.
The core loop needs no money, just render time in and render time out.
I registered on October 10th, the same Saturday the laptop farm gave up, and left the client running.
Here is our profile a few days later:
Let me read that back to you.
Our laptops spent 2 days and 7 hours rendering strangers' frames.
That is 6,981 frames for other people.
And in return I ordered 18,651 frames across 17 projects.
I ordered almost three times as many frames as I rendered, and the balance still says 1,261,589 points.
I cannot give you SheepIt's exact exchange rate, so treat this as an observation, not a formula.
As far as I can tell, a light 360p frame is cheap to order, a heavy 1080p ray traced frame costs more, and a stronger GPU earns faster.
What I can show you is the shape of it:
The points line only goes up.
Four days of render streaks, and I never ran dry.
The frames line flattens after the first couple of days, which is my guess for the laptop getting busier with my own work.
That is the part I did not expect.
I thought I was borrowing a farm.
I was joining a barter economy where the same laptop that edits Miles during the day renders somebody else's sheep at night.
Everyone is the customer and the supplier at the same time.
The catch: strangers cannot run your scripts
There is exactly one thing SheepIt asks of you, and it is the whole engineering problem.
Your .blend has to run on a machine you have never seen, unattended, with none of your project around it.
My scenes were not built for that.
They are built by Python scripts that load a city, retarget animations, key thousands of values and bake the result into a .blend.
On my laptop that file leans on a whole project folder:
Absolute paths to textures, like /home/lovestaco/pers/lr_demo/....
Image sequences for the animated screens in the city (the bugs board, the queue counters).
Sound strips for the voice-over.
Render settings that my own scripts apply at render time.
A stranger's machine has none of that.
It cannot run my scripts, so settings I apply from code simply never happen.
So I wrote a packer, sheepit_pack.py, whose job is to turn a built scene into a hermetic one:
Pack every image into the .blend.
Textures travel inside the file now.
Copy image sequences next to it with relative paths.
Blender cannot pack a sequence, so the folder rides along in the zip and the paths become //assets/....
Drop the sound strips.
The voice-over and sound effects are mixed later with ffmpeg anyway, so the farm never needs them.
Bake the settings into the file.
1920x1080 at 100%, 64 samples, ray tracing at full resolution, motion blur on, PNG output.
Then zip it with the .blend at the root.
My zips came out between 130 and 240 MB.
SheepIt takes up to 2 GB, so that is a comfortable fit.
Trust nothing, verify everything
Here is the thing about sending your scene to strangers.
If it is broken, you find out hours later, when a stranger's machine has already burned your points on a hundred identical black frames.
So every package goes through a gate before it leaves my laptop.
flowchart LR
A[Built .blend] --> B[Pack<br/>images, relative paths, baked settings]
B --> C[Zip<br/>blend at the root]
C --> D[Extract into a clean folder]
D --> E{Verify<br/>paths, settings, no sound}
E -->|fail| X[Fix and repack]
E -->|pass| F[Render 1 or 2 test frames<br/>from the extracted copy]
F --> G[Upload the zip]
G --> H[Community renders]
H --> I[Download the frames zip]
I --> J{Frame check<br/>count, gaps, size, black frames}
J -->|fail| Y[Re-queue those frames]
J -->|pass| K[Assemble with audio and subtitles]
classDef decision fill:#f4d35e,stroke:#b8991f,color:#1a1a1a
classDef mine fill:#5ee6c8,stroke:#1f9c86,color:#1a1a1a
classDef farm fill:#9d8cff,stroke:#5b4bcc,color:#1a1a1a
classDef bad fill:#ff9a5c,stroke:#c4642a,color:#1a1a1a
class E,J decision
class A,B,C,D,F,K mine
class G,H,I farm
class X,Y badThe important part is the extraction.
I do not test the original .blend.
I unzip the package into a fresh temporary folder, the way the farm will see it, and run the checks there.
Every external file must exist and be a relative path.
No sound strips may be left.
The resolution, samples, ray tracing, motion blur and PNG format must all match what I think I baked.
Then I render one or two real frames from that extracted copy, with the baked settings.
If those frames look right, the package is right.
On my GTX 1650 those test frames take between 7 and 35 seconds at 1080p.
Which is a quick way to tell the difference between "this will take a day" and "this will take a week" before anyone else spends a point on it.
I run it as one command per part, and it stops with a loud error at the first problem.
It also never deletes anything.
An old package is moved aside, not overwritten.
The bug where the file was fine and the check was wrong
The first time I ran the new packager for part 1, it died at the zip step with ERROR: street_part_1_final.blend is not at the zip root.
It was at the zip root.
I looked at the zip.
The file was right there, first entry.
The check looked like this, with the fix underneath:
set -euo pipefail
# broken: dies on SIGPIPE even though the file is in the zip
unzip -Z1 "$ZIP" | grep -qx "street_part_1_final.blend" || die "not at the zip root"
# fixed: capture first, then grep
LIST=$(unzip -Z1 "$ZIP")
grep -qx "street_part_1_final.blend" <<<"$LIST" || die "not at the zip root"
grep -q is polite about one thing: the moment it finds a match, it exits.
That leaves unzip writing the rest of the file list into a pipe nobody is reading, so it gets SIGPIPE.
And pipefail says that if any stage of the pipe fails, the whole pipe failed.
So the file was found, and the check reported it missing.
The fix is to stop piping.
If you ever write producer | grep -q under set -o pipefail, remember this.
It works until the producer has more output than the pipe buffer, and then it fails on the one day it matters.
Render only what the film keeps
This part is satisfying.
The film is not one long take.
Parts of the Blender scenes are cut from the final video (we removed a mural scene, the LED ticker and a subway lightbox), and the 2D product boards in part 3 are not rendered in Blender at all.
If you upload a scene and ask for "frame 1 to the end", the community renders all of that for you, for free, and you throw half of it away.
Rude to the sheep.
So each package gets uploaded with exactly the frame ranges the film needs.
Part 0 is one range, 458 frames.
Part 1 is three ranges, because three scenes are cut.
That skips about 535 frames that never reach the final video.
Part 2 is one range, 2,441 frames.
Part 3 is the same zip uploaded twice, frames 1 to 664 and 2150 to 3661.
The 2D boards sitting between them come from a Python script on my laptop in a couple of minutes.
The whole film is 8,229 frames, or 4 minutes 34 seconds.
Last post I said 7,300.
The film grew.
Films do that.
Assembling what comes back
Each part comes home as a zip of PNG frames.
A 1080p part is between 2 and 4 GB.
I do not trust anything that arrives from a farm of strangers.
So before a single frame goes into a video, a check script looks at the zip:
Is the zip intact?
Is the frame count exactly what the build says it should be, numbered from the first frame to the last, with no gaps and no extras?
Does every PNG decode, at exactly the expected size?
Is any frame entirely black?
An all-black frame is the farm's way of telling you that a worker had a bad day.
If everything passes, the frames are hard-linked into a numbered folder (no copies, so a 4 GB set costs nothing extra), ffmpeg encodes the base video, and my assembly script mixes in the voice-over, sound effects, music, subtitles and the frame-number burn-in.
That last one is for the team.
When someone says "the thing at f 1201 is off", I can find it.
Stale frames beat missing frames
My render scripts skip frames that already exist, which is wonderful when a long render gets interrupted.
It is terrible after you change the scene.
Stale frames from the old version sit in the folder, the renderer says "already done", and your new film has the old shot spliced in.
The rule I follow now: when the scene changes, the old frame folder gets moved aside (not deleted, never wiped), and the render starts into a clean one.
A draft at home, the real thing at the farm
Here is the workflow that has been settled for the project, and it is the actual answer to the render bill from last post.
Drafts are local.
360p, EEVEE, no ray tracing, no motion blur.
About 0.7 seconds per frame, so part 2's 2,441 frames take roughly 30 minutes.
The whole film is about two hours.
Make chai, come back, watch Miles.
Finals are on the farm.
1080p, 64 samples, ray traced reflections, motion blur.
A day of laptop time, spread across a flock that does not need me.
And between them sits the thing that makes drafts useful: a review copy the team can actually open.
Did Miles get his 1080p?
Yes.
Two of the four parts have already come home at 1080p from the flock, a 2 GB zip of PNGs for the opening and 3.7 GB for part 2.
Then the team's notes arrived and the film changed under them.
So there is a fresh set of packages sitting verified and ready for the community, each one with a test frame already rendered from the extracted copy.
What I would tell last week's me
Do not build a farm when a community already runs one.
Four laptops taught me a lot about networking.
A flock taught me that I had been solving the wrong problem.
Make your scene hermetic before you make it fast.
If the file only works on your machine, it works on one machine.
Verify the package, not the original.
Extract it into a clean folder and render a frame from that.
Keep a cheap draft loop.
It is the thing that lets a teammate say "this word is wrong" without it costing you a day.
And a thank you to the strangers whose GPUs are going to render the final.
You are not a sheep.
You are the shepherd.
I would love to hear from you in the comments.
Have you ever lent your machine to a community farm, or used a community compute network, for a project?
Follow along, because next time I will show you the final cut.
Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production secure and reliable without slowing you down.
I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.
Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.
Spend code review effort where business risk is highest — not spread evenly across every diff.
⭐ Star it on GitHub:
HexmosTech
/
LiveReview
Risk-Aware AI Code Review for Business-Critical Systems
LiveReview: Risk-Aware AI Code Review for Business-Critical Systems
LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.
The exact math, not a black box
Visualize blast radius at a glance
Every factor that feeds the score
Here's the goal:
- A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.
- A 300-line UI change in one file, fully covered by tests…
Click below to try LiveReview with your codebase:
Top comments (0)