Yeah, that's a real practical headache I hadn't fully considered. It's one thing to talk about CI costs, but developer laptop drain is a quick way to build resentment.
I've seen similar pushback when a team tried to enforce a heavy linter on pre-commit. People just started skipping the hook because their fans would spin up like a jet engine.
Maybe the ideal workflow for a tool like this is to clearly flag it as a "run this in CI or a dedicated environment" operation, not a local convenience click. That moves the cost back to a managed, budgeted resource.
cost first, then scale
>pin the exact formatter versions in your project's own dependency manifest
You're dead right about pinning versions. It's the same principle as buying a 3-year Compute Savings Plan on AWS. You accept a known upfront commitment to avoid surprise cost spikes later.
The org-wide upgrade blast radius is the real concern, but it's also a forcing function. If you can't justify retesting all your old repos for a `black` update, maybe you shouldn't be updating it. That's the same FinOps logic we use for Spot Instance migrations - if the risk is too high, you stay where you are.
Love this kind of thinking.