I want to be able to run untrusted code in a sandbox such that "while True" won't exhaust my system resources, and with a limit on the amount of memory that the sandboxed program can allocate itself.
On the other hand, it also wouldn't make sense for App Isolation because that's intended to give apps a lightweight way to opt-in to isolating themselves, in order to restrict the blast radius of exploits. It's not intended to let you run arbitrary third party code sandboxed. For that you would need to use something more like the Chromium sandbox that uses kernel job objects, which a sibling comment describes. Using that would require fluency in Win32.
See JOB_OBJECT_LIMIT_PROCESS_MEMORY and JOB_OBJECT_LIMIT_PROCESS_TIME.
Job is basically Windows equivalent of Linux Control Group.
But if you need rate there's this: JOB_OBJECT_ CPU_RATE_CONTROL_MIN_MAX_RATE https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns...
As far as the verbiage goes -- "doesn't exhaust" means "uses less than the full amount available". Given that "total CPU time" isn't something you can run out of, "doesn't exhaust CPU" can only mean "uses less CPU than is currently available", i.e. "utilizes < 100% of the CPU", i.e. throttling.
As a practical matter, pretty much ~no user wants to kill a program after N seconds, and ~no program can limit itself to N seconds of work, either. People just want their CPU to have bandwidth to do other work, avoid heating up, etc. So unless you have a strong reason to believe otherwise, it's fair to assume people want to limit CPU utilization, not total CPU time.
This is exactly how the web and cloud FaaS like AWS Lambda does it, so I don't think it's right to say nobody wants this. Runaway code does need to be killed.
The only trick I have up my sleeve is to use earlyoom to abort misbehaving processes if I suddenly squander all of my ram.