--- title: How to Run Long Unattended Tasks With Gemini 4 Carbon url: "https://goremy.ai/blog/articles/gemini-4-carbon-long-running-agent-tasks" author: Luis Chavez-Mattos editor: Luis Chavez-Mattos editor_title: Director, Product published: "2026-11-12T07:40:09.197Z" updated: "2026-11-12T07:40:09.197Z" topic: AI Agents & Automation description: "Prompt structure for multi-hour Gemini 4 Carbon runs: minimum passes, a state file on disk, and a fresh reviewer every 10 passes, shown with real demos." --- # How to Run Long Unattended Tasks With Gemini 4 Carbon > Prompt structure for multi-hour Gemini 4 Carbon runs: minimum passes, a state file on disk, and a fresh reviewer every 10 passes, shown with real demos. Edited by Luis Chavez-Mattos, Director, Product ยท Published 2026-11-12 ## How do you set up Gemini 4 Carbon for long unattended runs? Put three things in your first prompt: a minimum number of passes, a state file on disk, and a fresh reviewer that scores the work every 10 passes. Without them, a model tends to stop early and hand you a first draft. With them, one creator kept Carbon working for about 20 hours on a single 3D reconstruction, without asking a question. Google says Carbon can run for days on multi-step engineering tasks. The runs described below, all inside Google's Antigravity coding environment, are public evidence of what that looks like. ## TL;DR - **Ask for iterations up front.** If a task is subjective, such as "make it look realistic," set a minimum pass count in the first prompt or the model will stop at the first acceptable draft. - **Keep the run's memory in a file on disk.** Long runs overflow the model's context window many times, so a state file with the current pass and the biggest open problems lets it pick up where it left off. - **Use a cold reviewer.** A fresh sub-agent that sees only the output and a reference, never the plan, scores more honestly than a model grading its own work from memory. - **Give the model a way to see its own work.** Every strong demo had a render step, fixed camera positions and a scoring step. - **Expect the model to build its own checking tools.** In several demos Carbon wrote small programs to audit its output or tested a small case before the full run. - **Keep a human in the loop for the final call.** The model's self-review missed things a person caught, and its own score for the fort was still about 5 out of 10. ## Why do AI models stop early on big tasks? Ask a model for a big project in an ordinary prompt and it usually delivers something plausible and stops. From its side, the task looks finished. For anything where "good" is a matter of judgment (a realistic 3D scene, a polished design, a thorough research report), that first draft is rarely the version you wanted. The creator behind the demos summed up the fix as a prompt that sets expectations for effort and verification. In his tests, a studio visualization and a 3D character runner both started as rough drafts and only got good after 10 or more passes. A "pass" here means the model renders the scene, looks at the pictures, and fixes what looks wrong. ## What are the three parts of a long-run prompt? ### 1. A minimum number of passes State the floor as a number. For the studio planner, the prompt asked for a hyperrealistic version with at least 10 iterations, and Carbon went through 15. For the fort project, the prompt required at least 100 passes and told the model not to ask any questions along the way. This matters most for subjective work. A number gives the model a stopping rule it cannot talk itself out of. ### 2. A state file on disk A context window is the amount of text a model can hold in mind at once. A run that lasts hours will overflow it again and again, and each time the model's working memory resets. The fix is a plain file the model reads at the start of every reset. In the fort run, the state file held the current pass number and the 10 biggest open problems. The model re-reads it, knows where it is, and carries on. This works for other models too, and it is a good habit for any long agent task. ### 3. A fresh reviewer every 10 passes A model that grades its own work from memory tends to be generous. In the fort run, after every pass Carbon rendered the fort from the same camera positions, so each pass could be compared with the last. Every 10 passes it started a new sub-agent that received only the renders placed next to real photographs. That reviewer had never seen the plan or earlier scores, so it scored the replica cold. The scores moved slowly and honestly. They started at 3 out of 10 and were around 5 by the time of recording. On that scale, 3 is roughly a blob and 5 is a model you can recognize as the fort. Photorealism starts around 8. ## What does a prompt template look like? This is a generic template built from those three parts. Replace the bracketed items with your own task. It is not the creator's exact wording. ``` Goal: [describe the finished result and where it should be saved]. Rules: 1. Work for at least [N] passes. A pass means: produce the output, check it against [reference / test / checklist], and fix what is wrong. 2. Do not ask me questions. If something is unknown, make a best guess and label it "inferred" in your notes. 3. Keep a file called STATE.md. After every pass, update it with the current pass number and the 10 biggest open problems. Read it again whenever your context resets. 4. Render or export your output the same way every pass (same camera positions, same test inputs) so passes can be compared. 5. Every 10 passes, start a fresh sub-agent. Give it only the latest output and [the reference]. Do not give it the plan or past scores. Ask it to score from 1 to 10 and list the top problems. Add its findings to STATE.md. 6. Before any large run, test a small case first. ``` ## How did the demos use these rules? **The fort.** The most ambitious run reconstructed a fort in Peshawar, Pakistan, a site with little online documentation. The prompt demanded the most realistic replica possible from public sources only, and barred two well-known 3D tools in favor of an open-source 3D engine released about a month earlier. The first phase had no 3D at all. Carbon logged 30 sources it opened and read, including colonial records from the 1890s, old aerial photographs and satellite imagery it used to measure the walls. It worked out the building history and modeled the walls as British-period brick over an older mud core. Where the public record was silent, it kept a list of unknowns and marked those parts as inferred. When the engine could not do something the fort needed, Carbon went into the engine's source code and extended it. At the time of recording it had made six changes, two of them bug fixes. The run was past 65 passes and about 20 hours in. **The studio.** The creator described a rented room and asked for a 3D setup plan. The first version looked basic, so he asked for a hyperrealistic version with at least 10 iterations. The result was an interactive model where you can switch to a camera's point of view, change the lens and turn lights on and off. He still advised checking any gear suggestions yourself before buying. **The storm in a teacup.** The prompt ended with "use a team of sub-agents." Carbon wrote a shared plan, and also a shared timeline of the storm so every sub-agent knew when lightning strikes. It then split the scene so each sub-agent owned its own files (porcelain, tea surface and lighting, clouds). The project came to almost 13,000 lines of code. The lesson: when you split work across agents, give them the shared facts they all depend on, and give each one its own territory. **The dragon.** A single pass of about 72 minutes produced a dragon defined entirely as a signed distance function (one math formula that says how far any point is from the surface) from a single concept image. No long loop was needed here, which shows that not every task needs 100 passes. ## How does the model check its own work? The most transferable habit in these demos is that Carbon built tools to audit itself. When the 3D runner's legs looked jittery, Carbon did not patch the animation by eye. It wrote a small program that stepped through the tour frame by frame and flagged sudden jumps in the character and camera movement, then fixed the walk cycle. On the creator's GPU machine (a small DGX Spark cluster), Carbon ran a galaxy collision simulation with more than half a million stars. It simulated a single galaxy first to confirm the setup was stable. In a second task, it trained a four-legged robot with reinforcement learning (a method where software learns by trial and error). On reviewing its own video, it noticed the robot ran off the edge of the floor, extended the floor and rendered the video again. You can ask for the same behavior directly: test a small case first, review your own outputs afterward, and write a check you can rerun. ## Where does Carbon still need help? - **Its own scoring is not a verdict.** The fort sat at about 5 out of 10 by its own reviewer's score. The creator also had to point out the jitter in the runner. - **Output limits apply.** In a no-tools test where Carbon wrote the roughly 20,000 weights of a small neural network in a single reply, it played Breakout well, averaging 217 points per game. On harder games it hit the reply limit on all four attempts. At high effort it spent the whole reply on thinking, so the creator used medium effort. - **Tools matter.** That test had no ability to run anything. The creator's point was that in a coding agent like Antigravity, the same model is far more capable. - **Verify what affects money or safety.** Gear lists, measurements and research claims should be checked by a person. - **A disclosure worth knowing.** The creator said he recently joined Google and was given early access by Google DeepMind, and that the views are his own. Treat the demos as a strong example, not a controlled benchmark. ## What does this mean for you? If you work in marketing, finance, operations or HR, you probably will not be rendering forts. But the pattern carries over to any task that is too big for one sitting: a competitor review, a data cleanup, a long document set to summarize, a report with many sections. - **Decide what "done" means before you start.** A pass count, a checklist or a reference example gives the model something to measure against. - **Make the work visible.** Ask for outputs saved in files you can open, plus a running notes file that lists open problems. - **Add a skeptical second reader.** A reviewer that sees only the result and the standard, not the reasoning, catches more. - **Check in at the end, not every hour.** Read the state file and the reviewer's last report, then give targeted feedback, as the creator did with the jittery legs. ## Could you build a tracker for these long runs yourself? If you start running several long jobs, the state files, reviewer scores and open-problem lists pile up fast. You could keep them in a spreadsheet, or describe a small internal tool to [Remy](https://goremy.ai), which builds and deploys full-stack apps from a plain-English description. For example: a run log where each task has a goal, a pass count, a score history and an open-issues list, with a form for adding your own review notes and a dashboard showing which runs need attention. You own the result instead of renting another subscription. ## Frequently Asked Questions ### How long can Gemini 4 Carbon run on its own? Google says Carbon can run for days on multi-step engineering tasks. In the demos described here, the longest run had been going about 20 hours at the time of recording and was still improving. Your results will depend on the task and the tools you give it. ### Do I need Antigravity to use these techniques? The demos all ran in Antigravity, Google's agentic coding system, where the model could search the web, write code and run it. The prompt structure (minimum passes, state file, cold reviewer) is not tied to one product, but you do need an environment where the model can run code and save files. ### What is a cold reviewer? A cold reviewer is a fresh sub-agent that receives only the current output and a reference, such as real photographs. It has never seen the plan or earlier scores, so it cannot grade on memory or goodwill. In the fort run, one was started every 10 passes. ### Why use a state file instead of relying on the chat history? A long run overflows the model's context window many times, and the model loses earlier details each time. A file on disk survives those resets. It should hold the current pass and the biggest open problems so the model can re-read it and continue. ### Is a high pass count always better? No. The dragon came out of a single 72-minute pass. Use high minimums for subjective work where quality builds over iterations, and keep simpler tasks simple.