A Toggle Is Not an Explanation

I was looking at Vercel's Fluid Compute setting because my bill had gone up, and the first question seemed simple: is it cheaper to leave it on or turn it off?

The answer was not simple. Fluid Compute is usually cheaper, except when it is not. It depends on how much time a function spends actually using the CPU, how much time it spends waiting for a database or another API, how much memory it needs, how long it runs, how many requests arrive together, which region it runs in and probably a few other things I had not thought about before opening the settings page.

But in the interface, all of this becomes a toggle.

Fluid Compute: on or off.

The toggle makes the decision look much more certain than it is. It suggests that there are two stable states and that I only need to choose the correct one. But I am not really choosing whether I want Fluid Compute. I am choosing a pricing and execution model for a workload whose future behaviour I do not fully understand.

That is a very different decision.

"Fluid Compute" is also the name of the mechanism, not the consequence. It tells me what Vercel calls the feature, but not what turning it on will do to my bill, performance, function duration, cold starts, concurrency or ability to debug something when it goes wrong.

This happens a lot in software. The interface exposes the internal concept directly and assumes that control is the same as understanding. There is a toggle, so technically the user is in control. But the user may have no realistic way to predict what either option will do.

Vercel has much more information than I do. It knows how my functions behaved during the last week or month. It knows how much time they spent computing and how much time they spent waiting. It knows their memory use, duration, traffic and concurrency. It could probably show me something like:

"Based on your last 30 days of usage, Fluid Compute would have cost between €8 and €11 less."

Or:

"Your workload is mostly CPU-bound, so turning Fluid Compute off may be cheaper."

That would still contain uncertainty, but it would be useful uncertainty. It would help me make a decision based on my application rather than on a generic documentation page.

Instead, the uncertainty is transferred to me. I am expected to understand Vercel's billing system, understand my own architecture, predict future traffic, estimate the cost difference, make the change and then remember to return later to check whether it worked.

This is not necessarily bad because the system is complicated. Complicated systems cannot always be reduced to one clean answer. The problem is that the interface hides the complication while leaving the risk with the user.

A toggle is especially strange here because toggles feel deterministic. Dark mode will be on or off. Notifications will arrive or not arrive. Fluid Compute will not produce one predictable outcome. The result depends on conditions that continue changing after I press the button.

It is closer to choosing an investment strategy than changing a preference.

This is where usability becomes less about making a control easy to operate and more about helping someone act under uncertainty. The toggle itself is perfectly usable. I know how to click it. The harder question is whether I understand enough to click it responsibly.

Good interfaces for uncertain decisions should probably do more than explain the feature. They should show the likely outcome, how confident the system is, what assumptions the estimate is based on and what could cause the result to change.

They should also make the decision feel reversible.

Instead of only offering on and off, Vercel could offer something like:

"Try Fluid Compute for seven days. We will compare cost and performance with your previous usage."

After the test, it could explain what happened:

"Fluid Compute saved an estimated €4.80 because 71% of your function duration was spent waiting for external services."

Now the user is not being asked to predict a complicated system in advance. The interface turns the choice into an experiment and helps the user build a better mental model from the result.

This also changes the role of feedback. Normally, feedback means that I click a button and see that the setting has changed. But for a decision like this, the real feedback may only become visible days later. Did it reduce cost? Did anything become slower? Did a function unexpectedly keep running for several minutes? Did my usage change so much that the original recommendation no longer applies?

A small success message saying "Fluid Compute enabled" answers almost none of these questions.

Cloud products are full of decisions like this. Autoscaling, caching, function regions, database sizes, model selection, retention periods, spending limits. The interfaces expose increasingly powerful infrastructure choices, but the consequences are often delayed, conditional and difficult to observe.

There is another layer of uncertainty here. Vercel's current Fluid Compute model separates Active CPU from Provisioned Memory. CPU billing pauses while a function is waiting for external services, but memory remains provisioned while requests are still in flight. This is a more precise way to charge for work, but it is also a more complicated thing to imagine. The final cost does not belong to one visible duration. It emerges from several overlapping measurements that behave differently over time.

The interface could translate this into something I can reason about. It could show that my application spent 18 minutes actively computing but remained in memory for two hours because it was waiting on APIs. It could explain which routes caused the difference. It could warn me that one long streamed response is responsible for most of the memory charge. It could tell me whether my cost increased because Fluid Compute was expensive or because a function started behaving differently.

Without this, I may blame the setting for a change caused by my own application. I may also turn the setting off and accidentally make the cost worse. The toggle gives me an action before the system gives me a diagnosis.

This pattern exists far beyond cloud computing. Privacy controls ask me to predict future data use. AI model selectors ask me to trade quality, speed and cost without knowing how difficult my next request will be. Advertising dashboards ask me to set a budget before I know the value of the audience. Health interfaces ask me to interpret measurements that vary naturally from day to day. In all of these cases, the user is not selecting a stable preference. The user is making a bet.

The interface rarely says that.

Maybe the next step in cloud UX is not simplifying all of these systems into more toggles. Maybe it is designing interfaces that admit uncertainty instead of pretending the uncertainty disappeared when the setting received a name.

The real question was never whether I wanted Fluid Compute turned on.

The question was: given how my application actually behaves, which option is likely to be safer and cheaper, how certain is that estimate, and how will I know later whether it was correct?

That is the decision the interface should have helped me make.

Connected reading

• Some Apps Explain Themselves
• The Most Dangerous Interface Is the One That Says Everything Worked
• Every Interface Contains a Business Model
• The Interface Is Now Part of the Answer

AI authorship note

This essay began with Kris Haamer noticing that Vercel presents Fluid Compute as a simple on-or-off setting even though its cost depends on workload behaviour. AI supported verification of Vercel's current pricing model, development of the argument around uncertainty and reversibility, drafting, editing and implementation. Kris directed the article toward the broader interaction-design problem: interfaces often expose control without explaining the consequences of using it, then leave the user responsible for uncertainty the system could have reduced.