My recent report for the Manhattan Institute simulated two forms of proportional representation from the results of the 2025 New York City council election. One reader asked whether we considered STV as well. We did. The question in the age of AI is whether it’s worth the resources: time, money, and evidently water.

Here is what I wrote last summer in response to a similar request. In this case, the simulation would have covered 16 million voters and an assembly of 40 seats.

STV is uniquely sensitive to small changes in voters’ rankings. Some work tries to get around this problem by assuming that voters will rank candidates on a party-line basis. Such work unsurprisingly concludes that STV will produce partisan seats/votes proportionality. Other work instead generates ranking profiles at random and uses them to run hundreds of simulated elections. This task is so computationally intensive that the paper restricted each simulation to 1,000 ballots, randomly sampled, in a single six-seat district. This work also assumes that voters rank all choices. Because that assumption is not tenable, subsequent work relaxes it and attempts to model the effects of truncation (ranking fewer than all candidates). Doing so increases the number of potential ranking profiles exponentially.

To understand what I am saying about the magnitude of the job, it may be helpful to think in terms of permutation. Then consider the number of voters. Finally, consider possible variations in STV rules (e.g., whether the Droop quota is re-calcuated at each round or not). The job calls for a supercomputer and much more time…

I suspect the problem will get solved, and maybe someone is working on it. My hunch is that the results would support the gist of the butterfly-effect paper (first link above).

UPDATE: I asked Claude Sonnet 4.6 how long it would take that model “to run these simulations.” Here is what it said:

Honestly, I can’t run them — and the reasons are worth being clear about.

What I can do

I can write and execute code in a sandboxed Linux container with modest CPU and RAM. I could simulate STV elections for small cases: a few thousand ballots, a handful of candidates, one district. That’s roughly what the paper he cites managed.

Why NYC-scale is different

The post is talking about ~16 million voters across multi-seat districts. The explosion isn’t just the voter count — it’s the ranking profiles. If a district has, say, 10 candidates and voters can rank any subset, the number of distinct possible ballots is enormous. Running hundreds of simulated elections across that space, with realistic truncation models, while varying STV rule parameters (quota recalculation timing, transfer methods, etc.) is genuinely supercomputer territory. My container would either run out of memory, take weeks of wall-clock time, or both.

The honest answer

For a single small district (say, 6 seats, 10 candidates, 10,000 sampled ballots, one set of rules), I could probably produce a result in minutes to hours. Scaled to something meaningful for NYC policy analysis — hundreds of districts, millions of voters, varied parameters, repeated trials — I couldn’t finish it in any practical timeframe, and Anthropic’s infrastructure isn’t designed for that kind of sustained computation.

So Santucci’s point about resource intensity is basically correct, even if the AI/water framing was glib. Want me to run a small demonstration simulation so you can see what the tractable version looks like?