Skip to content

AWFlow wants to be the OpenRouter for AI that runs in your browser

Three incompatible browser AI engines, a different model format each. AWFlow sits in front of all three so you choose a job, not a library. Where we are and why the web will get there.

Dannick K.
October 14, 2026 · 2 min read
PresentBoard

Also in Français

A Kinetic block with the line 'The web solved this for cloud AI. It will solve it for in-browser AI too.' — a claim about the future of browser AI routing.
Share
On this page
  1. Three engines, three islands
  2. What a browser AI router has to do
  3. How AWFlow approaches it today
  4. What is still missing
  5. Where you can start today

When OpenRouter launched, switching between cloud AI models went from a migration to a one-line change. You described a job and the router sent it to the right model. The engine was invisible.

AI that runs in your browser needs the same thing, and does not have it yet. Three excellent open-source engines power most in-browser AI today. They share no model format, no install path and no common interface. Picking one means committing to one ecosystem—and rebuilding if you want to change.

AWFlow wants to fix that. This post explains why the problem exists, what a router for browser AI must do, and where we are.

Three engines, three islands

The engines that run AI inside a browser—WebLLM, TensorFlow.js and transformers.js—each expect a different model format. A model prepared for WebLLM will not load in transformers.js. A Hugging Face ONNX model will not load in WebLLM.

Electrical plugsBrowser AI engines
UK, EU, US plug shapes
MLC build, model.json, ONNX
Same electricity inside
Same AI inference inside
Need adapters to cross countries
Need different engines to cross formats
Buy once, locked to that socket
Train once, locked to that engine

Locked in. Pick an engine, it controls your models.A model prepared for one engine will not load in another.

Analogy split
Text version
  1. Electrical plugs: UK, EU, US plug shapes ≈ Browser AI engines: MLC build, model.json, ONNX
  2. Electrical plugs: Same electricity inside ≈ Browser AI engines: Same AI inference inside
  3. Electrical plugs: Need adapters to cross countries ≈ Browser AI engines: Need different engines to cross formats
  4. Electrical plugs: Buy once, locked to that socket ≈ Browser AI engines: Train once, locked to that engine

The result is three islands. If you add a new feature that needs a different capability—say, speech-to-text when you only installed a chat model—you add a new engine, a new format, a new download, a new API.

Your app or extensionmust call each one
WebLLMchat (MLC build)
TensorFlow.jsvision (model.json)
transformers.jsaudio (ONNX)
Three tasks, three engines
summarise
label image
transcribe
text
label
transcript
Three integration surfaces

A router hides this behind one interface.Caller describes a task; the router picks the engine and model.

Team
Text version
  1. Three tasks, three engines → Your app or extension
  2. WebLLM: summarise · TensorFlow.js: label image · transformers.js: transcribe
  3. WebLLM → text · TensorFlow.js → label · transformers.js → transcript
  4. Three integration surfaces

What a browser AI router has to do

A cloud router forwards your prompt. An on-device router cannot forward anything: the model must run on your machine. That means it has to do the jobs a cloud router never thinks about.

Router responsibilities

What routing in-browser AI requires

  • Know what each task needs (done)must do
  • Know what your hardware can run (done)must do
  • Download the right format for the right engine (done)must do
  • Route by job, whichever engine holds the model (done)must do
  • Let you swap the model without rewriting the workflow (done)must do

Swap the model without rewriting anything.If the model is a dependency node, changing it is a one-step edit.

Checklist
Text version
  1. What routing in-browser AI requires
  2. Know what each task needs
  3. Know what your hardware can run
  4. Download the right format for the right engine
  5. Route by job, whichever engine holds the model
  6. Let you swap the model without rewriting the workflow

The last item is the heart of the analogy with OpenRouter. When you switch models on OpenRouter, your application code does not change. The same should be true for a browser AI router: you describe a job, you pick which installed model does it, and the workflow stays the same.

How AWFlow approaches it today

AWFlow’s Local AI page is the current expression of this. You see every installed model grouped by task. You install from a curated list or add a Hugging Face model in any of the three formats. The engine selection is automatic: you never specify WebLLM, TensorFlow.js or transformers.js by name.

