Build a local LLM chat app without code: your model, your laptop

Why every other guide assumes the model is in the cloud

The honest reason is that most no-code platforms cannot reach your laptop. Bubble, Glide, Softr, Voiceflow, Zapier, all of them run inside a hosted runtime in someone else's data center. When their docs say 'plug in an LLM,' they mean an HTTP endpoint they can reach: OpenAI, Anthropic, Cohere, an OpenRouter or AWS Bedrock proxy. None of them can call http://127.0.0.1:11434 on your machine because they are not on your machine.

That leaves two paths in most articles you will find on this topic. The first is 'install Open WebUI,' which is excellent software and the right answer when the chat UI you want is the one Open WebUI ships. The second is 'host your model with Ollama on Fly.io,' which works but cancels the privacy and cost story that drove you toward a local LLM in the first place. Both routes skip the question of how to get a custom UI you actually own.

mk0r fits a different gap. The agent runs in a sandbox in the cloud, but the artifact (the Vite project) is portable code. You take the artifact home and run it next to Ollama. The model never travels.

The shape of the system

Three machines do three things. The diagram below is the whole architecture. Nothing else is hidden behind it.

The mk0r sandbox writes code; it does not host weights. The product config is explicit about this: 'Heavy local model inference is out of scope for the standard 1 vCPU sandbox.' That is the constraint that makes the whole story work. Because the sandbox cannot be the model host, the model has to be on your machine, which means your prompts have to be on your machine too, which is exactly what 'local LLM' means in the first place.

Step 1. Get Ollama running with the right CORS gate

Install Ollama from ollama.com/download. Pull a model. Llama 3.2 is a fine starting point on a 16 GB MacBook; Mistral 7B and Qwen 2.5 fit too. The exact model does not matter for this guide; the wire format does.

Before you start the daemon, set OLLAMA_ORIGINS so the browser is allowed to call it from a different origin. On macOS:

launchctl setenv OLLAMA_ORIGINS "http://localhost:5173,http://127.0.0.1:5173"
# then quit and re-open the Ollama menubar app
ollama pull llama3.2
ollama serve   # if running from the CLI

On Linux you set it in the systemd unit override or export it in the shell that runs the binary. The Ollama FAQ at github.com/ollama/ollama/blob/main/docs/faq.mdx walks through every platform. If you skip this step, the chat will fail with a CORS error in the browser console the first time you click Send. The error message is loud; you cannot miss it.

Sanity check from a terminal on your laptop:

curl -sN http://127.0.0.1:11434/api/chat \
  -d '{"model":"llama3.2","messages":[{"role":"user","content":"hi"}],"stream":true}' \
  | head -3

You should see JSON-lines streaming back, one object per token chunk. Each object has message.content with the next piece of text. That is the shape the generated UI parses.

Step 2. Describe the chat to mk0r

Open mk0r.com. No account, no setup. Type one sentence that names the URL, the model, and the behavior you want. The smaller the sentence, the more honest the result; the more specific, the less iteration you spend later.

Two examples that work first try:

• "A mobile-first chat that streams from my Ollama at http://127.0.0.1:11434/api/chat, model llama3.2, with markdown rendering and a stop button."
• "A two-column chat. Left side: history of past conversations from localStorage. Right side: streaming response from Ollama at 127.0.0.1:11434, model qwen2.5. Allow me to switch model via a dropdown that pulls from /api/tags."

The under-the-hood scaffold is named in the system prompt at src/core/e2b.ts line 170: a Vite + React + TypeScript + Tailwind CSS v4 project at /app, dev server on port 5173 with HMR, Playwright MCP wired into a real Chromium for browser testing. The agent edits files inside that scaffold; it does not regenerate the world on every turn. That is what makes iteration cheap.

Step 3. What you skip vs writing it by hand

The chat client itself is not exotic, but the small bits add up. Streaming JSON-lines parsing, abort-on-resubmit, content-by-content append into React state, the textarea that grows with content, the auto-scroll-to-bottom on new tokens. Here is what your editor looks like the by-hand way vs the prompt-mk0r way.

// Roughly what you write by hand for an Ollama chat client
import { useRef, useState } from "react";

type Msg = { role: "user" | "assistant"; content: string };

