AI systems have become strong at reasoning, but AI that operates in devices, vehicles and robots also needs a continuous understanding of what is happening around it: who is present, who is speaking, and when action is needed. In this written Q&A, AI Time Journal asked Dr. Dani Cherkassky, CEO and Co-Founder of Kardome, about the recurring cost of always-on voice interfaces and why he argues that perception should run on the device while deeper reasoning is called from the cloud when needed.
Let's start with the framing that opened this conversation, the "Interface Tax." What do you mean by it, and why does an always-on, cloud-first voice interface become financially unsustainable at scale?
When I talk about the "Interface Tax," I mean the recurring cost of keeping an AI interface continuously available and aware of what is happening around it.
This becomes particularly important as we move from command-based voice interfaces to AI that is always present. Before the system can reason or respond, it needs to continuously determine what is happening in the physical environment: who is speaking, where they are, whether they are addressing the device, what they intend, and whether anything requires action.
If all of that continuous perception and understanding depends on the cloud, every interaction, and potentially every moment leading up to an interaction, creates recurring costs for connectivity, data transfer, processing and inference. Multiply that across millions of devices designed to be used naturally and frequently, and the economics become difficult to sustain.
The answer is not to eliminate the cloud. It is to separate two fundamentally different jobs.
The first is continuous perception and contextual understanding: the intelligence that needs to stay close to the user and operate efficiently on the device. The second is deeper reasoning, which can be activated when it is actually needed and run wherever it can be delivered most effectively.
This division of labor allows AI to be continuously present without continuously paying for its most expensive intelligence. The edge handles what is happening now; deeper reasoning is brought in when the situation requires it.
Break down the economics for us: where do the real costs accumulate in cloud-first voice (continuous audio streaming, per-request inference, data egress, redundancy), and how do they compound as usage grows?
It is not one cost that creates the problem. It is the accumulation.
You have network transport, cloud compute, speech processing, inference calls, storage, observability and redundancy. A single interaction may also pass through several AI services before it reaches a larger model for more complex reasoning.
For occasional voice commands, that can be manageable. But once voice becomes an interface people use naturally and frequently, the economics change. More usage means more processing, and in a cloud-heavy architecture, success itself becomes expensive.
Always-available voice makes this even more challenging because the system has to understand what matters before there is even a clear request. If every sound or interaction has to travel through the cloud before the system can decide whether it is relevant, you are using expensive resources before you know whether deeper reasoning is needed.
That is why the architecture matters. The more you can understand close to the user (who is speaking, what is relevant, the context and intent), the more selectively you can use the expensive parts of the AI stack.
The goal is not simply to reduce cloud costs. It is to build an architecture where increased usage does not automatically mean proportionally increased cost.
You argue on-device (edge) voice is the real next wave. What changes, both technically and economically, when voice processing moves onto the device instead of the cloud?
I think the important shift is that the device stops being simply an endpoint for cloud intelligence and becomes intelligent in its own right.
For the next generation of voice interfaces that matters, because the intelligence needs to be available continuously. A device should not need to send everything to the cloud just to understand whether something happening around it is relevant.
On-device AI makes that continuous intelligence practical. It can operate with very low latency, without depending on connectivity, and with much of the interaction remaining local.
The economics change as well. Instead of paying for cloud processing every time the interface is used, or simply available, more of that intelligence runs on compute already built into the product. So increased usage does not have to translate directly into increased cloud cost.
The cloud still has an important role, particularly when an interaction requires larger models or deeper reasoning. But the fundamental shift is that intelligence is no longer something the device has to constantly reach out for.
It becomes part of the device itself.
Where does the always-on cost constraint bite hardest today? Which product categories (automotive, wearables, smart home, contact centers) are forced to confront it first?
The pressure is greatest wherever voice is moving from an occasional feature to a primary interface.
Automotive is a good example. Voice has to work naturally while people are driving, often with multiple passengers, road noise and limited connectivity. The expectation is that the system is simply available when you need it, not that you have to think about activating it first.
We see a similar shift in smart home and consumer devices. As voice becomes integrated into TVs, appliances and other everyday products, the number of potential interactions increases dramatically. Robotics takes this even further, because a machine operating around people needs continuous awareness of its environment.
Wearables have another constraint: power. Sending everything to the cloud is not only an economic question; network usage and continuous processing also have implications for battery life and responsiveness.
So I don't think there is one category where this suddenly becomes a problem. The common denominator is the transition from voice as a feature you occasionally activate to voice as an interface that is naturally available throughout the day.
And that transition changes the architecture you need.
On-device voice carries its own trade-offs: model footprint, accuracy in noisy real-world conditions, latency, updatability. How do you weigh those against the convenience of the cloud?
There are absolutely trade-offs. The edge has finite compute, memory and power, while the cloud gives you access to much larger models and makes it easier to update capabilities centrally.
But I think it is a mistake to look at on-device AI as simply a smaller version of cloud AI. The advantage of the edge is specialization.
A device operates in a specific environment, with a specific purpose and a defined set of interactions. That allows you to build highly optimized models for the things that need to happen continuously and immediately, rather than trying to run a general-purpose model for everything.
So the engineering challenge is not to put the biggest possible model on the device. It is to put the right intelligence in the right place. Use specialized on-device models where speed, privacy and continuous availability matter, and use larger models when the task genuinely benefits from their capabilities.
That is a much more efficient architecture than asking either the edge or the cloud to do everything.
How does moving voice on-device change the privacy and data-governance calculus for enterprises, and how much of the shift is driven by cost versus compliance and trust?
Privacy is one of the strongest arguments for doing more voice processing on the device.
An always-available microphone does not have to mean continuously sending everything it hears to the cloud. Those are two very different architectures.
When more intelligence happens locally, the device can process information first and minimize what needs to leave the device. From a privacy perspective, that is a fundamental difference. You are reducing unnecessary movement of potentially sensitive data rather than trying to manage it after it has already been collected and transmitted.
It also changes the governance challenge. The less data you need to move and process externally, the less data you have to secure, store, manage and potentially expose.
I would not separate cost, compliance and trust too much because the same architectural decision affects all three. Processing more locally can reduce recurring cloud costs, reduce unnecessary data movement, and make an always-available voice interface easier for users and enterprises to trust.
For me, the principle is simple: if information does not need to leave the device, why send it?
Kardome's approach separates speakers by their location in the room, so a device can follow one voice in noise or in a crowd. How does solving that problem affect the cost and reliability of always-on voice on the edge?
The first challenge for voice AI is knowing what to listen to.
Real environments are messy. You have multiple people speaking, television or music playing, echoes, mechanical noise, and people moving around the room. If you send that entire acoustic mixture into increasingly sophisticated AI models, you are asking higher-level intelligence to solve a perception problem.
Our Spatial Hearing technology addresses that problem at the source. It allows the device to organize the acoustic scene, separate speakers and noise, and focus on the voice that matters.
Doing that on the edge has two important effects. First, you improve the quality of the information going into the rest of the voice stack. Even the best speech recognition or language model will struggle if it receives the wrong speaker or a poor-quality signal.
Second, you give the device an understanding of the ambient and device context of the interaction before deeper processing begins. That makes it possible to be much more selective about what needs additional processing and what does not.
This is why we see separating speakers in space as more than noise reduction or speech enhancement.
Zooming out, the "Interface Tax" seems to apply beyond voice, to any AI capability that must run continuously at the edge of a product. What's the general lesson for teams designing AI-native interfaces?
I think the bigger lesson is that AI-native interfaces cannot be designed around the assumption that every interaction starts with a prompt.
That model works when AI lives primarily in an application: the user opens it, asks for something, and the AI responds. But as AI moves into devices, vehicles, robots and other physical environments, the interaction changes. The technology is part of the environment around us.
For that to work naturally, a device needs enough intelligence to understand context continuously and recognize when something actually requires attention or action. It should not require the user to explicitly initiate every interaction.
That does not mean running the most powerful AI model all the time. It means designing different layers of intelligence for different jobs, with efficient intelligence continuously available close to the user and deeper capabilities brought in when they are needed.
I think that is one of the important shifts ahead: from AI that waits to be asked to AI that can understand when it is needed.
Drawing on your background in microphone-array processing and acoustics, what do most teams get wrong when they estimate the cost and feasibility of deploying voice AI in production?
The biggest mistake is evaluating voice in conditions that do not resemble the environment where the product will actually operate.
A demonstration with one person speaking directly toward a microphone in a quiet room tells you very little about production performance.
In reality, the speaker may be several meters away. There may be two or three people talking. Music may be playing. The device may create its own noise. The room may produce strong reflections. And the person speaking may move while they talk.
Teams also tend to focus heavily on speech-recognition accuracy while underestimating everything that happens before recognition. You can have an excellent language model and excellent ASR, but if you captured the wrong person or a poor-quality signal, the rest of the stack is working from bad input.
Looking 12 to 24 months out: where is on-device and edge voice AI heading, and what would you advise enterprises evaluating voice AI deployments to do right now?
We are going to see much more intelligence distributed across the edge.
Devices will become better at continuously understanding their immediate environment: who is present, who is speaking, where they are and what requires attention. Larger multimodal and generative models will then be used selectively for richer reasoning and interaction.
That will make voice feel less like issuing commands to a machine and more like interacting naturally with something that understands the surrounding context.
For enterprises evaluating voice today, I would recommend testing the whole interaction architecture, not simply comparing language models. Measure performance in the actual environment where the product will operate. Look at latency, false activations, multiple speakers, distance, noise and connectivity loss. Determine what can remain local and what genuinely benefits from cloud reasoning.
And most importantly, design for usage at scale. If the economics only work when customers rarely use the interface, you have not built a sustainable AI interface. You have built a demonstration.
