bring your own model

free software for the llm era. the app is free; the user brings their own model for the parts that need it, and pays only for the inference they personally use.

the app
free to use, free to host. no backend.
the model
the user brings their own key.
the bill
paid straight to the provider, no markup.
the developer
never touches the key or the money.

what it is

a pattern for building apps with llm or agent features at their core, without charging anyone a subscription.

the app works on its own: browse, read, navigate, use the whole thing for free. some features are powered by a model. when a user wants those, they connect their own key, and the inference runs on their own model access, billed directly by their provider.

the app stays free, and nobody pays for anyone else's inference.

why it exists

when an app's features run on inference the developer pays for, the app can't really be free. the cost has to come back somehow — a subscription, metering, a payment stack — and the developer ends up reselling intelligence they never set out to resell.

byom removes that. the user already has, or can get, model access. they bring it. no middleman, no markup, no billing business growing out of a side project.

the bigger idea

building software with coding agents is fast and widely accessible now. that makes it easy to build small, useful tools that solve real problems — and a lot of that software is better with model inference.

those tools don't have to become subscription products to exist. they can be free software, with each user carrying their own inference cost through their own model access. one person solves their problem, shares it, and anyone with the same problem benefits — at no cost to the builder.

how it works1

v1: openrouter
user's browser → their own key → the provider → the model

there is no developer server on this line — the key and the money go straight from the user to their provider.

  • free to host. static front-end code, no developer-run backend.
  • bring a key. model-powered features ask the user to connect one.
  • browser-local. the key stays in the browser and calls the provider directly. it never reaches the developer.
  • pick a category. apps request a model category — frontier or worker — and let the user choose.
  • set a ceiling. a user-set budget limit keeps inference from running away.

security2

keeping the key in the browser is a privacy and control win, not a cryptographic guarantee.

a key in browser storage can be read by any cross-site-scripting flaw on the page, so byom apps follow six invariants to reduce that surface. they are mandatory for any app claiming compliance or showing the badge.

  1. 1 in-memory by default. the key is held in memory for the session. persistence to local browser storage is explicit and opt-in — the user chooses it, so a returning user does not have to re-enter the key. it is never persisted silently.
  2. 2 never sent to the developer's servers. the key is never transmitted to or stored on any server the developer runs. it goes only to the provider.
  3. 3 strict content security policy. a strict csp is in place to limit where scripts can load from and where the page can send data. its load-bearing purpose is to bound key and prompt exfiltration via injected scripts and arbitrary-origin egress.
  4. 4 minimal third-party javascript. every dependency is attack surface for key theft. keep third-party js to the minimum the app genuinely needs, and justify each one.
  5. 5 never log the key, never log key-linked prompts. neither the key nor prompt content tied to the key is written to any log.
  6. 6 pre-flight token estimation and enforceable budget limits. before a request, estimate its token cost and check it against a user-set, cumulative budget — accounting for in-flight requests, so concurrent or multi-step calls cannot blow past the ceiling before spend catches up. the app stops at the limit, including when a bug spams requests. this ceiling is a best-effort guard against estimates; see "the honest budget boundary" below for what it does and does not guarantee.

a badge means an app follows the pattern and these invariants. it is not proof of safety: in-page ui can always be cloned by a malicious site. stronger phishing resistance would need privileged browser chrome — a future direction, not part of v1.

the money3

you can see what you spend, as you spend it.

  • live cost. model-powered actions show their real cost as they run — actual usage, never an estimate.
  • breakdown. spend is attributable per request, and where the app can, per feature.
  • history. a local record of what you've spent, kept on your device next to your key setup. the developer never sees it.
  • no lost work. if a paid action is in progress, the app warns before you leave, so you don't pay for work that gets thrown away.

getting a key4

byom assumes you can bring model access, not that you already have it.

an app built on byom should walk a first-time user through it: what a key is, getting one from a provider (openrouter in v1), setting a spend limit there, and connecting it.

if that path isn't clear to someone who's never seen an api key, the app isn't done.

in practice

a worked example, end to end:

  1. 1you open the app and use it. browsing, reading, navigating — free.
  2. 2a feature needs a model. the app asks you to connect a key, and shows you how to get one if you don't have it.
  3. 3you set a budget. the app guards against runaway spend; set a hard limit at your provider too.
  4. 4the feature runs. you see the cost as it works, recorded locally.

more examples are coming as apps adopt the pattern. the registry lists the ones that exist today.

the badge5

an embeddable mark: a plug connecting into a two-slot socket. apps that follow the pattern can show it. light, dark, and small variants live under /assets/badge/.

BYOM badge — follows the pattern and security invariants, not proof of safety. BYOM badge — follows the pattern and security invariants, not proof of safety.

markdown

[![BYOM](https://byom.flkp.nl/assets/badge/byom-badge-light.svg)](https://byom.flkp.nl/)

html

<a href="https://byom.flkp.nl/" rel="noopener">
  <img src="https://byom.flkp.nl/assets/badge/byom-badge-light.svg"
       alt="BYOM badge — follows the pattern and security invariants, not proof of safety." width="168" height="44" loading="lazy">
</a>

registry

0 apps

apps that use this convention. a listing says an app follows the pattern and has a BYOM-INTEGRATION.md — it is not a security audit.

no apps listed yet. the registry opens as apps adopt the pattern and publish.

to add an app, edit registry.yaml and open a pr; ci validates it against the schema. see the registry readme.

  1. ↩ the provider model, categories, and the call path. 01-provider-model.md
  2. ↩ the six security invariants. 02-security-invariants.md
  3. ↩ cost transparency. 06-cost-transparency.md
  4. ↩ the wizard and onboarding contract. 03-wizard-ux-contract.md
  5. ↩ the badge and registry. 04-badge-and-registry.md

read the full constitution →