export default function App() {
  const [messages, setMessages] = useState<Msg[]>([]);
  const [input, setInput] = useState("");
  const abortRef = useRef<AbortController | null>(null);

  async function send() {
    abortRef.current?.abort();
    const ac = new AbortController();
    abortRef.current = ac;

    const next: Msg[] = [...messages, { role: "user", content: input }];
    setMessages([...next, { role: "assistant", content: "" }]);
    setInput("");

    const res = await fetch("http://127.0.0.1:11434/api/chat", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        model: "llama3.2",
        messages: next,
        stream: true,
      }),
      signal: ac.signal,
    });
    if (!res.body) return;

    const reader = res.body.getReader();
    const decoder = new TextDecoder();
    let buf = "";
    while (true) {
      const { done, value } = await reader.read();
      if (done) break;
      buf += decoder.decode(value, { stream: true });
      const lines = buf.split("\n");
      buf = lines.pop() ?? "";
      for (const line of lines) {
        if (!line.trim()) continue;
        const json = JSON.parse(line);
        const delta = json.message?.content ?? "";
        setMessages((cur) => {
          const last = cur[cur.length - 1];
          return [
            ...cur.slice(0, -1),
            { ...last, content: last.content + delta },
          ];
        });
      }
    }
  }

  return (
    <main className="min-h-screen p-4 max-w-md mx-auto">
      <ul className="space-y-2 mb-4">
        {messages.map((m, i) => (
          <li key={i} className={m.role}>{m.content}</li>
        ))}
      </ul>
      <textarea
        value={input}
        onChange={(e) => setInput(e.target.value)}
        className="w-full border p-2"
      />
      <button onClick={send} className="mt-2 px-4 py-2 bg-teal-500 text-white">
        Send
      </button>
    </main>
  );
}

The point is not that the by-hand version is hard. It is not. The point is that you trade an hour of fiddling with stream parsing for a sentence, and the agent verifies in a real Chromium before it claims done. If the streaming reader has an off-by-one at the JSON boundary, the agent catches it (the response area never updates) and fixes it before reporting back.

Step 4. Walk through what actually happens

Two of those five steps are on your machine; three are in the sandbox. The split is the design. The sandbox is good at boilerplate, file edits, browser verification. Your laptop is good at running a 7B model without paying anyone. The export step is the bridge.

Step 5. Export and run it on your laptop

When the agent is done, ask it to commit. Each session is provisioned with a private GitHub repo whose URL lives in /app/.env as GITHUB_REPO_URL. From your terminal:

git clone <your-repo-url>
cd <your-repo>
npm install
npm run dev
# vite running on http://localhost:5173

Open the URL. The chat connects to http://127.0.0.1:11434 (the agent wrote that base URL into .env as VITE_OLLAMA_URL by default; change it if your Ollama listens elsewhere). Send a message. Tokens stream in. Network panel shows requests to localhost only. Activity Monitor shows your CPU or GPU spinning, not your network card. That is the whole point.

Iteration from here is a normal codebase. Push to the repo. Deploy to Cloudflare Pages or static-host the build output if you want to share the UI; the people you share it with will need their own Ollama for the chat to work. There is no proprietary runtime in the export and no mk0r-only build step.

The honest limits

Three things to know before you commit.

The mk0r preview cannot reach your Ollama. While the agent is iterating inside the sandbox, the in-VM Chromium is on a different machine than your laptop. It cannot fetch your localhost. The agent verifies the UI shape (input, message list, send button) but it cannot verify a real model round-trip from inside the sandbox. The first true round-trip happens after you export and run locally. If that distinction matters, an alternative is to ask the agent to call a public endpoint (Hugging Face Inference Providers, OpenRouter) so the in-sandbox preview is a full system, then swap the base URL to your Ollama on export. That is a one-line change in /app/.env.

Multi-user shared chat is not this shape. The exported app is a single-page client that talks to a localhost daemon. If you want friends or coworkers to use it, you need a real backend (a Postgres, a streaming relay, a per-user model context). Open WebUI is closer to that out of the box. mk0r is a fit when 'local' really means 'me, on my laptop'.

RAG over a personal corpus is one prompt away but two prompts of work. You can ask the agent to add a file-upload box that chunks documents and stores embeddings via a local Ollama embedding model (mxbai-embed-large works). It will scaffold the basics. The retrieval quality, chunk size, and prompt template are knobs you will tune by hand. None of that is unique to mk0r; the same is true if you build it in any framework. The agent gets you a working baseline, not a finished retrieval system.

When you should not do this

Use Open WebUI, AnythingLLM, or LibreChat when the goal is a polished chat with auth, multi-user, plugins, RAG out of the box, and you do not want to maintain any of it. They are well maintained; you will be happier than building.

Use Hugging Face Inference Providers or OpenRouter when the privacy and cost story does not matter. A hosted endpoint plus a generated UI removes the CORS gate and the export step.

Use mk0r for the case in between: a custom UI that you actually own, talking to a model that lives on the same machine as the user. A weekend project. A privacy-first chat for one. A chat for a kid that strips out anything you do not want them to see. Anything where the UI is small, the model is yours, and the artifact deserves to be a regular Vite project you can fork, share, or deploy.