Test a cloud AI agent in a throwaway repo before overnight work

You can leave a cloud agent on a task while you sleep, but the failure mode usually arrives after you stop watching: a half-finished task, a permission prompt, or compute still being billed. A throwaway repo lets you see that before it costs you a real service or a real budget.

Use a repo you can delete: no production secrets, no customer data, no shared branches. You want session continuity, billing behavior, and interruption patterns under conditions close to real work, without creating extra work.

Prove the agent survives the unattended stretch

Run the same task twice: once while you are present, once while your laptop is closed or the machine is off. Write the starting state down before the run. The task should be small but multi-step: fix a failing test, add a doc page, or refactor a function. Skip code-quality judgment for now; the question is whether the agent survives the gap between human attention and machine execution.

The checks follow the failure modes they expose: resume catches context loss, sleep catches local dependency, billing catches unexpected cost, identity catches missing approval, and interruptions catch the need for manual confirmation.

• Resume after shutdown: Stop the session mid-task, then check whether the next prompt restores the last useful state.
• Run while the machine sleeps: Close the laptop and confirm the session continues from the cloud console.
• Find the billing source: Identify where compute is charged before the run, then note the entitlement or account balance.
• Test the admin and identity gate: In an organization-owned repo, confirm whether an administrator must enable a policy before the agent can run and be billed to the organization.
• Count interruptions: Track every prompt for permission, missing credential, ambiguous instruction, or manual confirmation.

If any check fails, do not move to a real repo; the test is only useful if the result can veto the rollout.

The Copilot setup is new enough to verify, not assume

GitHub's connected Copilot cloud experience and its cloud sandboxes are generally available to customers on paid Copilot plans. Rollout to paid Copilot plan users started on October 28. The timing matters: the feature is new enough that your team may still be finding the edges.

GitHub moved Actions from a fixed standard-runner-minute allotment to a shared dollar-based compute entitlement. Copilot cloud sandbox charges start in November 2026 and come out of the included Actions entitlement.

You need Visual Studio Code 1.144 plus the chat.automations.cloud.enabled setting turned on before Copilot cloud automations start. Shared Copilot Automations are reaching Copilot Pro, Pro+, Max, Business, and Enterprise plan subscribers. In an org-owned repo, shared Copilot Automations require an admin to switch on the policy that lets the cloud agent bill the organization.

Turn the result into a veto, not a vibe

Write down the result before you clean up the repo. A clean run can still hide a missing approval, a hidden cost, or a session that cannot resume after a crash. The test is about operational risk, not code style.

If the agent resumes cleanly, runs after your machine sleeps, and stays inside a known billing path, it has earned a second trial. That second trial should be a small real task in a low-risk repo, with a human reviewing the diff before merge. If it needs constant hand-holding, keep it in the throwaway repo.

For a technical lead, the decision is whether the agent can be left alone without creating a support ticket, a billing question, or a security exception. The throwaway repo makes that answerable before an incident. Record the interruption count next to the diff: a low count means the agent can handle routine ambiguity, while a high count means it will need a human for every edge case. Keep the note with the repo name, task, date, plan, and owner.