Models got a trillion-dollar upgrade; the way you type intent did not change.

The numbers are large enough to distort the conversation. An eleven billion dollar round at a valuation near one point two five trillion dollars tells you where capital believes the returns will come from: models, compute, and the infrastructure to train and serve them. That belief is reasonable. Capability has improved on nearly every axis, and the companies that control frontier models sit at the center of a new platform shift. But a valuation is a claim about the future, not a description of how work currently gets done inside an ordinary company on a Tuesday morning. Valuation describes expectation; the bottleneck describes the day.
Follow the money and you see a pattern. Capital flows toward what can be built, owned, and defended: data centers, chips, training runs, distribution. Those are the assets that show up on a balance sheet and in a pitch deck. The interface between a person and the model rarely gets the same treatment, because it looks small next to a data center and it is hard to own. Yet that interface decides whether the trillion dollars of capability is actually used. A model that can reason across a thousand pages is not useful if the person holding the question cannot express it clearly and quickly.
Investors understand this better than the headlines suggest. Every platform shift eventually produces value in the layer that connects users to the core technology: the browser, the app store, the operating system, the search box. Those layers looked trivial at the time and became enormous. The current shift has a comparable gap. Models are funded; tooling around them is funded; the input side is mostly assumed to work because keyboards have always worked. Assumption is not the same as optimization, and the assumption is where the opportunity sits. Assumptions are cheap to hold and expensive to leave unexamined for a decade.
The keyboard is the tell. It is the most used input device in knowledge work and the least rethought. It has been refined for speed and feel but not for the task of expressing intent to a machine that can act on paragraphs rather than keystrokes. When the downstream system can do more, the upstream bottleneck becomes more valuable to fix. That is the plain reading of a trillion-dollar model layer: the payoff is limited by how much intent people can push through. Whoever removes that limit captures a share of the value the models create, without needing to train a model at all.
Picture the stack as it actually runs. A person forms an intent, translates it into words, types those words, and sends them into an application. The application passes them to a model, which returns text. The person reads, corrects, and iterates. Every arrow in that diagram is a place where meaning can leak. The model layer is now well funded and heavily optimized. The human layer, from thought to typed text, has barely changed. The gap between the two is the unclaimed layer, and it is not a metaphor: it is the seconds and minutes between having a thought and getting it into a form a model can use.
Why has this layer stayed unclaimed? Partly because it spans everything. Input happens in every app, so no single product team owns it. Partly because it looks solved: keyboards work, dictation exists, and most people have adapted. Adaptation hides cost. A worker who types slowly has simply built a career around avoiding certain kinds of writing. A team that writes in a second language has learned to send shorter messages. These adaptations are rational, and they are also a tax that nobody budgets for. Unclaimed layers often look like solved problems until someone measures the workarounds. Measurement is usually the first product opportunity.
The layer is also politically awkward. Improving input touches every workflow, which means it cannot be sold as a narrow pilot. It changes habits, and habits are defended. It shows up in productivity numbers only indirectly. That combination is unattractive to teams that need a clean attribution story. So input improvements tend to arrive sideways, through operating system features or third-party tools, rather than as a strategic initiative. The result is a market that is large, real, and fragmented, which is usually the signature of an opportunity rather than a dead end. Fragmented markets reward a layer that can serve every surface at once.
Voiskey's bet is that this layer deserves a product, not a setting. System-level voice input, accurate across more than one hundred languages, running on Mac and Windows, working inside the apps people already use: that is an attempt to claim the layer directly. It does not compete with models. It feeds them better material. In a stack where the top is funded at a trillion dollars, the layer that determines how much of that capability reaches a person is worth building deliberately, not leaving to whatever ships by default. Defaults are chosen by whoever owns the platform, not by the people doing the writing.
Input quality is not a soft variable. It determines what the model can infer, which determines the quality of the answer. A vague prompt produces a generic response because the model has nothing specific to work with. A prompt that states the goal, the audience, the constraints, and the format produces something usable. The difference is not model capability; it is the material the model receives. Most disappointing AI output is not a reasoning failure. It is a specification failure, and the specification is written by a person typing at the speed of their hands rather than the speed of their thinking.
Iteration amplifies the effect. Good AI work is usually a conversation: a first attempt, a correction, a refinement. Each turn costs typing. When the cost is high, people stop iterating early and accept a mediocre result, or they front-load everything into one long prompt and hope. Neither behavior produces the best output the model could deliver. Lowering the cost per turn changes the pattern: more corrections, more specificity, better final text. The output quality improves not because the model changed but because the person was able to keep supplying the detail the model needed. Cheap turns are a quality feature disguised as a speed feature.
There is also a context problem. The information a model needs often lives in documents, threads, and recordings that a person must summarize before prompting. Summarization is writing, and writing is the bottleneck. A tool that lets someone speak the context quickly, in their own words, gets more of it into the prompt. More context, correctly expressed, reduces hallucination and rework. This is why input improvements compound: better input produces better output, which produces a better next prompt when the person reacts to what came back. The loop gets tighter and the quality curve bends upward. Each turn carries more context than the last, at no extra typing cost.
None of this diminishes the models. It reframes where the marginal gain is. If a model's capability is fixed for a given task, the largest remaining improvement comes from the quality and quantity of intent it receives. That is an interface problem, and interface problems are solved by design rather than by scale. Polishing, structure, and speed of entry are not cosmetic. They are the mechanisms by which a capable model receives a capable prompt. The keyboard sits between the two, and its limits propagate through everything downstream. Improving the input remains the cheapest way to improve the output, and it is available today.
An expression layer is a specific architectural claim. It says that converting human intent into usable text deserves to be a shared capability, like a font renderer or a network stack, rather than a feature rebuilt inside every app. The layer handles capture, cleaning, formatting, and insertion. Applications above it simply receive better text. This separation is why a single habit can work in email, chat, documents, and developer tools without each product implementing its own dictation. It also means improvements in the layer benefit every surface at once, which is how infrastructure earns its place. Infrastructure is judged by what it enables above it.
Voiskey implements this with the Speak-Polish-Type-Edit loop. Speech is captured, polished into readable prose, typed into the active field, and left editable. The polish step is where expression intelligence does its work: removing fillers, repairing restarts, applying punctuation, and preserving the speaker's intent and tone. Because processing is local by default with zero retention, the layer can be trusted with the material people actually work on, from customer details to internal strategy. Security is not a feature bolted on afterward; it is a precondition for speaking real work into a system that touches every window. That precondition is what separates a demo from a daily tool.
The layer also solves a distribution problem. Enterprises rarely adopt a tool that requires every application to integrate. They adopt something that works with what they already run. A system-level layer meets that requirement because it needs no per-app work. It also fits the Team plan model, where shared workflows and conventions keep output consistent across an organization. Consistency matters in regulated and customer-facing work, where tone and terminology are part of the brand. A layer that can be configured once and used everywhere is easier to govern than a dozen app-specific features nobody audits. Governance is easier when there is one layer to review.
The strategic case is simple. Models are a commodity input at the top of the stack, expensive to build and increasingly similar in capability. The expression layer is where differentiation can live because it encodes how a specific person, team, or company communicates. That is not something a foundation model vendor will optimize for. It is close to the user, sensitive to context, and improved by daily use. In a market where the top is crowded and capitalized, the layer next to the person is where durable product value can be built. And it is the layer users feel every hour of the day.
The first change is volume. When sending a message costs less, people send more of them: more updates, more documentation, more follow-ups. That sounds like noise, but in practice it usually means fewer things fall through the cracks. The messages that used to be skipped because writing them was tedious now happen. A quick recap after a call, a note in a record, a clarifying reply in a thread. Teams that adopt faster input often discover that their processes were fine and their writing volume was the real constraint. That is a surprising finding, and a useful one for capacity planning.
The second change is iteration. Faster input means more rounds with an AI assistant, more drafts, more attempts at a hard message. People explore more when exploration is cheap. That changes the character of the work: less one-shot perfectionism, more rapid refinement. The output is usually better because the person saw more options and corrected more mistakes. It also changes how people feel about writing. A task that felt heavy becomes a conversation. That shift in perception is often more durable than any single time saving, because it changes what people are willing to attempt. Willingness is the scarce resource in most writing work.
The third change is inclusion. Fast typing is a skill that some people have and others do not, and the gap maps onto language background, disability, and role. Voice input narrows that gap. Someone writing in a second language can speak their intent and get clean text. Someone with a motor impairment can produce the same volume as a colleague. A new hire can communicate at the level of their thinking rather than the level of their typing. Inclusion is usually discussed as a policy goal, but here it is a direct product of lowering input friction. Friction was doing the exclusion, not policy.
The fourth change is measurable throughput. When input stops being the constraint, the limiting factor moves to judgment: deciding what to say, to whom, and when. That is a healthier bottleneck, because it is the part of work that benefits from human attention. Organizations that measure the shift find that time to send falls, rewrite cycles drop, and the share of messages that need clarification declines. None of this requires a bigger model. It requires removing the keyboard from the critical path and letting people express intent at the speed they can think it. That is the definition of a well-designed input layer.
Click into the inserted draft and type the right word, or select the phrase and speak the replacement through the hotkey. Do not repeat the whole passage. If the same term keeps coming back wrong, open Voiskey settings and add it to your custom vocabulary with the spelling you prefer, so future dictation gets it right without the extra edit.
It is the four-step habit Voiskey is built around. You speak naturally into the active window, Voiskey polishes the words into clean text, the result is typed at your cursor, and you edit anything you want before sending. Each step is quick, so the whole loop feels like one action. Once it becomes routine, you stop thinking about the steps and simply talk your way to a finished message.
No. Voiskey runs at the system level, so one installation covers mail, chat, documents, notes, and code editors without a separate plugin for each. You trigger it with the same hotkey everywhere, and the text appears at your cursor. Install Voiskey once per computer, sign in, and it is ready in every program you open.
Most people feel at ease with Voiskey within a few days of regular use, because the core loop is just speak, polish, type, and edit. The first hour is about building the hotkey habit. After that, pacing and punctuation improve with practice. Give it a week of real messages and it starts to feel like ordinary typing, only faster.

Speak your intent into every app and let the model receive the detail it needs.
Use it across macOS, Windows, iOS, and Android