Workspace Index › Dev Notes › 3,500 lanterns nobody asked for — Blender agents and the underspecification benchmark
#168PoC
3,500 lanterns nobody asked for — Blender agents and the underspecification benchmark
Two frontier agents were given Blender: one built 3,500 lanterns nobody requested ("see how far I can go unprompted"), the other finished fast and showed something presentable first. Both reasoned well — which is exactly why capability wasn't the interesting axis. An open-ended creative tool makes every spec incomplete, and what an agent does with that slack — over-build, show early, or ask — is a design temperament you can measure.
Directly runnable — the setup is an evening, the experiment is a prompt.
Wire Fable to Blender. The standard path is blender-mcp: an MCP server plus a Blender addon that opens a socket into Blender's Python API (bpy), so the agent sends real commands — create objects, assign materials, set cameras, render. Install Blender, add the addon, register the MCP server with Claude Code, and confirm with a "make a cube and render it" smoke test. (Headless alternative: have the agent write a bpy script and run blender --background --python scene.py — simpler, no live loop.)
Run the underspecification test. Give the identical, deliberately open prompt — "make a beautiful night scene with lanterns" — to each agent/model you want to compare, and do not clarify. Record four numbers: time to first render, count of unrequested elements (the lantern number), tokens/cost burned (a 3,500-object loop is a paid loop — the-price-cut-names-the-customer's cache economics decide what it costs), and quality-of-response to one round of feedback ("fewer lanterns, warmer light").
Score temperament, not beauty. The rubric: did it ask, show early, or over-build? Which default do you actually want for interactive work versus overnight batch art? The deliverable is that rubric filled in — per model, per task class.
Source: shared SNS review of Astra vs. Fable 5.1 driving Blender, 2026-09-06.
Why
When both agents are smart, the benchmark moves to what they do with slack. "Make a night scene" underdetermines almost everything — count, mood, when to stop. The 3,500 lanterns are not a bug: they are one answer to the question every open task silently asks, how much of the unspecified space do I own? One temperament fills the slack with initiative (impressive, expensive, occasionally exactly what you wanted); the other optimizes time-to-first-showable and hands the slack back to you as a feedback opportunity. Neither is wrong — but they suit different work, and a benchmark that only scores the final render never sees the difference.
For interactive work, show-early usually wins, and the reason is the loop. A first render in two minutes converts the human into the missing part of the spec: "fewer lanterns, warmer light" after a quick look beats any amount of unprompted elaboration, because the agent's model of your intent is weakest exactly where the spec was silent. This is demonstration-is-not-a-specification running in reverse — an agent treating a vague request as license to demonstrate is manufacturing spec where none was given. And over-delivery has a bill: thousands of unrequested objects are thousands of paid tool-loop iterations, the precise cost structure the cache-read repricing targets.
Blender is a better agent lab than it looks. It is a full professional tool with a complete Python surface (bpy), so the agent isn't clicking pixels (agents-computer-use's hard mode) but issuing real API commands with verifiable results — object counts, render times, scene graphs you can assert on. That makes temperament measurable: the same open prompt, four numbers, a rubric. the-harness-not-the-model said the differentiation lives in the harness; this card is a concrete, cheap harness experiment anyone can run in an evening — and the SNS post's conclusion ("both excellent!") is precisely the non-measurement the rubric replaces.
How it works
The wiring options
Path
How it works
Fits
blender-mcp
MCP server + Blender addon socket → live bpy commands
Interactive agent sessions, the full loop
Headless script
Agent writes a bpy script → blender --background --python
CI-able, deterministic, no live feedback
Screenshot driving
Agent reads renders, clicks UI
agents-computer-use hard mode — avoid unless that's the point
The two temperaments, observed
Over-deliverer (the 3,500 lanterns)
Show-first
Fills slack with
Initiative and elaboration
A reviewable draft
First visible result
Late, spectacular
Minutes, modest
Cost profile
Thousands of paid loop iterations
Small until feedback arrives
Fails when
You wanted control of the spec
You wanted to be surprised
Right for
Overnight batch art, exploration
Interactive collaboration — most real work
The four numbers to record per run
Time to first render a human can react to.
Unrequested-element count (the lantern number).
Tokens and tool-loop iterations burned.
Response quality to one feedback round — does the correction land without collateral rework?
프런티어 에이전트 둘에게 블렌더를 맡겼더니: 하나는 아무도 부탁하지 않은 등불을 3,500개 지었고("말 안 해도 여기까지 한다"), 다른 하나는 재빨리 끝내고 먼저 보여줄 수 있는 것을 내놓았습니다. 둘 다 추론은 훌륭했고 — 바로 그래서 능력은 흥미로운 축이 아니었습니다. 열린 창작 도구는 모든 명세를 불완전하게 만들고, 에이전트가 그 여백으로 무엇을 하는가 — 과잉 구축, 조기 공개, 질문 — 는 측정 가능한 설계 기질입니다.
즉시 실행 가능 — 셋업은 하룻저녁, 실험은 프롬프트 하나입니다.
Fable 을 블렌더에 배선. 표준 경로는 blender-mcp: MCP 서버 + 블렌더 애드온이 블렌더의 Python API(bpy)로 소켓을 열어, 에이전트가 실제 명령 — 오브젝트 생성, 머티리얼 지정, 카메라 설정, 렌더 — 을 보냅니다. 블렌더 설치, 애드온 추가, Claude Code 에 MCP 서버 등록 후 "큐브 하나 만들고 렌더" 스모크 테스트로 확인합니다. (헤드리스 대안: 에이전트에게 bpy 스크립트를 쓰게 하고 blender --background --python scene.py 실행 — 더 단순하고 라이브 루프가 없습니다.)
미명세 시험 실행. 비교할 에이전트/모델마다 동일하고 의도적으로 열린 프롬프트 — "등불이 있는 아름다운 밤 풍경을 만들어 줘" — 를 주고 명확히 해 주지 않습니다. 숫자 넷을 기록합니다: 첫 렌더까지의 시간, 부탁하지 않은 요소의 개수(등불 수), 태운 토큰/비용(3,500 오브젝트 루프는 유료 루프입니다 — the-price-cut-names-the-customer 의 캐시 경제학이 값을 정합니다), 그리고 피드백 한 번("등불 줄이고 빛은 따뜻하게")에 대한 반응 품질.
아름다움이 아니라 기질을 채점. 루브릭: 물었는가, 일찍 보여줬는가, 과잉 구축했는가? 대화형 작업 대 밤샘 배치 아트에서 실제로 원하는 기본값은 어느 쪽인가? 산출물은 모델별·작업 종류별로 채워진 그 루브릭입니다.
출처: 아스트라 대 Fable 5.1 블렌더 조작 SNS 후기 공유, 2026-09-06.
왜
둘 다 똑똑하면, 벤치마크는 여백을 다루는 방식으로 옮겨 갑니다. "밤 풍경을 만들어 줘"는 거의 모든 것을 미결정으로 남깁니다 — 개수, 분위기, 멈출 시점. 등불 3,500개는 버그가 아닙니다: 모든 열린 작업이 조용히 던지는 질문 — 명세되지 않은 공간을 내가 얼마나 소유하는가? — 에 대한 하나의 답입니다. 한 기질은 여백을 주도권으로 채우고(인상적, 비싸고, 가끔은 정확히 원하던 것), 다른 기질은 첫 공개까지의 시간을 최적화하며 여백을 피드백 기회로 되돌려 줍니다. 어느 쪽도 틀리지 않지만 — 어울리는 일이 다르고, 최종 렌더만 채점하는 벤치마크는 그 차이를 영영 못 봅니다.
대화형 작업에서는 조기 공개가 대개 이기고, 이유는 루프입니다. 2분 만의 첫 렌더는 사람을 명세의 빠진 부분으로 전환합니다: 흘낏 본 뒤의 "등불 줄이고 빛은 따뜻하게"가 어떤 무단 정교화보다 낫습니다 — 에이전트의 의도 모델은 명세가 침묵한 바로 그 지점에서 가장 약하니까. 이것은 demonstration-is-not-a-specification 의 역방향 실행입니다 — 모호한 요청을 시연 면허로 취급하는 에이전트는 주어진 적 없는 명세를 제조하는 중입니다. 그리고 과잉 이행에는 청구서가 있습니다: 부탁하지 않은 수천 오브젝트는 수천 번의 유료 도구 루프 — 캐시 읽기 가격 인하가 겨냥한 바로 그 비용 구조입니다.
블렌더는 보기보다 좋은 에이전트 실험실입니다. 완전한 Python 표면(bpy)을 가진 프로 도구라, 에이전트가 픽셀을 클릭하는 게 아니라(agents-computer-use 의 하드 모드) 검증 가능한 결과가 남는 진짜 API 명령을 내립니다 — 오브젝트 수, 렌더 시간, 단언할 수 있는 씬 그래프. 그래서 기질이 측정 가능해집니다: 같은 열린 프롬프트, 숫자 넷, 루브릭 하나. the-harness-not-the-model 이 차별화는 하네스에 산다고 했는데, 이 카드는 하룻저녁에 누구나 돌릴 수 있는 값싼 하네스 실험이고 — SNS 후기의 결론("둘 다 훌륭!")이 정확히 이 루브릭이 대체하는 비측정입니다.