Pith. sign in

REVIEW 3 major objections 5 minor 48 references

VoyagerVision: Investigating the Role of Multi-modal Information for Open-ended Learning Systems

T0 review · 3 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Adding screenshots to the Voyager Minecraft agent enables building tasks it previously could not attempt.

desk verdict The system convincingly builds simple Minecraft structures, but the paper's central claim that screenshots enable this is confounded by simultaneous changes to model and prompts. read the letter →

arxiv 2507.00079 v1 pith:LLM2QALS submitted 2025-06-29 cs.AI cs.LG

Ethan Smyth , Alessandro Suglia This is my paper
classification cs.AIcs.LG
keywords multimodalagentsMinecraftVoyageropen-endedlearningvisualfeedbackGPT-4oembodiedAIconstructiontasks
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper extends the Voyager open-ended Minecraft agent—normally limited to textual inputs—with agent-perspective screenshots, creating a multimodal version called VoyagerVision. The authors claim this visual feedback lets the agent complete a new class of construction tasks, such as poles, walls, stairs, pyramids, and nether portals, that text-only Voyager could not perform. In unit tests, the system was manually verified successful in 18 of 50 build attempts, with most successes in flat worlds. In open-ended runs of 50 iterations, it averaged 2.75 unique structures per run while still gathering resources. If the claim holds, adding a camera to an open-ended text agent is a low-cost route to spatial task competence.

What carries the argument

The mechanism is the Voyager loop itself—curriculum agent proposes a task, action agent generates Mineflayer JavaScript, critic agent verifies success and critiques failures, with successful code stored in a skill library—modified so that every agent also receives a screenshot of the bot's current point of view. A camera from Prismarine-Viewer is placed at the bot's head position and orientation each round to produce the screenshot. The critic is told to use the screenshot as its primary means of checking spatial and building tasks, and the action agent is instructed to reposition itself, often on a dirt pole, to give the critic an unobstructed view of the finished build. These visual inputs are what the paper identifies as making construction tasks feasible.

What would settle it

Run the same building unit tests and open-ended building prompts with GPT-4o but no screenshots, keeping the VoyagerVision prompts and scaffolding rules; if the no-vision agent builds the same structures at a similar rate, the visual input is not what unlocks the new task class.

Watch

Extended reading notes

Core claim

The central claim is that multimodal input—screenshots of the bot's point of view fed to all three Voyager agents—expands an open-ended learning system's task repertoire to include visual and spatial construction. The paper reports that VoyagerVision built an average of 2.75 novel structures per 50-iteration open-ended run, at a 39% average success rate on building tasks, and that in hand-verified building unit tests it succeeded in 18 of 50 attempts (12 of 25 in flat worlds; 6 of 25 in regular worlds). It further reports that switching Voyager's text-only GPT-4 to GPT-4o alone slowed resource gathering, while adding screenshots produced no further degradation. The paper interprets these results as demonstrating the value of multimodal integration for open-endedness.

Load-bearing premise

The building gains are attributed to screenshots, but the full system differs from Voyager in three ways at once—the model, the prompts, and the visual input—so the experiment cannot show which change enables building.

Editorial extensions

