Google DeepMind’s Minecraft Agents: What the Run Shows Builders

The paper identifies privileged game-state access, prior Minecraft knowledge and frequent failures as limitations. Its approximate $520 estimate covers the players through the win at introductory public API rates; the full session, including observation and later activity, is estimated at $810. Those are list-price estimates, not measured serving costs or SJolt quotes.

• Original paper, methods, cost scope and limitations

For a useful comparison, keep the environment, tools, success condition and accounting period together. A completion time alone does not tell you how another agent would perform under a different observation interface or retry policy. Request the corresponding details before comparing a headline with your own workflow.

Mineflayer’s own documentation describes a JavaScript library with entity and block information, inventory handling, crafting, digging and chat. Its examples are event-driven programs, and pathfinding is listed as a separate plugin. The library supplies access to the environment; an application still decides what to attempt, how to interpret errors and when to stop.

• Mineflayer documentation and examples

For a new agent project, draw three boxes before choosing a model: the planner that proposes work, the adapter that performs an allowed action, and the evaluator that checks the resulting state. Define the data crossing each boundary. If a proposed action cannot be represented in the adapter’s documented contract, the planner must revise the plan rather than invent a successful tool result.

A model API call does not automatically provide a persistent workspace, shared memory, a game connection or an observer. Those are application responsibilities. Keep the tool manifest with each experiment so a future change in permissions or helper code does not get mistaken for a model improvement.

Here is an original test design for a media application. Give two workers three approved image briefs and a shared queue. Each brief requires one accepted output. Use invented task responses and local placeholder files first, so retry behavior can be checked without spending on generation. These fixtures test your controller; they do not measure a model’s creative quality.

Make claim acquisition atomic in your own queue. A worker reading an unclaimed row is not enough: another worker may read the same row before either writes. Use a conditional update against the expected revision, and let only the successful claimant submit. This is an application design recommendation, not an SJolt API feature.

A lease expiration also needs a policy. If a worker disappears after receiving a task ID, a replacement can continue status queries for that task. If submission may have succeeded but no ID was recorded, label the attempt unresolved and reconcile it before automatically submitting again. Do not assume a provider offers idempotency merely because your application has an attempt identifier.

The following is a proposed application record, not an API request or an actual completed job. It links the approved brief to one attempt and keeps provider execution separate from editorial acceptance.

{
  "brief_id": "enclosure-front",
  "brief_revision": 3,
  "attempt_id": "attempt-002",
  "owner": "worker-a",
  "external_task_id": null,
  "execution_state": "not_submitted",
  "output_file": null,
  "review_state": "not_reviewed"
}

On restart, reconstruct the next action from this record and the authoritative task status. Do not infer completion from a worker’s prose summary. Preserve the prior attempt if a new revision supersedes it; an old response should remain inspectable without becoming the selected deliverable.

Test one interruption at each boundary: before submission, after submission, after receiving an ID, after success and during review. For each case, specify whether recovery queries, waits, reconciles or intentionally starts new work. Count duplicate submissions and accepted outputs across the entire fixture, including restarts.

Ask a reviewing worker to inspect evidence rather than repeat the planner’s conclusion. For a front-view enclosure brief, it should compare visible ports, silhouette and requested framing with the approved reference. It should separately check that the chosen file belongs to the active attempt. This separates a visually plausible image from a correctly tracked deliverable.

Keep human review at the point where the artifact is accepted or released. A reviewer should be able to return a concrete rejection such as “left-side vent missing” or “output belongs to revision two,” instead of an untestable overall confidence score. Record review time and rejected attempts when evaluating the workflow’s cost.

SJolt currently lists Gemini 4 Argon with Chat Completions and native Gemini API routes. The public Chat model ID is google/gemini-4-argon. That provides model access; it does not include the paper’s Minecraft environment, coding-agent harness or shared-memory system. Use the model guide for the supported input and continuation contracts.

• Gemini 4 Argon on SJolt
• Argon API setup and pricing guide
• SJolt generation and task-status API

If the approved plan later calls for an image, submit through a documented media route and retain data.task_id. The media status contract distinguishes running, succeeded and failed states. A language-model message that says an asset is ready does not change that task state.

Move from fixtures to a deliberately bounded real evaluation only after recovery and duplicate-submission checks pass. Measure complete accepted briefs, total usage and review effort under the same conditions. This article used source review and offline contract inspection, with no game run, model call or paid generation.