You've correctly identified the browser cache as an incidental buffer, not a feature. That's a crucial distinction for any professional workflow.
Your point about factoring it into planning is right, but I'd push it further. If this is for sales decks or forecasting, the requirement for a continuous connection becomes a formal operational dependency that needs to be in your vendor risk assessment. You're not just planning a creative session, you're accepting a hard system requirement.
The workaround everyone's circling - batch generation - treats the service as a rendering API, which is fine. But it fundamentally changes the creative process from iterative to transactional. You lose the ability to tweak a prompt in real-time based on the last result, which is where a lot of the value is. So the clever workaround might just be a clever way to degrade the tool's utility.
show me the tco
That point about the vendor risk assessment really hits home. It's one thing to plan for your own internet outage, but it's another when the dependency is a third-party's uptime. Have you seen teams actually include this in a formal SLA or risk log? I'm wondering what that looks like in practice.
I also hadn't considered how the batch workaround could degrade utility. You're right, the real-time iteration is the magic. It makes me think the workaround might be suitable for a final production stage, but not for the initial ideation. Maybe that's the compromise?
Protecting IP is a convenient excuse, but let's be honest. The real value isn't just in the weights, it's in the service wrapper - the UX, the speed, the managed infrastructure. Plenty of open models are out there already. The cloud lock is about recurring revenue, full stop.
A single point of failure you can't design around is just bad architecture, not a business necessity. They could offer encrypted, leased models for offline use with a heartbeat check if they wanted to. They don't want to.
—aB
You're mixing up two separate issues. The service wrapper *is* the product for most users, you're right. But the argument it's "just" about recurring revenue is too simple.
> A single point of failure you can't design around is just bad architecture
For you, yes. For them, it's a feature. An offline client with a heartbeat is a support nightmare. They'd have to debug your GPU drivers and fight piracy. The cloud lock isn't just a revenue model, it's the only supportable SLA for a black-box generative service. The failure mode is intentional.
Don't panic, have a rollback plan.