If this is right

  • Text-only Voyager-style agents can be extended to construction tasks by adding screenshots, without changing the underlying skill-library and self-verification architecture.
  • Vision does not appear to hurt the original resource-gathering capability: the GPT-4o-with-screenshots variant reached iron pickaxe at the same iteration count as the GPT-4o text-only variant in the paper's 30-iteration runs.
  • The agent's building competence is sensitive to terrain: success roughly doubled in flat worlds relative to regular worlds, so handling irregular ground is a separate challenge from vision.
  • The model's own visual self-verification is not fully reliable, since manual review showed 2 of 20 reported unit-test successes were false positives, so deployment of such agents would still need external checking.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because the full system differs from Voyager in model, prompts, and visual input simultaneously, the paper does not establish that screenshots specifically cause the building gains; a text-only GPT-4o run with the same building prompts is needed to attribute the effect.
  • Averaging 2.75 unique structures per run means the agent is producing a small set of varied builds, not sustained open-ended invention; measuring structural novelty (geometry or function) rather than distinct task names would test the open-endedness claim.
  • If screenshots are the enabling cue, the critic's visual verification is the most likely load-bearing component; ablating screenshots from just the action and curriculum agents while keeping them for the critic would localize where the vision matters.
  • The scaffolding and re-positioning rules added to the prompts may themselves be doing much of the work; a follow-up that strips those prompt changes while retaining screenshots would separate prompt engineering from perception.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper introduces VoyagerVision, a multimodal extension of the Voyager Minecraft agent that adds agent-perspective screenshots to the LLM input pipeline and replaces GPT-4 with GPT-4o. The authors claim that visual input enables the agent to complete building tasks that were previously infeasible for the text-only Voyager. They evaluate the system in two phases: (1) building unit tests for five structures (pole, wall, stairs, portal, pyramid) in flat and regular worlds, with 18 of 50 attempts verified as true successes by manual inspection; and (2) open-ended experiments, including resource-gathering runs with and without screenshots and 12 open-ended building runs, where the agent completed an average of 2.75 unique structures per 50-iteration run.

Significance. If the central causal claim were established, this work would be a useful demonstration that adding visual feedback can expand the task repertoire of an open-ended embodied agent, with possible relevance beyond Minecraft. The paper has notable strengths: the authors report manual verification of unit-test outcomes, transparently disclose that the critic's self-verification produced false positives (pyramid: 3 reported vs 2 true in flat worlds; 1 reported vs 0 true in regular worlds), and append the full prompts for all system variants, which aids reproducibility. However, the headline claim that visual input itself enables building is not supported by the current experimental design, because the full system differs from Voyager in model, modality, and prompts simultaneously, and no text-only GPT-4o building control is run. The contribution is therefore best viewed as a promising system demonstration with an unresolved attribution question.

major comments (3)
  1. [Section 1, Section 4.2, Abstract] The central causal claim that adding visual input enables building tasks is confounded by three simultaneous changes between Voyager and VoyagerVision: the model (GPT-4o vs GPT-4), the input modality (screenshots added), and the task prompts (building encouragement added, and the original instruction 'Do not ask me to build or dig shelter' removed). Section 4.2 compares resource-gathering performance with and without screenshots, but the open-ended building experiment is run only on the full VoyagerVision system. There is no text-only GPT-4o condition with the same building-oriented prompts. Therefore, the observed ability to build structures cannot be attributed to the visual modality; a text-only GPT-4o agent given the same building prompts might perform similarly. The abstract and Section 1 overstate the evidence when they say visual inputs 'enable' the new class of tasks.
  2. [Appendix D, Abstract, Section 1] The claim that Voyager 'was incapable of this' is not evidence of a modality limitation, because the original Voyager curriculum prompt explicitly forbids building, placing, planting, and trading tasks (Appendix D, original prompt criteria 7 and 8). The inability to build in the original system is a prompt-design choice, not a demonstrated consequence of text-only input. The manuscript should either soften the causal language or run a controlled baseline with building-oriented prompts and no screenshots to establish the modality's contribution.
  3. [Section 4.2, Table 1, Section 4.1] The open-ended building metrics rely on the critic agent's self-verification, but Table 1 shows that this same critic over-reports building success in the unit tests: it reported 3 pyramid successes in flat worlds where only 2 were true, and 1 in regular worlds where 0 were true, inflating the overall reported total from 18 to 20 true successes. Section 4.2 reports an average of 2.75 unique structures per run without any manual verification or false-positive analysis for the open-ended building experiment. The true success count could be lower, and the paper should either provide manual verification for open-ended runs or explicitly acknowledge this limitation when reporting the 2.75 figure.
