A smart keyboard that knows what you're typing into

A keyboard suggestion can be grammatically fine and completely wrong for the box you're typing in. “Thanks for following up” belongs in an email. It is a strange completion for a search query and a worse one in a code editor.

Jev can supply a small decision before the keyboard spends money generating text: what kind of field is this, what tone fits, and would a suggestion help? The keyboard can then choose an approved snippet, ask a writing model, or stay quiet. This is a proposed implementation pattern; the examples below are not results from a shipped keyboard.

Give the model the context the app already knows

Start with the application and field metadata you can access with the user's permission. A search field should identify itself as search. A password field should be excluded locally. There is no reason to ask a remote model to rediscover a field type your app already knows.

The ambiguous cases are more useful: a general text area inside an email client, a chat composer used for both customers and colleagues, or a form field whose visible label gives more information than its HTML type.

Send a small text sample alongside the relevant field label and application category. Avoid sending the whole conversation, browser page or document by default. Keep those fields separate so a sentence in the sample cannot masquerade as application metadata.

A decision request might ask for three things:

Question	Available answers	What the application does with it
Writing context	email, chat, form, code, search, unclear	Chooses the permitted suggestion features
Suitable tone	formal, casual, unclear	Selects a snippet style when relevant
Would a suggestion help now?	Probability of yes	Decides whether to offer anything

These are application-defined questions. TypeSafe documents Choice and Noul as typed decision primitives; Jev does not generate the suggested sentence. A label such as formal is an instruction to the next part of your software.

Let a label choose a small action

Suppose a user types “Can you send the revised invoice” in a customer email. A useful response could be a saved closing phrase, shown as a preview. The same phrase in a search box should remain a search query. In a code editor, disable prose completions unless the user explicitly invokes them in an appropriate context.

Keep the action mapping in code. For an email with enough context, show a relevant saved snippet. For a drafting request that needs new wording, call a separate text model with the user's selected passage and requirements. For an incomplete form value, leave the value alone.

The writing model should receive the actual task, not only Jev's label. “Formal” does not tell it who the recipient is or what the writer wants to say. Treat the classification as one input to a bounded request, and let the person accept or reject the resulting text.

Cache the context while the field remains stable. Trigger another decision after a meaningful change, such as switching applications or moving from a subject line to a message body. A short pause can be a useful sampling point; its duration needs testing in the actual keyboard. Keep typing responsive while the decision runs, and discard results tied to an older field or text revision.

Price decisions separately from writing

Consider a hypothetical product with 1,000 active users, each triggering 20 context decisions a day for 30 days. That produces 600,000 decisions per month. If your planning allowance is $0.00005 per decision, classification gets a $30 allowance. Those are illustrative assumptions, not a Jev or Vaaya quote.

Now suppose a separate writing call follows 10% of decisions, at an assumed $0.002 per call. That adds $120. The modeled total is $150 before retries, hosting and other costs. The writing step still deserves its own limit even when context checks are inexpensive.

Replace both assumed prices with observed receipts from a small, authorized pilot. Count full requests, including their question text, and include failures or retries that incur charges. The guide to reading an agent's spending statement explains how to separate useful completed work from repeated attempts. Do not turn a monthly estimate into a promise about cost per keystroke.

A short input may deserve no suggestion

“Fine” can be agreement, frustration or the start of a longer sentence. A confident classification does not establish the writer's intention. Give the model an unclear option and evaluate the point at which the keyboard stops offering suggestions. TypeSafe's confidence documentation distinguishes an option's probability from the separate confidence value returned for Choice and Score.

Test abbreviations, misspellings and mixed-language text with people who use them. TypeSafe's model documentation says English performs best; a threshold tuned on English emails is not evidence that Hinglish messages will behave the same way.

Exclude passwords, payment fields and other sensitive contexts before making a network request. Give users control over which apps participate and what text leaves their device. A cloud context check is still a disclosure of that text, even if the result is only a label.

Measure suggestion acceptance, immediate deletion after acceptance, unwanted suggestions and time waiting for a usable suggestion. Review failures by field type. A higher suggestion count is easy to produce; a keyboard that interrupts less and preserves the writer's words is a more useful test.

You can use Jev on Vaaya, along with 500+ model options and 1,500+ endpoints. One API key, one balance, a receipt for every call.

Questions

Can Jev write the keyboard's suggestions?

Jev returns typed decisions, such as a context label or the probability that a suggestion would help. A template, snippet library or separate generative model supplies the suggested text.

Does the keyboard need to send every keystroke?

No. Sample after a pause or an explicit request, reuse a recent context decision, and avoid sending sensitive fields. Calling on every keystroke adds cost and can produce decisions about text that has already changed.

Will Jev work equally well across languages?

TypeSafe says English is Jev's strongest language. Evaluate the languages and mixed-language inputs your users write, and keep the keyboard's ordinary behavior available when context is uncertain.