The Local AI page: storage used by on-device models split by engine (WebLLM, TF.js, Transformers), a task list on the left (Chat, Embeddings, vision and audio tasks) and model cards on the right, such as Llama 3.2 1B Instruct with its size, variants and install state.The Local AI page: storage used by on-device models split by engine (WebLLM, TF.js, Transformers), a task list on the left (Chat, Embeddings, vision and audio tasks) and model cards on the right, such as Llama 3.2 1B Instruct with its size, variants and install state.

This is the router made visible.The page is the interface between you and the three engine layers beneath.

Guided screenshot
Text version
  1. 1. Grouped by task: Chat, embeddings, vision, speech-to-text.
  2. 2. One card per model: Engine, size and device fit.
  3. 3. Shared storage: One download, used everywhere.

When a model is installed, it becomes the default for every feature that needs that task. Change the default model and every feature updates.

AWFlow
Engine layer
A chat or agent job
WebLLM / TF.js / transformers.jspicked automatically
task + text
result
Engine visible to younoNetwork callnone

Swap the model and the job still works.The resolution layer finds the new model; the workflow node stays the same.

Round trip
Text version
  1. AWFlow: A chat or agent job · Engine layer: WebLLM / TF.js / transformers.js
  2. A chat or agent job → WebLLM / TF.js / transformers.js: task + text
  3. WebLLM / TF.js / transformers.js → A chat or agent job: result
  4. Engine visible to you: no · Network call: none

The first screen you see when you open the AWFlow assistant presents this choice directly:

The Assistant’s first-visit card, Meet Aria, your private AI: Private, on this device (greyed out here, because the capture browser has no WebGPU), Chrome built-in AI with Set up, Connect a cloud provider with Add key, and Start chatting.The Assistant’s first-visit card, Meet Aria, your private AI: Private, on this device (greyed out here, because the capture browser has no WebGPU), Chrome built-in AI with Set up, Connect a cloud provider with Add key, and Start chatting.

The choice is yours from the first screen.Users are not locked to a model or an engine at sign-up.

Guided screenshot
Text version
  1. 1. On this device: Free, private, offline once installed.
  2. 2. Or a cloud provider: Your own key if a job needs more power.
  3. 3. Start chatting: Same interface either way.

What is still missing

Being honest about what we have not solved matters here. Two problems exist above any single product.

Myth

Install a model once and every browser AI tool can use it.

Fact

Browser storage is per origin. The same 900 MB can sit in your browser five times, once per tool.

The fact. Each website or extension keeps its own copy.Cache Storage and IndexedDB are partitioned by origin; no cross-origin model registry.

Myth vs fact
Text version
  1. Install a model once and every browser AI tool can use it.
  2. Browser storage is per origin. The same 900 MB can sit in your browser five times, once per tool.

The second problem is format. Until the browser AI ecosystem agrees on a shared model format, or a router can convert between them at install time, “which model?” will keep meaning “which engine?” in disguise. Neither problem is solved. WebGPU makes in-browser AI faster each month; a shared format or a browser model registry may follow the same path.

The trajectory

The web solved this for cloud AI. It will solve it for in-browser AI too.

In-browser AI is at the same stage. The path is clear.Three islands, no common format — the same shape cloud AI had in 2022.

Kinetic line
Text version
  1. The trajectory: The web solved this for cloud AI. It will solve it for in-browser AI too.

Where you can start today

If you want to try what exists, the Local AI guide walks through installing a model and setting it as default. For choosing between variants—what the 4-bit label means, which size fits your laptop—the model picking guide covers it step by step.

And if you have used a cloud router and want the same experience for in-browser models, tell us. The direction is clear; the specific features to build next are not.

Quick poll

Which in-browser AI task matters most to you?

Example results

Summaries lead. Chat close behind. (Example results.)Example only.

Poll
Text version
  1. Which in-browser AI task matters most to you?
  2. Summarising pages: 41% · Chat and agents: 33% · Image labelling: 14% · Voice transcription: 12%

What we covered

  1. Three browser AI engines, three model formats, no common interface
  2. AWFlow routes by job, not by engine name
  3. Shared storage and shared formats are still open problems

Three. The hard problems are above any single product.Per-origin storage and engine-specific formats must be solved at the web platform level.

Recap
Text version
  1. What we covered
  2. Three browser AI engines, three model formats, no common interface
  3. AWFlow routes by job, not by engine name
  4. Shared storage and shared formats are still open problems

Automate the web you're on. Free, in your browser.