minor comments (5)
  1. [Table 1] The column header 'Overrall World Sucess Rate' contains two spelling errors ('Overrall', 'Sucess'); it should be 'Overall World Success Rate'.
  2. [Table 2 caption] The caption contains 'interations', which should be 'iterations'.
  3. [Abstract] The abstract states VoyagerVision was 'successful in half of all attempts in flat worlds,' but Table 1 reports 13/25 reported and 12/25 true successes in flat worlds. The phrasing is imprecise and should reflect the true verified count (12/25).
  4. [Section 4.2, Table 3] The open-ended building results are aggregated over 12 runs with no per-run breakdown, variance, or confidence interval. Given the small sample, the paper would benefit from at least reporting the range of unique structures per run.
  5. [Section 3.2] The appendix text describing the critic prompt says the response must end with ')' but the example JSON ends with '}'; this appears to be a typo and should be corrected.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation found; the building-capability comparison is confounded but not circular.

full rationale

This paper contains no mathematical derivation chain in which an output is defined in terms of itself. The central claim—that adding screenshots to Voyager enables building tasks—is an empirical claim supported by three open-ended experiments and unit tests. No parameter is fitted to a subset and then reported as a prediction; no uniqueness theorem from the authors' prior work is imported; no ansatz is smuggled in via citation; and no known result is merely renamed. The only self-citation (Suglia et al., 2020) appears in the general background and is not load-bearing. The original Voyager prompts are quoted in the appendices, so the comparison is transparent. Two concerns are validity issues rather than circularity: (1) the final open-ended building experiment changes model, prompt, and modality simultaneously relative to original Voyager, so the causal role of screenshots is not isolated; the paper itself acknowledges that the GPT-4o drop 'could potentially be due to the fact that the prompts written for the original Voyager maximised performance for GPT-4.' (2) The critic agent's self-verification over-reported pyramid successes (4 vs 2) in unit tests, and manual checks corrected those unit tests, but the open-ended unique-structure counts in Table 3 are not reported as manually verified. These are measurement and internal-validity weaknesses, not circular reductions of the claim to its inputs. Therefore the circularity score is 0.

Assumptions & free parameters 3 free parameters · 3 assumptions · 0 invented entities

No fitted model parameters are present; the ledger contains only hand-chosen evaluation budgets and background assumptions about the Minecraft and Voyager stack. The central claim rests on a domain assumption that GPT-4o interprets screenshots well enough to verify builds, which is not independently evidenced in the paper.

free parameters (3)
  • Maximum task attempts = 3
    Failure threshold in the action loop, inherited from default Voyager and not varied here. It determines which tasks count as failed in the open-ended evaluation.
  • Open-ended building horizon = 50 iterations
    Budget for the open-ended building evaluation; the reported average of 2.75 unique structures is measured within this horizon and would likely change with a different budget.
  • Resource-gathering cutoff = 30 iterations
    Manual cutoff chosen because original Voyager reaches iron tools in 21 iterations; runs exceeding 30 count as failure to match performance.
assumptions (3)
  • domain assumption The Voyager framework works as described in [13] when reimplemented with GPT-4o and the appended prompts.
    The evaluation assumes the Mineflayer, Prismarine-Viewer, and skill library stack replicates Voyager's behavior; no code is shipped to verify this.
  • domain assumption GPT-4o can reliably interpret Minecraft point-of-view screenshots for spatial verification.
    The entire critic and building loop depends on this capability; Section 3.1 assumes screenshots provide sufficient information for spatial reasoning.
  • domain assumption Manual verification of unit-test outcomes is accurate and complete.
    Section 4.1 states results are verified manually, but no logs, world states, or screenshots are released for independent audit.

how reviews work

0 comments
Cite this review

Pith. "Pith review of VoyagerVision: Investigating the Role of Multi-modal Information for Open-ended Learning Systems." pith.science (2026). https://pith.science/paper/LLM2QALS

