Open models or a paid API: the calculation that decides it
The calculation that killed a feature in our product took fifteen minutes. A ready made background removal service costs around 20 cents per image. A user uploads roughly fifty items of clothing. That is about ten dollars per person just to prepare pictures, against annual revenue per user in the region of two dollars.
At that point the technology choice stops being a technology question.
Count cost per user, not cost per call
A price per API call tells you nothing until it is multiplied by behaviour. The same twenty cent operation is trivial for one product and ruinous for another, and the only difference is how many times a single user triggers it.
So the comparison always reduces to two numbers in the same units: what you earn per active user per period, and what you spend on them over the same period. If the second exceeds the first, growth increases losses, and no amount of code optimisation changes that.
What self hosting changed
In our case background removal runs on BiRefNet, an open model under the MIT licence, hosted on our own server. Attribute recognition uses marqo-fashionSigLIP, also open, under Apache 2.0.
The economics change shape. Instead of paying per image, there is a fixed rental of roughly six thousand roubles a month, and the cost of one operation drops to fractions of a cent. The more users, the lower the per operation cost, so spending stops growing linearly with the audience.
The honest downside: fixed rental is paid when you have few users too. Early on that is more expensive than per call pricing. The switching point sits exactly where the monthly rental equals the sum of per call charges.
What we deliberately did not do
We did not train our own model. Background removal and attribute recognition are solved problems, and our own model would have cost months for equivalent quality. What has to be yours is the part nobody sells: in our case the algorithm that matches an outfit to a specific wardrobe.
We did not use a foreign cloud backend. Personal data of Russian citizens flows through the system, and the law requires it to be recorded and stored in databases located in Russia, while popular foreign platforms have no Russian regions. That question was settled by hosting before model selection even started.
We did not leave expensive operations unlimited. This is a separate principle: a cheap operation can be unlimited, an expensive one becomes the product’s currency. If generating an image costs whole roubles and processing an uploaded photo costs a fraction of a kopeck, the second is unlimited and the first runs on a counter. Otherwise your most active users are your most expensive ones.
Three questions before choosing
How many operations does one active user trigger per month. Without that number there is nothing to compare.
Are there data constraints. Personal data, medical or banking secrecy, or a clause in a client contract can close off an external service regardless of price.
Who maintains the server. An open model is not only a licence, it is updates, monitoring and being on call. Without that person, fixed rental becomes hidden debt that comes due at the worst possible moment.
A practical sequence
Start with a paid API while the user base is small: you pay only for what is used and you validate the idea faster. In parallel, calculate the point where per call pricing exceeds rental, and agree in advance that the migration happens when that point is reached rather than after the first invoice that upsets you.
For the migration to be possible at all, isolate the model behind your own interface from day one: product code calls your processing function, never the vendor directly. That is a few hours of work at the start and weeks saved later. Without it, the cost calculation is academic, because the migration will simply never happen.
FAQ
When is a paid API the better choice
When volume is low and irregular, when the paid model is meaningfully better than the open one, and when nobody on the team will maintain a server. Fixed rental only wins under steady load.
Should we train our own model
Almost never. Background removal and attribute recognition are solved problems, and training your own would take months for the same quality. Build your own only what does not exist ready made, which is usually the logic on top of the models.
What about data residency
If personal data of Russian citizens passes through the service, the law requires it to be recorded and stored in databases located in Russia, and popular foreign platforms have no Russian regions. That constraint is solved by where you host, not by which model you pick.
How should the cost be calculated
In the same units as revenue: per active user per period. A price per call means nothing until it is multiplied by how many calls one user makes in a month or a year.