Deccan AI
Dataset delivery

Blender bpy agent episodes

Ten accepted samples of a model writing and running Blender Python step by step. Deccan AI, September 2026.

This is supervised fine-tuning data for a tool-calling coding agent, with Blender as the environment. It is for teams training or evaluating models that write code, execute it, read what comes back and continue. You get ten accepted samples, each with the instruction, the full step trajectory, one runnable script, the saved .blend, harness renders and the verification record, plus the task bundle each was run against, so you can run your own model on the same brief and grade it with the same checks.

In every episode here a model writes Blender Python, executes it in a headless harness, reads the stdout, tracebacks and scene state that come back, and decides its next step. Each of those steps is recorded as it happened. The result is then checked by tooling that does not take the model's word for anything: the scene is re-opened in a fresh Blender, the renders are made by the harness rather than the agent, and the whole script is replayed from scratch to prove it reproduces.

10samples
265recorded tool calls
172machine checks
5.2Mvertices built, 8,886 to 4.2M a scene

The samples

What a sample contains

Instruction

The brief, as pinned in the sample beside the checks and the rubric it was graded by.

Trajectory

Every step in order: the code the model wrote, what Blender returned, and its own commentary between steps.

Script

Every executed step concatenated into one runnable file. The same code as the trajectory, not rewritten.

Scene

The saved .blend as the model left it.

Renders

Hero image, turntable views, a composed shot set, orthographic elevations for five of the ten, and an animation preview or frames where the task moves.

Verification

Check results, the replay diff, integrity, the rubric review and the decision, with the copy of the checks that was used.

What you can train

Tool loop

train/agentic_trajectories.jsonl holds one multi-turn row per sample: the brief as a user turn, each assistant turn with its tool call, and each tool result carrying stdout, tracebacks and scene state, so a model learns to act, read and decide again.

Instruction to script

train/instruction_to_script.jsonl pairs each brief with its final_script.py, the executed steps concatenated in order. This is a single-turn target and a different one, and it is labelled as such.

Your own rollouts

samples/<name>/task/ is a complete task: the brief, the start file, the checks and the rubric, pinned as the episode ran. Point your own model at it and grade the result against the same checks these samples were graded against.

Verifier

The checks are declared in checks.json as a type plus parameters, and SCHEMAS.md defines the 33 types used across these ten samples. The executor that reads those files is ours and is not included, so the results in verification/ are reported rather than reproducible with our code. Each type is a deterministic function of a saved .blend and is reimplementable from bpy, so they work as a grader beyond these ten samples once you write the ones you care about.

How a sample is verified

Checks

Run in a fresh Blender against the saved file, using the checks pinned inside the sample.

Renders

Produced by the harness from the saved scene. Nothing the agent rendered is used.

Replay

The whole script re-executed in a clean Blender, and the resulting scene state compared.

Integrity

Trajectory invariants and the hashes of the pinned task files.

Rubric review

A vision language model is shown the harness renders and the written rubric and answers it item by item, using the renders alone. The rubric ships with the sample, so you can run the review with a model of your own rather than take ours.

Human review

A person looks at the renders and the whole record last, and decides whether the sample ships. It is the only layer that is not automated and the only one that can read a reviewer's verdict against the evidence behind it.

How these samples were made

Ten episodes, ten accepted samples. Each shipped sample is the only episode run against the brief and the checks it ships with: none is the best of several draws of the same brief. That is not one run per task. When an episode failed we corrected the brief or a check and ran again, and an episode run against a superseded version of a task was set aside rather than shipped. Four tasks were accepted on the first episode and the rest took between two and six. Six further tasks were authored and run for this round and sit outside this release; five of them had at least one episode pass every automated gate, so the ten here are not simply the tasks a model happened to pass. The step and check totals at the top of this page are summed from manifest.json, and README.md carries the full run history.

Ten tasks is the scale of a production record rather than a benchmark, and the numbers are written to be read that way: an account of how these samples were made, with the checks and the replay behind each one. The rubric review is one model's judgement of how a scene looks, shown the harness renders and the written rubric and nothing the builder said about its own work. The checks and the replay establish that the scene is what the script produced. The review adds an opinion on top of that, and we publish it as exactly that.