@misc{pith2026250700079,
  author       = {Pith},
  title        = {Pith review of: VoyagerVision: Investigating the Role of Multi-modal Information for Open-ended Learning Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LLM2QALS}},
  note         = {Machine review of arXiv:2507.00079}
}
read the original abstract

Open-endedness is an active field of research in the pursuit of capable Artificial General Intelligence (AGI), allowing models to pursue tasks of their own choosing. Simultaneously, recent advancements in Large Language Models (LLMs) such as GPT-4o [9] have allowed such models to be capable of interpreting image inputs. Implementations such as OMNI-EPIC [4] have made use of such features, providing an LLM with pixel data of an agent's POV to parse the environment and allow it to solve tasks. This paper proposes that providing these visual inputs to a model gives it greater ability to interpret spatial environments, and as such, can increase the number of tasks it can successfully perform, extending its open-ended potential. To this aim, this paper proposes VoyagerVision -- a multi-modal model capable of creating structures within Minecraft using screenshots as a form of visual feedback, building on the foundation of Voyager. VoyagerVision was capable of creating an average of 2.75 unique structures within fifty iterations of the system, as Voyager was incapable of this, it is an extension in an entirely new direction. Additionally, in a set of building unit tests VoyagerVision was successful in half of all attempts in flat worlds, with most failures arising in more complex structures. Project website is available at https://esmyth-dev.github.io/VoyagerVision.github.io/

Figures

Figures reproduced from arXiv: 2507.00079 by the authors.

