AI App Builder In-App AI (2026): The Builder Is AI. Your App Probably Is Not.

Quick Answer

Every builder on this board is an AI product. In September 2026 that tells you almost nothing about whether the app you ship can call a model, because the documentation for these eight describes two entirely separate things under one word: the AI that writes your code, and the AI your users reach at runtime.

Four builders name a first-class in-app AI product where you never touch a provider key. Lovable ships a built-in AI connector and says of it, in its own docs, "These AI features run inside your app. They are separate from the Lovable agent that helps you build and edit your project." Replit offers managed access to OpenAI, Anthropic, Google and OpenRouter models with "no developer account setup, no API key management". Base44 exposes an OpenAI-compatible gateway with, in its words, "no API key to manage". v0 is pre-configured to the Vercel AI Gateway and says "no additional setup is required".

Two document only the bring-your-own-key route. Softr exposes OpenAI, Anthropic and Gemini as workflow steps. Bubble treats a model as any other HTTP API through the API Connector.

Two document no in-app AI product at all. Bolt.new publishes exactly one page about large language models, and it is about how Bolt uses one to write your code. Webflow's only AI entry in its developer documentation is an MCP server so that agents can drive Webflow.

The column that actually decides the bill is none of those. It is whose meter the call lands on.

The word "AI" is doing two jobs

Read these docs side by side and the ambiguity is not subtle, it is structural. On an AI app builder, the phrase "AI features" can mean the model that turns your prompt into a React component, or it can mean the model your customer's chatbot calls at two in the morning. The vendors that have thought hardest about this say so themselves.

Lovable marks the boundary twice on one page. Above its model list it states that those models are for "AI features inside the apps you build" and adds, plainly, "They are not the models Lovable uses to write, edit, or reason about your code."

Bolt.new is the cleanest demonstration of the opposite. Its documentation index contains a single page under the heading "Introduction to LLMs", and the page is entirely about the builder: "In Bolt, this generative power is what turns your requests into code, designs, or solutions behind the scenes." There is no dishonesty in that. It is simply answering a different question from the one a buyer asks when they want a summarise button in their own product.

This is why a marketing page is useless on this axis. "AI-powered" is true of all eight and discriminates none of them.

Three architectures, and one column that matters

Every cell above is taken from the vendor's own documentation, read on 22 September 2026. Where a cell says "not documented" it means exactly that and nothing more: an absence in the documentation we read, not a statement that the thing is impossible. Any builder that lets you write server-side code lets you call an HTTPS endpoint, and a model is an HTTPS endpoint. The distinction being drawn here is whether the vendor names in-app inference as a product it supports, meters and will answer questions about.

Two nuances the table compresses. Softr does have AI credits, and they are real, but its own billing page scopes them to features like Ask AI and Database AI Agents, which are things you use while building. The path from your shipped app to a model is the workflow integration, and that runs on your provider key. And v0's metering is documented clearly for its own agent traffic, where gateway requests are described as consuming "your team's AI Gateway credits", while the page describing AI models for your projects does not state the meter for calls your deployed app makes. We are recording that as unstated rather than inferring it.

What your user sees when the meter runs dry

The managed path is genuinely easier. It is also the one where a billing event becomes a user-facing failure, and Lovable is the only builder here that documents that consequence explicitly.

Lovable, on running out of credits, verbatim: "If your workspace runs out of credits, the server returns a 402 Payment Required status code."

That is not your dashboard showing a warning. That is the AI feature inside your live product returning a payment error to somebody who has never heard of your builder. Lovable is more forthcoming here than anyone else on the board, and being forthcoming is what makes the mechanism visible; the same class of failure exists wherever platform credits back runtime inference.

Two more clauses from the same page are worth reading before you design around a credit pool. Lovable documents that its monthly AI grant for deployed apps is a "Temporary offering, subject to change" and does not roll over. It also documents that you are charged when a generation completes "even if your app stops waiting or never shows the clip", and that on cancelled requests "some usage may still be billed even if the app closes the connection before the response finishes". A user who closes the tab can still cost you.

