Sheets 20 million cells: how many Sume jobs can a ledger hold?

How many Sume jobs can one Google Sheets ledger hold now that the cell limit doubled? Divide 20,000,000 by your column count. Google's announcement says a spreadsheet can hold up to 20 million cells, up from 10 million, for new, existing and imported files, rolling out from September 10 for Rapid Release and September 28 for Scheduled Release (read 2026-10-04). With a six-column ledger that is about 3.3 million job rows, far more than most teams will ever submit.

The better question is whether a sheet should be the record at all. This post does the arithmetic, then says where the authoritative copy lives.

The row arithmetic

The limit counts cells across the whole spreadsheet, not per tab, so every tab, helper column and empty-but-allocated cell competes for the same total. Divide by the number of columns in your widest ledger tab, then leave room for other tabs.

The figures below assume every column is filled for every row, which is the worst case. They are plain division of the limit Google states, rounded down.

What the announcement does not say

The post is about the spreadsheet's cell ceiling. It says nothing about Apps Script runtime or UrlFetchApp quotas, or about how fast a script can read and write a very large range. A sheet that is legal at 3 million rows may still be slow to scan, so plan to read only the rows you need, such as those without a result yet.

Do not assume the larger limit lifts any script quota. The post on UrlFetchApp limits and Sume bulk runs covers those separately.

The sheet is a view, not the ledger

Sume keeps the record of your jobs. GET /v1/jobs lists them, and GET /v1/jobs/:id/status and /result give the state and artifacts, all free reads. If the sheet and the API disagree, the API is right. That lets you treat the sheet as a working view you can rebuild, which removes the pressure to keep every historical row in it.

Spend is the same. GET /v1/usage and GET /v1/balance are free reads for what you have used and what remains. A sheet column for cost is a convenience copy; reconcile it against usage rather than trusting a sum of cells.

A practical layout

Keep the active tab small: only jobs that are not yet terminal, plus the last few days. Archive finished jobs by exporting them and clearing the rows, which keeps scans fast and the cell count low. Terminal statuses are completed, failed and canceled, so a row in any of those is safe to archive once its artifact URL is saved elsewhere.

Store the idempotency key you sent in its own column. If a script run stops halfway, re-running it with the same keys returns the original jobs instead of creating duplicates. For a fuller ledger design in code, see a cost ledger keyed on the job id, and for the export side, exporting usage to CSV. A longer walkthrough of driving jobs from a sheet is in bulk AI videos with Apps Script.

const columns = [6, 8, 12, 20];
for (const c of columns) {
  console.log(c + ' columns -> ' + Math.floor(20000000 / c) + ' rows');
}