# Windows ready is not Excel ready: a 30-cycle resume test Measured stop/resume and Office-readiness results from one retained Panes Windows computer, with the timing boundaries and sample limits exposed. Published 2026-11-15T06:00:00Z by Renaissance Superintelligence Corporation (RSI). In a 30-cycle test on one retained Panes computer, median start-request time was 15.360 seconds. Median time from resume to verified Office work was 29.425 seconds. Measure both: a running Windows VM and a completed application check answer different questions. ## Test the saved state before making new work Each cycle wrote a synthetic file and registry checkpoint, stopped into native S4, resumed, and checked the checkpoint before Office wrote new work. All 30 comparisons matched. The witness included five file hashes and the existing profile/CurrentUser DPAPI state. This makes a persistence claim testable without publishing private profile details. After checking retained state, each cycle tested Office readiness and ran fresh preparation and verification of a small Excel Power Query/VBA, Word and PowerPoint workload. Preparation cleared query output before refresh and reran the VBA marker. The assertions checked the saved Office artifacts rather than accepting cached output alone. The run made 283 API calls with HTTP 200 results and 190 native executions with exit code zero. Those counts describe this test’s completed operations. They are not independent users, independent computers or an estimate of fleet uptime. ## Keep the timing boundaries separate The table reports 30 completed samples per row. The p50 convention is the lower middle value; p95 uses nearest rank. HTTP wall time, positive S4 confirmation, saved-state readiness and verified Office work include different operations. Subtracting one published percentile from another does not produce the percentile of their difference. One retained Windows computer, 30 sequential completed cycles; seconds Boundary | p50 | p95 | Maximum Stop HTTP request | 14.379 | 15.144 | 15.419 Stop to positive native S4 | 14.527 | 15.318 | 15.513 Start HTTP request | 15.360 | 15.878 | 16.017 Resume to saved-state checkpoint ready | 16.695 | 17.206 | 17.459 Resume to Office verified | 29.425 | 53.530 | 55.085 Fresh preparation + verification | 16.194 | 40.193 | 41.350 ## What the difference means for an agent builder A control plane’s running state is useful for scheduling, but a user cares whether the workbook can complete its next operation. Start a workflow timer before the resume request and stop it only after your application-level assertion passes. Keep the infrastructure timer too: it helps locate the delay. For a close workflow, a useful readiness probe might open a small owned workbook, refresh a known local input, check a calculated result and save. Do not let the probe modify the customer’s live workbook. An application check should have its own bounded timeout and a visible result that the agent can inspect. The same distinction applies to screenshots. A desktop image proves the renderer returned pixels. It does not prove Excel has finished a refresh or that a saved deck includes current chart data. Use the screen to inspect the application and use file-level assertions to verify the deliverable. ## Do not turn a same-guest test into a fleet claim Repeated use of one retained machine correlates the samples. It can reveal state drift and repeated stop/resume problems on that machine; it cannot establish behavior across new machines, tenants, add-ins or concurrent workloads. This test did not compare Azure, measure cold-cache startup or evaluate a production availability target. Report the complete denominator. Here, planned, attempted and completed were all 30, with zero failed, uncertain or unattempted cycles in this run. In a different test, show those categories even when they spoil the headline. Keep failed experiments attached to their own scope rather than replacing them with later successful samples. Costs need a separate measurement. The acceptance store used zero-rate intervals, which are not the allocated host cost and cannot establish a retail job price. For a paid evaluation, record actual running intervals and applicable pricing, plus model, storage and backup charges. Neither this latency table nor a demo video supplies that bill. ## Apply the method to your actual Office task Use the [monthly-close case](/examples/excel-to-powerpoint) as a richer application workload: preserve the starting workbook, roll the period, reconcile the model and update the editable deck. Test readiness and recovery before handing the job to an unattended agent. Read the [Windows sandbox evaluation guide](/blog/windows-agent-sandbox-evaluation) for the full acceptance scorecard. Connect your agent through the [Panes docs](/docs#mcp) and compare results under the exact workload, Office version and computer size you intend to use. ## Evidence This is the November 9, 2026 same-guest acceptance run, not a new fleet benchmark. All 30 planned cycles completed. The machine had 4 vCPU and 16 GiB RAM. All samples share one retained guest and profile; no cache flush was performed. The downloadable result is a public projection of the sanitized source evidence. Private acceptance-store zero-rate intervals are not retail costs, so no dollar-per-task result is reported. The monthly-close recording linked below is a separate workflow, not a recording of these 30 cycles. ## Sources - [Download the scoped 30-cycle measurements and method](/research/office-persistence/2026-11-09.json) - [Watch the native Office recording and download the files](/examples/excel-to-powerpoint) - [Pinned workflow source and reproduction instructions](https://github.com/logancsack/panes-office-workflows/tree/0c4f1841e21528ec2fd1210602f361a0d198f1a5/monthly-close) - [Native validation summary](/examples/excel-to-powerpoint/monthly-close/validation.json)