seat pricing or per-task pricing when one account costs me $410 a month in compute Usage-Based

You do not have a pricing model problem, you have one price stretched over two different products. The 900-task account and the 41,000-task account are not buying the same thing.

The shape you want is a platform fee plus an included allowance plus overage. Something like $99/month including 8,000 tasks, then $0.015 per task after. Light accounts pay a floor that covers support and hosting, heavy accounts pay for what they burn, and your margin stops being a lottery ticket on who signs up.

Pure per-task is worse than it looks. Revenue becomes unforecastable, and more importantly customers get afraid of the product. Nobody wants a meter running from unit one, so they use it less, which is the opposite of what you want.

Keep seats for who is allowed to log in and meter the thing that costs you money. Two dials, both of which a finance person can read off an invoice without calling you. Seats-only breaks exactly the way you described, usage-only makes small customers nervous.

Before you redesign anything, find out whether that account is a product bug wearing a costume. 41,000 tasks across 8 seats is 5,125 each. Is a human doing that? Or did somebody wire your API into a loop, or hit a retry path that never terminates?

I would want to see the distribution of those 41,000 by hour before I changed a price.

Or raise the seat price. $12 is a sandwich. If the product is worth $410 of compute to them it is very obviously worth more than $96 to them, and you are the only person in the transaction who thinks otherwise.

Simplest thing: hard cap everyone at 10,000 tasks a month. No pricing redesign, no metering infrastructure, problem gone by Friday.

Budget for the plumbing before you commit. Usage pricing means metering, an idempotent event pipeline, reconciliation, dunning on amounts that change every month, and a support load of "why is this invoice different". Two weeks minimum, and it never fully goes away.