Honest answer first: we don't run a CI matrix, so I can't hand you a threshold I've actually validated at that shape. What we measured was one repo, cold, on a schedule — and the number came out large enough that the question stopped being how to tune it and became which runs deserve the context at all.

The split that has held for us is by cost-of-being-wrong rather than by token count. A run that writes something — commits, publishes, changes state — gets the full load, because a retry there isn't just tokens, it's an artifact someone has to unwind. A run that only reads, and whose output a human reviews anyway, gets --bare with the two or three facts it needs pasted straight into the prompt.

That slightly inverts your framing: instead of starting from the tax and asking when it's worth paying, start from what a wrong answer costs and let that pick. The jobs where nobody would catch the mistake are the ones where the overhead is cheapest relative to what it prevents.

The one part I'd gently push back on is waiting for the monthly bill to force it. In our case the bill wasn't what surfaced it — noticing that an unattended run was loading far more than it could possibly use was. If you want something concrete to measure: run one of your matrix jobs both ways, cold and --bare with the context pasted in, and compare retries rather than tokens. If --bare costs you no retries on that job, the load was never buying you anything there.

What's the shape of your matrix — mostly the same prompt across many targets, or genuinely different jobs? Those two pull in fairly different directions on this.