There's quite a few tasks I've found that work like this, although if course most tasks don't and require a much higher degree of interaction. The prime examples are read only audits of very large codebases, and that's what I was was running overnight. One file per subagent, each subagent writes a report with recommendations. Since it's pi and the subagents have very now scope, looking at them they ranged between 7-40k context use per subagent. I've found codex maxes out at about 50 concurrent subagents before I start getting rate limited, so the coordinating session is instructed to run them in batches of 50. My subagent extension is set up to make this as efficient as possible, the subagents can share a prefix and suffix prompt then a list of name + specific prompt in json format.

Overnight it ran ~800 tiny auditors. I then run synthesis on the written audit files, extract bugs, then another round to find which ones have a common source, group them by priority etc.

I've cautiously started doing larger tasks that are not just read only, for example I was dealing with a large codebase full of lint and type errors, so I sent out waves of workers with clear instructions to only fix obvious/trivial issues to and otherwise to append to a todo file for my review. That worked well and cleared a few thousand issues over several hours.

I don't really want to share any other tasks I've worked on this way because it'll draw out the agentic coding sceptics and I'm not interested in defending my workflow.

I'm not the person you asked, but if they're running in their own local hardware, then it might just be a lot slower than what the big providers run their models on. System RAM is a lot cheaper than VRAM, especially if you bought it last year.