Is there a way to determine the optimal size of a batched transaction to save on fees? I've been looking at other questions about fees and batching, but it seems no one asked if there is some way to determine the optimal size of a transaction to save on fees (assuming all inputs are spending from segwit native UTXOs for simplicity).
To expand a bit on what I have in mind: I need to pay various amounts to different people (let's consider their number can be anywhere between 1 and infinite), and I guess that by making one &quot;big&quot; transaction paying them all at once instead of 1 transaction for each of them I can save on fees. But is it the more people I can add up in the same transaction the better, or would I save less at some point if my transaction keeps getting bigger? Is there some model to calculate the &quot;optimal&quot; size for my batched transaction, or maybe it doesn't make sense?
Here's my best guess for now: adding more people means really adding outputs, which makes the transaction grow linearily (assuming all ouputs are pretty standard and roughly of the same size), so assuming the fees are split between each receivers the more people you can onboard on the same transaction the cheaper it gets for everyone.
But at some point the sum of the amounts of the ouputs will grow bigger than the one input I added at first and I'll need to add another input. If I have relatively big ouputs to spend this is probably ok, but if I only have small outputs and/or I'm adding relatively big amounts in the outputs at some point adding one more output could need to add one or maybe more inputs, making the growth in size transaction not worthing the save in fees, so I'd rather just stop it and send the batch at this point.
[EDIT] I came across this article that seems to confirm what I was thinking, and that all things being equal it will always save fees to add a new output.
But at some point the sum of the amounts of the ouputs will grow bigger than the one input I added at first and I'll need to add another input. If I have relatively big ouputs to spend this is probably ok, but if I only have small outputs and/or I'm adding relatively big amounts in the outputs at some point adding one more output could need to add one or maybe more inputs, making the growth in size transaction not worthing the save in fees, so I'd rather just stop it and send the batch at this point.

The addition of another input does not matter, as it would have to be included in the next transaction too anyway.
In any way, a second stage transaction will always be more costy than a single batching transaction as you would duplicate the (non-witness!) meta bytes (version, n° of input, n° of outputs, locktime, etc..).