Figure 1
Figure 1. In this paper, we present VoyagerVision, the first Embodied Multimodal AI agent able to learn to solve both resource gathering tasks as well as novel building tasks such as poles, walls, and pyramids. This work explores Voyager [13], an open-ended Minecraft agent initially limited to text inputs due to prior LLM constraints. As such, motivating this project to enhance Voyager with screenshot inputs to integrate the … view at source ↗
Figure 2
Figure 2. Voyager Overview - Voyager iteratively creates and pursues new tasks, success￾ful task solutions are stored in the skill library for later use. All tasks are self-verified by the critic agent, failed tasks are re-attempted using the critic agent’s feedback. [13, p. 2] Voyager is made up of three agents: – A curriculum agent which decides which task to pursue next based on current environment information including su… view at source ↗
Figure 3
Figure 3. VoyagerVision Overview- curriculum agent proposes tasks (after completion of initial task), action agent generates code to complete tasks and critic agent verifies task success environment. Following this, the critic agent verifies the success of the task. For resource gathering tasks, the textual environment information, such as nearby blocks and what is currently in the agent’s inventory, is likely to be sufficien… view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Example of input provided to the critic agent following completion of the ”pole” structure. The critic agent uses this multimodal information to decide whether the task is complete. 3.2 Updated Model The version of GPT-4 [1] used in the default Voyager was only compati…
Figure 5
Figure 5. Figure 5: Pole Build [PITH_FULL_IMAGE:figures/full_fig_p013_5.png]
Figure 6
Figure 6. Figure 6: Wall Build [PITH_FULL_IMAGE:figures/full_fig_p014_6.png]
Figure 7
Figure 7. Figure 7: Stairs Build [PITH_FULL_IMAGE:figures/full_fig_p014_7.png]
Figure 8
Figure 8. Figure 8: Pyramid Build [PITH_FULL_IMAGE:figures/full_fig_p015_8.png]
Figure 9
Figure 9. Figure 9: Nether Portal Build B Appendix: Unit Tests Prompts For each of the unit tests a defined prompt was given, replacing the curriculum agent. This allowed consistent review of the agent’s performance [PITH_FULL_IMAGE:figures/full_fig_p015_9.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

48 extracted references · 35 canonical work pages

  1. [1]

    Gpt-4 technical report

    Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Floren- cia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, and Shyamal Anadkat. Gpt-4 technical report. arXiv preprint arXiv:2303.08774 , 2023

    arXiv 2023

  2. [2]

    Molmo and pixmo: Open weights and open data for state-of-the-art multimodal models

    Matt Deitke, Christopher Clark, Sangho Lee, Rohun Tripathi, Yue Yang, Jae Sung Park, Mohammadreza Salehi, Niklas Muennighoff, Kyle Lo, and Luca Soldaini. Molmo and pixmo: Open weights and open data for state-of-the-art multimodal models. arXiv preprint arXiv:2409.17146 , 2024

    arXiv 2024

  3. [3]

    Gpts are gpts: An early look at the labor market impact potential of large language models

    Tyna Eloundou, Sam Manning, Pamela Mishkin, and Daniel Rock. Gpts are gpts: An early look at the labor market impact potential of large language models. arXiv preprint arXiv:2303.10130, 2023

    arXiv 2023

  4. [4]

    Omni-epic: Open- endedness via models of human notions of interestingness with environments pro- grammed in code

    Maxence Faldor, Jenny Zhang, Antoine Cully, and Jeff Clune. Omni-epic: Open- endedness via models of human notions of interestingness with environments pro- grammed in code. arXiv preprint arXiv:2405.15568 , 2024

    arXiv 2024

  5. [5]

    Minedojo: Building open-ended embodied agents with internet-scale knowledge

    Linxi Fan, Guanzhi Wang, Yunfan Jiang, Ajay Mandlekar, Yuncong Yang, Haoyi Zhu, Andrew Tang, De-An Huang, Yuke Zhu, and Anima Anandkumar. Minedojo: Building open-ended embodied agents with internet-scale knowledge. Advances in Neural Information Processing Systems , 35:18343–18362, 2022

    work page 2022

  6. [6]

    The llama 3 herd of models

    Aaron Grattafiori, Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Alex Vaughan, et al. The llama 3 herd of models. arXiv preprint arXiv:2407.21783 , 2024

    arXiv 2024

  7. [7]

    Open-endedness is essential for artificial superhuman intelligence

    Edward Hughes, Michael Dennis, Jack Parker-Holder, Feryal Behbahani, Aditi Mavalankar, Yuge Shi, Tom Schaul, and Tim Rocktaschel. Open-endedness is essential for artificial superhuman intelligence. arXiv preprint arXiv:2406.04268 , 2024

    arXiv 2024

  8. [8]

    Position: Levels of agi for operationalizing progress on the path to agi

    Meredith Ringel Morris, Jascha Sohl-Dickstein, Noah Fiedel, Tris Warkentin, Allan Dafoe, Aleksandra Faust, Clement Farabet, and Shane Legg. Position: Levels of agi for operationalizing progress on the path to agi. In Forty-first International Conference on Machine Learning , 2024

    work page 2024

Show all 48 references
  1. [9]

    Hello gpt-4o

    OpenAI. Hello gpt-4o. https://openai.com/index/hello-gpt-4o/, 2024. Accessed: 2024-11-12

    2024

  2. [10]

    Prismarinejs/mineflayer: Create Minecraft bots with a powerful, stable, and high-level JavaScript API, 2013

    PrismarineJS. Prismarinejs/mineflayer: Create Minecraft bots with a powerful, stable, and high-level JavaScript API, 2013

    2013

  3. [11]

    Mastering atari, go, chess and shogi by planning with a learned model

    Julian Schrittwieser, Ioannis Antonoglou, Thomas Hubert, Karen Simonyan, Lau- rent Sifre, Simon Schmitt, Arthur Guez, Edward Lockhart, Demis Hassabis, Thore Graepel, et al. Mastering atari, go, chess and shogi by planning with a learned model. Nature, 588(7839):604–609, 2020

    2020

  4. [12]

    Compguesswhat?!: A multi- task evaluation framework for grounded language learning

    Alessandro Suglia, Ioannis Konstas, Andrea Vanzo, Emanuele Bastianelli, Desmond Elliott, Stella Frank, and Oliver Lemon. Compguesswhat?!: A multi- task evaluation framework for grounded language learning. In Proceedings of the 58th Annual Meeting of the Association for Computa...

    2020

  5. [13]

    Voyager: An open-ended embodied agent with large language models

    Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar. Voyager: An open-ended embodied agent with large language models. arXiv preprint arXiv:2305.16291 , 2023

    2023 arXiv

  6. [14]

    ‘ { ”reasoning

    Jenny Zhang, Joel Lehman, Kenneth Stanley, and Jeff Clune. Omni: Open- endedness via models of human notions of interestingness. arXiv preprint arXiv:2306.01711, 2023. A Appendix: Unit Test Building Tasks Below are example screenshots of the buildings used for each of the unit...

    2023 arXiv

  7. [17]

    It should be a single phrase

    The next task should follow a concise format, such as ”Mine [quantity] [block]”, ”Craft [quantity] [item]”, ”Smelt [quantity] [item]”, ”Kill 26 Ethan Smyth, Alessandro Suglia [quantity] [mob]”, ”Cook [quantity] [food]”, ”Equip [item]” etc. It should be a single phrase. Do not ...

  8. [18]

    The next task should not be too hard since I may not have completed enough very basic structures to be able to attempt it

  9. [19]

    I should build some- thing which is a small step forward from what I have built previously

    The next task should be novel and interesting. I should build some- thing which is a small step forward from what I have built previously. I should not be doing the same thing over and over again

  10. [20]

    Only repeat tasks if necessary

  11. [21]

    You should ensure I always have at least 16 blocks of dirt in my inventory before a building task to be used as scaffolding, otherwise I may be unable to complete the build

  12. [22]

    11 logs and already have 4 the tasks should still be gather 11 logs as the logs in your inventory will be accounted for

    If you need a certain amount of blocks i.e. 11 logs and already have 4 the tasks should still be gather 11 logs as the logs in your inventory will be accounted for. You should only respond in the format as described below: RESPONSE FORMAT: Reasoning: Based on the information I...

  13. [30]

    For instance, ”Placing 4 torches” and ”Dig a 2x1x2 hole” are not ideal since they require visual confirmation from the screen

    Tasks that require information beyond the player’s status to verify should be avoided. For instance, ”Placing 4 torches” and ”Dig a 2x1x2 hole” are not ideal since they require visual confirmation from the screen. 28 Ethan Smyth, Alessandro Suglia All the placing, building, pl...

  14. [31]

    You should act as a mentor and guide me to the next task based on my current learning progress

  15. [32]

    Please be very specific about what resources I need to collect, what I need to craft, or what mobs I need to kill

  16. [33]

    It should be a single phrase

    The next task should follow a concise format, such as ”Mine [quantity] [block]”, ”Craft [quantity] [item]”, ”Smelt [quantity] [item]”, ”Kill [quantity] [mob]”, ”Cook [quantity] [food]”, ”Equip [item]” etc. It should be a single phrase. Do not propose multiple tasks at the same...

  17. [34]

    The next task should not be too hard since I may not have the necessary resources or have learned enough skills to complete it yet

  18. [35]

    I should look for rare resources, upgrade my equipment and tools using better materials, and discover new things

    The next task should be novel and interesting. I should look for rare resources, upgrade my equipment and tools using better materials, and discover new things. I should not be doing the same thing over and over again

  19. [36]

    Only repeat tasks if necessary

    I may sometimes need to repeat some tasks if I need to collect more resources to complete more difficult tasks. Only repeat tasks if necessary

  20. [37]

    I want to explore the world and discover new things

    Do not ask me to build or dig shelter even if it’s at night. I want to explore the world and discover new things. I don’t want to stay in one place

  21. [38]

    For instance, ”Placing 4 torches” and ”Dig a 2x1x2 hole” are not ideal since they require visual confirmation from the screen

    Tasks that require information beyond the player’s status to verify should be avoided. For instance, ”Placing 4 torches” and ”Dig a 2x1x2 hole” are not ideal since they require visual confirmation from the screen. All the placing, building, planting, and trading tasks should b...

  22. [39]

    You should only respond in the format as described below: RESPONSE FORMAT: Reasoning: Based on the information I listed above, do reasoning about what the next task should be

    Crafting a crafting table should be one of my first goals once I have enough wood to do so, I cannot craft any tools without a crafting table. You should only respond in the format as described below: RESPONSE FORMAT: Reasoning: Based on the information I listed above, do reas...

  23. [51]

    a furnace, it is crucial that you place the crafting table prior to attempting to craft

    If a recipe requires a crafting table e.g. a furnace, it is crucial that you place the crafting table prior to attempting to craft

  24. [52]

    If you complete a building task, it is imperative that you position yourself at least 4 blocks away, additionally you must elevate yourself two blocks off of the ground on a dirt pole, stand on this pole and then look at what you just built

  25. [53]

    32 Ethan Smyth, Alessandro Suglia

    When you aim to verify a build, always ensure there are no blocks blocking your view between you and the block you are trying to look at, relocate if there are blocks in the way. 32 Ethan Smyth, Alessandro Suglia

  26. [54]

    If for any reason you fail a building task, on your next attempt you should attempt to view it from a different position than any you have used before

  27. [55]

    Ensure to position yourself in an open flat area before beginning a building task. You should only respond in the format as described below: RESPONSE FORMAT: {response format} Additionally, if for any reason you are not able to assist with a re- quest you must explicitly detai...

  28. [66]

    Name your function in a meaningful way (can infer the task from the name). 34 Ethan Smyth, Alessandro Suglia You should only respond in the format as described below: RESPONSE FORMAT: {response format} Below is the tweaked version of the original Voyager prompt, this version c...

  29. [67]

    Write an async function taking the bot as the only argument

  30. [68]

    - Use ‘mineBlock(bot, name, count)‘ to collect blocks

    Reuse the above useful programs as much as possible. - Use ‘mineBlock(bot, name, count)‘ to collect blocks. Do not use ‘bot.dig‘ directly. - Use ‘craftItem(bot, name, count)‘ to craft items. Do not use ‘bot.craft‘ or ‘bot.recipesFor‘ directly. - Use ‘smeltItem(bot, name count)...

  31. [69]

    Therefore, you should make it generic and reusable

    Your function will be reused for building more complex functions. Therefore, you should make it generic and reusable. You should not make strong assumption about the inventory (as it may be changed at a later time), and therefore you should always check whether you have the re...

  32. [70]

    Do not reuse functions listed there

    Functions in the ”Code from the last round” section will not be saved or executed. Do not reuse functions listed there

  33. [71]

    Anything defined outside a function will be ignored, define all your variables inside your functions

  34. [72]

    Call ‘bot.chat‘ to show the intermediate progress

  35. [73]

    You should frequently call this before mining blocks or killing mobs

    Use ‘exploreUntil(bot, direction, maxDistance, callback)‘ when you cannot find something. You should frequently call this before mining blocks or killing mobs. You should select a direction at random every time instead of constantly using (1, 0, 1)

  36. [74]

    Do not cheat

    ‘maxDistance‘ should always be 32 for ‘bot.findBlocks‘ and ‘bot.findBlock‘. Do not cheat

  37. [75]

    Do not write infinite loops or recursive functions

  38. [76]

    You definitely do not need them

    Do not use ‘bot.on‘ or ‘bot.once‘ to register event listeners. You definitely do not need them

  39. [77]

    Name your function in a meaningful way (can infer the task from the name)

  40. [78]

    a furnace, it is crucial that you place the crafting table prior to attempting to craft

    If a recipe requires a crafting table e.g. a furnace, it is crucial that you place the crafting table prior to attempting to craft. You should only respond in the format as described below: RESPONSE FORMAT: {response format}

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.