Base44 draws the same architecture without the softening. Its gateway documentation says the surface "uses your app's models, billing, and credit quota" and that calls are "metered against your app's credit quota". Replit is the most transparent on price formation, documenting that it manages the provider credentials and bills you at the public API price against your Replit credits.

So the real trade is not convenience against control. It is this: on the managed path, your users' consumption and your own ability to keep building are drawing on related pools of platform credit, and the failure surfaces in front of your customer. On the bring-your-own-key path you take on key storage, provider billing and rate limits, and in exchange the two budgets are genuinely separate and a bad month for your app cannot stop you shipping.

What the bring-your-own-key path actually costs you

The BYO route is often described as "just add your API key", and the vendor docs are more honest than that summary.

Base44 sets out the real precondition in a warning on its own integrations page: "To obtain and utilize an OpenAI API key, a paid account is required. While creating an OpenAI account is free, using the API necessitates funding the account with a credit balance or having a billing method on file." It then tells you to add a payment method and, optionally, to set a spending limit. That is three accounts to reason about before a single token is generated: your builder, your model provider, and your app's own users. Base44 also gates the route, documenting that AI integrations are available on the Builder plan and above because they depend on backend functions.

Bubble is the purest version of the pattern and does not dress it up. Its OpenAI material sits inside the API Connector documentation, alongside every other REST integration, and the sequence it gives you is to set up an account and an API key, then configure authentication, then define the calls. The advantage is that nothing is special: a model is an endpoint, the same skills apply, and the same connector serves any provider that appears next year.

Softr sits between the two. Its OpenAI integration is a set of named workflow actions rather than raw HTTP, with a custom prompt step plus prepared actions for writing, summarising, categorising and image generation, wired to run when a user submits a form or a record changes status. That is meaningfully less work than Bubble's route, and it is still your provider key and your provider invoice.

Worth noticing what none of the three requires: a conversation with your builder about how much AI your customers are allowed to use.

The things this column does not tell you

Two adjacent questions get confused with this one often enough to be worth naming.

The first is direction. This article is about your app calling out to a model. The opposite direction, where an agent calls in and drives your app or your builder, is a different product with a different answer per vendor, and we scored it separately in our comparison of which builders an agent can actually drive. Webflow is the clearest example of why the two must not be merged: it documents an MCP server and no in-app inference, so a feature table that collapses both into one "AI" row would mark it yes on a capability it does not offer.

The second is time. Model calls are slow by the standards of a web request, and anything involving a document, a long transcript or a video is slow enough that it cannot live inside the request that triggered it. Whether the work survives your user closing the tab is not an AI question at all, it is a question about what runs when nobody is watching, and several builders that answer the inference question well answer that one much less well.

Verdict, September 2026

If you want AI inside the product you ship and you want it working this week, the managed path on Lovable, Replit, Base44 or v0 is a real shortcut and the documentation is good enough to plan against. Prefer Replit if you want the pricing relationship legible, because billing at the public API price against your own credits is the easiest of these to forecast. Prefer Base44 if the feature is more than a single call, since it is the only one of the eight documenting a distinct surface for agent loops separately from one-shot invocation, alongside a bring-your-own-key route on the same platform.

Choose the bring-your-own-key path deliberately, not reluctantly, if in-app AI is going to be a load-bearing part of the product rather than a garnish. Softr and Bubble only offer that path, which sounds like a limitation and is closer to a clarification: your model bill arrives from your model provider, it scales with your users rather than against your build budget, and nothing about your AI spend can interrupt your ability to ship.

Treat Bolt.new and Webflow as builders for apps whose intelligence lives elsewhere. Neither documents in-app inference, and neither pretends to.

The question to ask a vendor is never "do you support AI". All eight do. Ask instead: when my customer triggers a model call at midnight, whose key signed the request, whose account gets the invoice, and what does my customer see when that account is empty.