Dyad and Lovable now differ over where the build executes and who holds the model key, not over desktop versus browser. Dyad is a free desktop app that runs Node and your app on your own machine and takes any OpenAI-compatible API key you supply. Lovable is a managed cloud platform that meters work in credits and gives its builder agent no model selection and no bring-your-own-key at all, on any plan. Pick Dyad when you want the token bill and the source tree under your control; pick Lovable when you want one company to run the build, the database, the hosting and the domain.
The "desktop versus browser tab" framing that most comparisons still use expired some time ago: Lovable's desktop app documentation says a native macOS and Windows client is available "on all plans, including Free, at no extra cost," with local MCP server support and multi-project tabs. Both products have a desktop icon. Only one of them runs your build on your own machine.
One disambiguation before the numbers, because both names collide badly. JuliaHub ships an unrelated product also called Dyad — physics-based modeling software — whose Light AI tier is also $20 per month, so a price lifted from the wrong page looks entirely plausible. Every Dyad figure below comes from dyad.sh or github.com/dyad-sh/dyad. And the AI builder is lovable.dev; lovable.com 301-redirects there, but lovable.it is an unrelated Italian lingerie brand (checked September 21, 2026).
Which one should you pick
Start from the constraint that cannot be worked around, because it decides most of these cases on its own: Lovable's builder agent has no model setting and takes no outside key. Lovable's FAQ answers the question directly — "No. Lovable manages the underlying model used by the agent in Build mode and Plan mode" — and adds that there is no setting to switch the agent between specific models. That is a missing feature rather than a paywall, so no upgrade path reaches it.
| Your situation | Pick | Why, and what it costs you |
|---|---|---|
| You already pay for model tokens and want the builder to use that account | Dyad | Custom OpenAI-compatible provider is a first-class setting; Lovable offers no equivalent for its agent |
| You want a specific model family for code generation | Dyad | You choose the model id yourself; Lovable rolls model upgrades out centrally and names no model |
| You want one vendor to run build, database, auth, hosting and domain | Lovable | Dyad's publishing guide has you deploy through GitHub and Vercel or your own cloud provider, and its database and auth layer is a separate Supabase or Neon integration you bring yourself |
| You cannot install Node.js, or you are not on macOS or Windows | Lovable | Dyad's quickstart requires Node.js locally, and its FAQ calls Linux support experimental without auto-updates |
| Your project is not a JavaScript app | Lovable | Dyad's FAQ states it only supports JavaScript-based apps |
| Your prompts or code must not train a vendor's models | Dyad, or Lovable Business and above | Since September 9, 2026 Lovable may train on Free and Pro customer data unless you opt out per account |
| You want to keep the option of leaving cheaply | Dyad | Each Dyad app is an ordinary Git repo on disk; Lovable cannot start a project from existing code, so the return trip is not supported |
| Non-developers on your team will edit the app | Lovable | Dyad's visual editor is Pro-only per its own interface strings, and Dyad has no shared workspace |
The training-data row is the one most readers have not seen. Lovable's FAQ states that "As of September 9, 2026, Lovable may use customer data from Free and Pro plans … to train, develop, and improve its AI models," with an opt-out per account under AI model training; Business and Enterprise workspaces are excluded by default. Checked September 19, 2026.
Two things Dyad's own comparison page gets wrong about Lovable
Dyad publishes a Lovable comparison page that ranks on this query, and two of its claims do not survive a check against Lovable's live documentation. The page carries no date, so it is possible to say the claims are wrong today without saying when they stopped being true.
| Claim on Dyad's page | What Lovable's docs say (checked September 19, 2026) |
|---|---|
| "Lovable's pricing restricts free users to … public-only projects." | Public visibility was removed from the product. Lovable's project visibility page records that from April 22, 2026, "You can no longer create public projects. Public project visibility has been completely removed." Free projects are workspace-private. |
| "Lovable's pricing restricts free users to 5 messages per day." | Lovable meters credits, not messages, and the harder limit is monthly. Subscription plans gives Free "5/day, 30/month", and states that after the monthly cap Lovable stops granting the daily credits for the rest of that calendar month. A single prompt costs 0.50 to 2.00 credits in Lovable's own illustrative Build-mode examples, so "5 messages" is not a conversion that exists. |
The same page also quotes "up to 500 messages/day for Gemini 2.5 Flash" as the free-model option, while Dyad's FAQ says 250 daily requests and its quickstart says 250 messages a day for the same model. Both cite a model generation that has since been superseded, and Google no longer publishes a per-model free requests-per-day table — its rate limits page now says limits can be viewed in Google AI Studio. Treat any "free messages per day" figure for a Dyad-plus-free-tier setup as unverifiable, and note that Google's pricing page marks free-tier content as used to improve its products.
Plans and prices side by side
| Plan | Published price | What it includes |
|---|---|---|
| Dyad Free | $0 | Local open-source app builder, macOS and Windows download, no sign-up, bring your own API key, community support |
| Dyad Pro | $20 / month | Pro modes for large codebases, 200 AI credits per month, full Dyad Academy access |
| Dyad Max | $79 / month | 900 AI credits per month, prioritized office hours, credit reloads at the same price; listed as an upgrade rather than a direct purchase |
| Lovable Free | $0 | 5 build credits per day capped at 30 per calendar month, 20 Cloud credits and 4 AI credits per month, workspace-private projects, Git sync. No code editing, no code download, no custom domain, no rollover, no top-ups |
| Lovable Pro | $25 / month for 100 credits, or $250 / year | Code editing and download, custom domains, credit rollover, on-demand top-ups, badge removal |
| Lovable Business | $50 / month for 100 credits, or $500 / year | Adds single sign-on, role-based access, the security center, internal publish and the Lovable API |
| Lovable Enterprise | Volume-based, no public number | Lovable states Enterprise plans do not include the free daily build credits or the monthly Cloud and AI grants |
Sources: dyad.sh/pricing, lovable.dev/pricing and Lovable subscription plans, all checked September 19, 2026. Both credit ladders extend well past the base tier; confirm your own tier in checkout.
Three credit rules decide more of the real cost than the headline price. Lovable's pricing page states that unused monthly plan credits expire two months after issue, annual-plan credits one month after the annual period ends, top-ups twelve months from purchase, and daily build grants at the end of each day; it also states that credits are not refundable or redeemable for cash. Top-ups cost more per credit than subscription credits — the credits documentation prices them at $15 per 50 credits on Pro and $30 per 50 on Business, against $0.25 per credit in the base Pro subscription, and gives them 12 months from purchase. And downgrading to Free freezes what the subscription granted: Lovable's subscription-plans page states that after the workspace moves to Free, unused monthly plan credits and rollover credits are frozen, cannot be used on Free and are not refunded, though they stay spendable until their original expiry date if you upgrade again first. On the Dyad side, AI credits roll over for one month, but Dyad publishes no per-model credit rate anywhere, only that "a credit corresponds directly to the cost of sending a message to an AI model" — so no "X credits buys Y tokens" conversion is derivable for either product.
Where a Kunavo key can and cannot go
This is the part most comparisons flatten, and getting it wrong in either direction is easy. Dyad takes an OpenAI-compatible endpoint as a first-class setting. Lovable does not, for its builder — but does document one route into the app you ship.
Dyad's custom models guide says "Dyad lets you use any AI model or provider, as long as they offer an OpenAI-compatible API." The path is Settings, then AI Providers, then Add Custom Provider, then Add Custom Model inside that provider.
| Dyad field | Value for Kunavo |
|---|---|
| API Base URL | https://api.kunavo.com/v1 — include the /v1, matching the placeholder the shipped Add Custom Provider dialog renders at v1.16.0, E.g., https://api.example.com/v1 |
| API key | Your sk-kn- key. The same dialog carries an optional "Environment Variable" field that names an environment variable to read the key from instead; the published guide documents neither field |
| Model ID | The exact Kunavo model slug, for example claude-sonnet-4-6. Dyad's guide stresses this "must match exactly what's specified in the provider's API documentation" |
| Max Output Tokens and Context Window | Fill both in by hand. Dyad warns that if left blank it "will use default values, which may be smaller than optimal" |
Three boundaries are worth knowing before you plan around this route. The source citations below were read at tag v1.16.0 on September 19, 2026.
Chat Completions only. In get_model_client.ts, a custom provider is built with the AI SDK's createOpenAICompatible client against your base URL. There is no Anthropic Messages path and no OpenAI Responses path for a custom provider. The hosted built-in entries in the same switch — OpenAI, Anthropic, Google, xAI, Bedrock, MiniMax — are constructed from an API key alone, with no base-URL field to redirect, so a gateway belongs in a custom provider rather than in one of those. The two exceptions are the local-server entries, Ollama and LM Studio, which do take a base URL but are documented for local model servers. That same custom-provider client is passed an includeUsage flag, but the source sets it only on the path where Dyad Pro is enabled alongside a custom or local provider; the plain bring-your-own-key path leaves it at its false default. Either way, how a given gateway reports streaming usage is not something this page tested.
Pro modes cannot use your key. The FAQ on dyad.sh/pricing answers this directly: Pro modes such as Smart Context work only with Dyad Pro's AI credits, because they need server-side processing across several models. The shipped source agrees structurally — the Dyad Pro branch builds a separate engine client against Dyad's own engine base URL with a Dyad API key, and Smart Context is passed as a dyad-engine provider option. So the features that make very large codebases affordable are exactly the ones a bring-your-own-key setup cannot reach. There is no configuration that gets both.
Free Agent mode is capped regardless of whose key it is. free_agent_quota_limit.ts sets FREE_AGENT_QUOTA_LIMIT = 20, and the handler defines a 23-hour window checked against the Date header from Dyad's own health endpoint to prevent clock manipulation; the hook that reads it only runs for non-Pro users, and the gate itself fires only when Dyad Pro is off and the selected chat mode is the local agent — the provider and key behind it make no difference. The number appears nowhere on dyad.sh, though the app's own mode selector labels the option "Free tier (20 messages/day)", and Dyad ships roughly weekly — so treat it as observed behaviour at one tag rather than a published commitment. Build mode with a custom provider is not under this cap.
On the Lovable side, the builder is closed and the app you ship is not. Lovable's AI features documentation states that the built-in AI connector always runs through Lovable and bills workspace credits, that the key is a Lovable-issued one, and that Anthropic models are not available through it — but that if your app needs a provider the connector does not offer, you can have Lovable call that provider's API directly from a backend edge function with your own key stored as a secret, in which case the app consumes only regular Cloud usage for running the function. Those are two different systems, and Lovable's own docs say so: the connector's models "are not the models Lovable uses to write, edit, or reason about your code." A Kunavo key can serve the runtime AI inside a Lovable-built app through that edge function. It can never serve Lovable's builder.
A worked cost estimate for the Dyad route
These figures are illustrative token arithmetic, not measured task costs and not a bill ceiling. Assume one Build-mode session that sends 150,000 uncached input tokens and receives 15,000 output tokens, and a heavier agent-style session at 600,000 input and 40,000 output. Both token shapes are assumptions for illustration. Rates come from the live Kunavo catalog per million tokens.
| Model | Input / output per 1M | Estimate, single session | Estimate, heavy session |
|---|---|---|---|
| Claude Haiku 4.5 | $0.40 / $2.00 | $0.090 | $0.320 |
| Gemini 3.8 Flash | $0.525 / $2.625 | $0.118 | $0.420 |
| GPT-5.6 Terra | $0.70 / $4.20 | $0.168 | $0.588 |
| Claude Sonnet 4.6 | $1.20 / $6.00 | $0.270 | $0.960 |
| Claude Opus 5 | $2.00 / $10.00 | $0.450 | $1.600 |
Read this against the subscriptions rather than as a like-for-like swap. A Lovable credit buys the managed build, the hosting, the database and the domain alongside the model work; a token rate buys only the model call, and you still supply Supabase or Neon and a deploy target yourself. The comparison that is actually decidable is the one about predictability: on the token route the unit price is published in advance, while on either credit route it is not — Dyad publishes no per-model credit rate, and Lovable says Build-mode cost depends on the complexity of the request and the work completed. At Claude Sonnet 4.6, the single session above estimates at $0.270; the same shape on Claude Haiku 4.5 estimates at $0.090. Cheapest listed rate and lowest cost to finish the job are still different questions — a cheaper model that needs three attempts can cost more than one that needs one — so measure on your own repository before settling.
Kunavo's catalog amount is a billing floor rather than a cap: when the upstream reports its charge, the bill is the greater of catalog cost and upstream cost times the applicable markup. Cache charges and external tools sit outside this example. The minimum top-up is $10 in prepaid credit, which is a funding minimum rather than a task fee or a subscription — see billing details.
Migration cost runs one way
Lovable to Dyad is the supported direction. Lovable's plan table gives Git sync to every plan including Free, and Dyad's importing guide names apps built with Lovable, V0 or Bolt as importable — subject to three caveats it states itself: importing is labelled experimental, only Node.js-based JavaScript apps are supported, and the app must run with npm run dev. Dyad keeps imported apps on local disk under ~/dyad-apps/ as ordinary Git repositories, which is why its FAQ can claim you can switch between Dyad and other tools freely.
Dyad to Lovable is not supported as an import at all. Lovable's FAQ states there is currently no way to start a Lovable project from already existing code on, for example, GitHub. Moving that way means rebuilding inside Lovable and paying credits for the rebuild.
Ownership is asymmetric in a second way that only shows up when you leave. Lovable says you own your code and that apps can be hosted anywhere via Git sync, but its deployment and ownership page also states that the editor and AI agent are a managed service that cannot be self-hosted or deployed inside a customer VPC, and that migrating the backend to plain PostgreSQL or another database provider is not supported out of the box. So the application is portable; the build environment is not.
The open-source claim needs a qualifier
Dyad's repository is live — not archived, created April 11, 2025, last pushed September 18, 2026, 21,597 stars (GitHub API, September 21, 2026). Its LICENSE puts content outside src/pro/ under Apache 2.0 and content inside it under the Functional Source License 1.1 with an Apache-2.0 future grant and a Competing Use restriction. Agent-mode code ships from src/pro/, so "fully open source" overstates it for the agent specifically — which is the part being compared against Lovable's closed platform.
Two version details to settle in your own install rather than from a badge. The newest tag is v1.16.0, and package.json at that tag reads 1.16.0 — but GitHub's latest-release endpoint still serves v1.15.0 from September 11, 2026, with no release object published for v1.16.0 (checked September 21, 2026). And the same package.json declares "license": "MIT" while the LICENSE files say otherwise and GitHub's detector reports NOASSERTION. The LICENSE files are the authority; the metadata is stale.
Setting up the Dyad route
Kunavo has no Dyad-specific setup page and Dyad has not been runtime-tested here — the configuration above is read from Dyad's documentation and its shipped source, which is a reference rather than a compatibility test. The generic path is the one Dyad documents: an OpenAI-compatible base URL, a key, and an exact model id. Start from the OpenAI-compatible API guide, keep a working route available while you try it, run one bounded build, then read the charge your account actually recorded for it. Create a Kunavo account when you are ready to fund a key.
If you are still choosing between builders rather than providers, the coding model comparison covers which model families suit which kind of work, and AI cost optimization covers how to measure a route on your own repository instead of on a price table.
FAQ
Is Dyad a free alternative to Lovable?
Dyad Free is $0 and needs no sign-up, per dyad.sh/pricing. It is a desktop app that runs Node and your app on your own machine, keeps each project as an ordinary Git repository, and lets you supply your own model API key. That removes the subscription, not the model bill — you still pay whichever provider the key belongs to. Two limits the pricing page does not mention: Dyad's shipped source caps free Agent-mode use at 20 messages per 23-hour window regardless of whose key you use, and the visual editor is labelled Pro-only in the app's own interface strings. Build mode with your own key is not under that agent cap.
Can I use my own API key with Lovable?
Not for the builder. Lovable's FAQ states that Lovable manages the underlying model used by the agent in Build mode and Plan mode, and that there is no setting to switch the agent between specific models. That is the absence of a feature rather than a plan gate, and no plan tier — Enterprise included — lists one. The one place an outside key is documented is the app you ship: Lovable's AI docs say the built-in AI connector always runs through Lovable and bills workspace credits, but that if your app needs a provider the connector does not offer, you can call that provider directly from a backend edge function with your own API key stored as a secret, in which case the app consumes only regular Cloud usage for running the function.
Is Dyad open source?
Partly, and the qualifier matters. The repository's LICENSE file puts everything outside the src/pro directory under Apache 2.0 and everything inside src/pro under the Functional Source License 1.1 with an Apache-2.0 future grant, which forbids what it calls a Competing Use. Agent-mode code ships from src/pro, so the agent specifically is fair-source rather than Apache-2.0. Two other labels on the same repository disagree with the LICENSE file: package.json declares MIT, and GitHub's own license detector reports NOASSERTION. Lovable, by contrast, states plainly that its editor and AI agent are a managed service that cannot be self-hosted or deployed inside a customer VPC.
Can I move a Lovable project into Dyad?
That direction is the cheap one. Lovable syncs any project to GitHub, GitLab or Bitbucket on every plan including Free, and Dyad's importing guide explicitly names apps built with Lovable, V0 or Bolt as importable — with the caveats that importing is still labelled experimental, that only Node.js-based JavaScript apps are supported, and that the app must run with npm run dev. The reverse direction is much harder: Lovable's FAQ says there is currently no way to start a Lovable project from existing code on, for example, GitHub, so a Dyad codebase cannot simply be opened in Lovable.
Which is cheaper, Dyad or Lovable?
Neither publishes a rate card you can compute against, so the honest answer is that only one of the three routes has a knowable price in advance. Dyad Pro is $20 per month for 200 AI credits and Dyad Max is $79 for 900; Lovable Pro starts at $25 per month for 100 credits and Business at $50 for 100. But Dyad defines a credit only as corresponding to the cost of sending a message to an AI model, and Lovable says Build mode cost depends on the complexity of the request and the work completed, with its own illustrative examples running 0.50 to 2.00 credits for a single prompt. The route you can budget ahead of time is Dyad Free plus your own metered API key, where the price per million tokens is published and the arithmetic is yours to do.
Does Dyad work with an OpenAI-compatible gateway?
Dyad's custom-models guide states that Dyad lets you use any AI model or provider as long as they offer an OpenAI-compatible API, configured under Settings, AI Providers, Add Custom Provider with an ID, Display Name and API Base URL, then Add Custom Model with a Model ID that must match the provider's documentation exactly. In the shipped source, custom providers are constructed with the Vercel AI SDK's openai-compatible client against that base URL, which means Chat Completions only — there is no Anthropic Messages path and no OpenAI Responses path for a custom provider, and the hosted built-in entries such as OpenAI and Anthropic are constructed from an API key with no base-URL field, so a gateway belongs in a custom provider rather than in one of those. Publishing a configuration path is not the same as runtime-testing it, so run one bounded build before committing to the route.
Opened directly on September 19, 2026: dyad.sh's pricing and Lovable-comparison pages and its custom-models guide; both Dyad LICENSE files; package.json, get_model_client.ts, free_agent_quota_limit.ts and the agent-quota handler at tag v1.16.0; the GitHub repository, releases and tags API; and Lovable's pricing page plus its subscription-plans, credits-and-usage, FAQ, AI-features, project-visibility, deployment-ownership and desktop-app documentation. Re-opened on September 21, 2026: the answers behind Dyad's pricing-page FAQ accordion; Dyad's FAQ, quickstart, importing, publishing and maximize-AI-credits pages; the Add Custom Provider dialog, the free-agent-quota handler and the chat-mode gate at tag v1.16.0; Lovable's Git-sync, enterprise and subscription-plans documentation; and the GitHub repository and releases API. Kunavo token rates come from the live catalog, and every dollar figure in the worked example is illustrative token arithmetic rather than a measured task cost.