What an AI Service Looks Like to the Frontend
Explore how frontend engineering interacts with AI services by understanding the terminology, control limits, and the nature of model responses. Discover why AI calls behave differently from typical API requests and how to manage AI-generated output effectively in your frontend projects.
Calling an AI service looks like any other request. An endpoint is asked, an answer comes back. What sits behind that endpoint works nothing like a database lookup, and the parts of it that matter to the frontend have names worth knowing.
We'll cover the following:
What the frontend is calling
The vocabulary of a model call
Why the same call answers differently
What the frontend can and cannot control
What the frontend is calling
The frontend never calls a model directly. The request goes to an endpoint on our own side, and that endpoint talks to the model.
There's a firm reason for this. Anything the browser holds, the user can read. A key that authorizes calls to a model is a credential, and credentials placed in frontend code are readable by anyone who opens the browser's developer tools. So the key stays on the server, and the frontend asks the server.
Note: The frontend never holds a key to an AI service, for the same reason it never holds a database password. Anything shipped to the browser is public.
The frontend only ever sees the first hop. What happens beyond our endpoint is not the frontend's concern.
Several companies build models, including OpenAI, Anthropic, and Google. Because the frontend only ever talks to our own endpoint, which one sits behind it is a decision made on the server side. Swapping one for another changes nothing the frontend can see.
Note: The frontend is written against our endpoint, not against a provider. That's what keeps the interface unaffected when the model behind it changes.
The vocabulary of a model call
Four terms cover what the frontend needs.
Term | What It Means |
Model | The system that takes text in and produces text out |
Prompt | The text sent to the model |
Completion | The text the model produces in response |
Token | The unit a model reads and writes text in, roughly a short word or part of one |
Let's see each in a bit detail.
Model
A model is the system that turns a prompt into a completion. It holds no records and looks nothing up. Everything it produces is composed from the text it was given.
This is the part of the picture furthest from the frontend. We never call it directly, we don't configure it, and which one sits behind our endpoint can change without the interface noticing. What matters is what it does: text in, text out, composed rather than retrieved.
Prompt
The prompt is everything the model is given. It isn't only the user's question. It's usually assembled from several pieces: instructions written by us, data pulled from state, and text the user supplied.
That assembly happens in our code, which means the prompt is something we build rather than something we pass along. How to build one well is its own subject.
Completion
The completion is what comes back. It's text, always, even when it looks like structured data.
This is worth sitting with. If we ask for a list and get back something that looks like a list, we received text shaped like a list. Nothing about the exchange guarantees it can be treated as one.
Token
A model reads and writes in tokens, which are chunks of text roughly the size of a short word or part of a longer one.
The frontend rarely counts tokens, but two consequences show up. A completion has a limit on how long it can be, so a request for something lengthy can stop partway. And a completion arrives token by token rather than all at once, which is why a generated answer can appear gradually.
Note: A completion that stops partway isn't a failure. The request succeeded and returned everything it was allowed to produce.
What a model can produce
Not every model works only in text.
Modality refers to the kind of content a model handles. A text model takes text and produces text. Some models also handle images, audio, or video, either as input, as output, or both. A model handling more than one kind is called multimodal.
For the frontend, this changes one thing and leaves another alone. What changes is rendering: an image completion needs different handling on screen than a paragraph does. What stays the same is the request. It's still a request to our endpoint with something sent and something returned.
The four kinds of work
Most AI features in an interface fall into one of four kinds.
Kind of Work | What It Does | Example |
Generation | Produces new text from instructions | Drafting a reply |
Transformation | Rewrites text that already exists | Shortening a long description |
Extraction | Pulls specific values out of free-form text | Finding a date inside a note |
Classification | Assigns text to one of a fixed set of categories | Marking a message urgent or routine |
The first two produce something a person reads. If the wording varies between requests, little is lost.
The last two produce something the interface acts on. A category decides which badge appears; an extracted value fills a display. When the interface depends on the answer rather than just showing it, whether that answer can be trusted becomes a real question, and checking it is a subject of its own later.
Why the same call answers differently
A model doesn't select the one correct next token. At each step it works out which tokens are plausible, and picks among them. That selection isn't fixed. Run the same prompt twice and the picks can differ, which is why two completions from identical input can read differently while both being reasonable. The setting that governs this is called temperature. Lower values make the model favor the most likely option more consistently. Higher values let it range more widely.
Two things matter to the frontend here:
Lowering temperature narrows variation but doesn't remove it. There is no setting that turns a model into a lookup.
And this setting lives on our endpoint, not in the browser, alongside everything else about how the model is called.
Note: Variation is a property of how the answer is produced. It can be narrowed, but the frontend cannot assume it away.
What a model call costs the interface
A model call is not free in the way a lookup is, and the frontend absorbs two of those costs directly.
Latency: A completion takes noticeably longer than retrieving a stored value. That wait is visible to the user and has to be designed for rather than covered over.
Review: Some completions need a person to confirm them before anything acts on the result. Which ones is a decision made per feature, not a fixed rule.
There's a third cost the frontend doesn't handle but should be aware of. Model calls are usually billed by tokens, counting both what's sent and what comes back, so a longer prompt or a longer completion costs more than a short one. How that's calculated varies between models and changes over time, and it's settled on the server side rather than in the interface.
What the frontend can and cannot control
The honest division is smaller than it first appears.
What Goes into the Prompt | Which Words Come Back |
How the completion is checked before use | Whether the completion is accurate |
What the interface does with the completion | How long the completion takes |
Whether a person confirms before anything happens | Whether the same prompt answers the same way |
Everything in the left column is ordinary frontend work. Everything in the right column is a property of the service.
The practical rule follows from that split. Use a model where language is the actual problem: turning data into a readable sentence, interpreting free-form text a user wrote, drafting something a person will review. Keep anything that must be exact in ordinary code, where the loop still behaves the way it always has.
A total, a permission check, and whether a form is complete: these are calculations. A model doesn't improve them, and it removes the guarantee that they come out the same way twice.
Why is a completion still just text even when it appears to be structured data?
We've covered what a model is, the four terms that describe a call to one, why the same prompt can answer differently, and the split between what the frontend controls and what it doesn't. The left side of that split is where all the work happens: building the prompt, checking the completion, and deciding what the interface does with it.