Så kopplar du dina egna Ollama-modeller till en AI-appbyggare

Varför köra genereringen genom din egen Ollama

Om du redan kör modeller lokalt med Ollama har du hårdvara och modellval som en webbläsarbaserad körning inte kan matcha – större kvantiseringar, modeller du hämtat eller finjusterat själv, och inga nedladdningsgränser satta av webbläsarens cache. Att peka en appbyggare mot den uppsättningen innebär att genereringen sker helt på infrastruktur du kontrollerar.

Det finns ett andra skäl som betyder mer i praktiken: förutsägbar kostnad. Molngenereringar räknas – fem i månaden på Gratis, 25 på Premium, 50 på Pro. Ollama-genereringar räknas inte alls, eftersom de aldrig rör en server som skulle kunna räkna dem. Bygger du om mycket är den skillnaden hela poängen.

Den ärliga motvikten är att en 7B-modell på din bärbara dator inte är en toppmodell i molnet. Räkna med att rätta den oftare. Vad du köper är integritet, obegränsat antal försök och kontroll över modellen – inte bättre resultat.

Vad du behöver innan du börjar

• Pro-planen. Ollama-inställningen ligger i kontomenyn under ett avsnitt märkt Premium / Pro, och den är låst specifikt till Pro. På Gratis och Premium syns valet men visar ett lås, och klickar du på det får du beskedet att funktionen är exklusiv för Pro-användare. Det går inte att kringgå från appens sida.
• Ollama installerat och igång på samma dator som webbläsaren. Editorn pratar med http://localhost:11434. En modell på en annan dator i nätverket går inte att nå via den här inställningen.
• En dator. Webbläsaren måste nå localhost, så en telefon eller surfplatta kan inte använda den här vägen.

Vill du köra lokalt utan Pro är vägen via WebGPU i webbläsaren alternativet – Qwen 3.5 4B fungerar på gratisplanen, obegränsat, utan att du behöver röra terminalen.

Steg 1: Installera Ollama och hämta en modell

Ladda ner Ollama från deras officiella sida och hämta en modell från terminalen:

ollama run gemma2

Specifikt för kodgenerering presterar kodtränade modeller i regel bättre än generalistmodeller i samma storlek, så det är värt att prova ett par innan du bestämmer dig. Modellfältet i editorn föreslår gemma2, llama3.1 och qwen2.5 som utgångspunkter, och gemma2 används om du lämnar fältet orört.

Vad du än hämtar: anteckna vad ollama list kallar den. Exakt den strängen är vad editorn skickar, och en nästan-träff som llama3 i stället för llama3.1 misslyckas som ett anslutningsfel snarare än som ett hjälpsamt "modellen finns inte".

Steg 2: Starta Ollama med CORS påslaget

Det här är steget nästan alla guider hoppar över, och skälet till att de flesta ger upp. En webbläsare vägrar prata med din lokala Ollama om den inte skickar tillåtande CORS-headers, så Ollama måste startas med en origins-variabel i stället för att köras igång som vanligt.

macOS och Linux:

OLLAMA_ORIGINS="*" ollama serve

Windows, i PowerShell:

$env:OLLAMA_ORIGINS="*"; ollama serve

Observera att det måste vara den körande instansen. Om Ollama redan körs som bakgrundstjänst utan den variabeln: stoppa den först – annars tar den nya processen inte över porten och webbläsaren fortsätter nekas. På macOS betyder det att avsluta programmet i menyraden, inte bara stänga ett fönster. På Windows: avsluta Ollama från aktivitetsfältet.

Symtomet när det här är fel är specifikt och värt att känna igen: editorn når porten, anropet avvisas innan Ollama ens ser det, och du får ett allmänt anslutningsfel. Ingenting syns i Ollamas egen logg, eftersom anropet aldrig kom fram.

Steg 3: Aktivera i editorn

Öppna kontomenyn och välj Lokal AI (Ollama) under avsnittet Premium / Pro. Dialogen har två reglage:

1. Aktivera lokal anslutning – reglaget som styr genereringen till localhost:11434.
2. Ollama modellnamn – exakt den modellsträng ollama list visar.

Tryck Spara inställningar. Båda värdena sparas i din webbläsare, så inställningen överlever en omladdning och står kvar tills du stänger av den. Det är värt att komma ihåg: kommer du tillbaka en vecka senare, glömmer att du lämnat den påslagen och genererar utan att Ollama körs, ser felet gåtfullt ut.

Steg 4: Bygg, och håll koll på vilken motor du faktiskt fick

Med reglaget påslaget går genereringsanropen till din dator. Statusmeddelandet säger att den kontaktar lokal Ollama medan den arbetar, vilket är det snabbaste sättet att bekräfta vilken motor som körde.

En prioritetsregel att känna till: är lokalt läge via WebGPU också aktivt vinner WebGPU. Motorn väljs i ordningen WebGPU, sedan Ollama, sedan molnet. Har du slagit på Ollama men en WebGPU-modell är laddad genererar du på WebGPU-modellen och Ollama-inställningen används helt enkelt inte.

Följdfrågan från Arkitekten kan köras på din Ollama-modell. Det finns ingen LLM-granskare som skriver om koden på Ollama-vägen — en syntaxkontroll stoppar JavaScript som inte går att tolka; den lagar inte logik och den anropar inte molnet.

Ingenting förändras i den genererade appen. Den använder fortfarande samma inbyggda Supabase-databas, samma inloggning och samma publiceringskedja, och SDK:n injiceras på samma sätt.

Kontextfönstret är det som faktiskt ställer till det

Det här är felet folk går på under sin andra eller tredje session, och det är inte uppenbart.

Editorn anpassar Ollamas kontextfönster till prompten. Den läser ett sparat värde som utgår från 8192 token och höjer det automatiskt när prompten behöver mer – och reserverar ungefär 6400 token marginal för ett fullt bygge och 2560 för en kirurgisk ändring, så att modellen har någonstans att skriva sitt svar. Taket ligger på 32768 token.

När appens källkod plus prompten överstiger taket avbryts genereringen innan den börjar, med beskedet att appen är för stor för den lokala modellens minnesfönster och en uppskattad tokenmängd. Det är ett medvetet avslag i stället för en avkapad, trasig app – en modell som får slut på fönster mitt i en fil producerar kod som slutar halvvägs genom en funktion.

Två vägar ut när du slår i taket: uppdatera appen via molnet i stället, eller dela upp ändringen i mindre steg. Uppdateringar använder ett diff-baserat redigeringsläge som bara skickar de delar som ändras, så små och specifika önskemål håller sig med god marginal inom fönstret medan "gör om alltihop" inte gör det.

Det får en praktisk följd för hur du arbetar. Lokala modeller är bäst på tidiga byggen och små, riktade ändringar. En stor och mogen app är i regel enklare att bygga vidare på via molnet, vilket är en avvägning snarare än en brist – och tänker du lämna plattformen så småningom spelar det större roll att koden som kommer ut är standardiserad och exporterbar HTML oavsett vilken motor som skrev den.

Vad som fortfarande går till molnet

Att vara exakt här spelar roll, eftersom "lokal AI" används slarvigt.

Genereringen är lokal: din prompt och koden modellen skriver stannar på din dator. Men det här är separata åtgärder som använder nätverket, och att köra Ollama förändrar dem inte:

• Att spara ett projekt lagrar det i molnet, liksom att publicera.
• AI-funktioner inuti den genererade appen – window.NorthernGoAI.generate(), speak() och generateImage() – går alltid till molnproxyn. Det finns ingen väg som skickar en publicerad apps egna AI-anrop till din Ollama, eftersom dina besökare inte kan nå din dator.
• Appens databas läser och skriver mot Supabase i molnet.

Ollama gör alltså byggandet privat, inte körningen. Den fullständiga jämförelsen av vad lokal och molnbaserad generering ger dig går igenom var den skillnaden betyder något, och vad GDPR innebär är värt att läsa om skälet till att du vill generera lokalt är regelmässigt snarare än praktiskt.

Begränsningar

• Kräver Pro, och fungerar bara från en webbläsare på samma dator som Ollama.
• Tak på 32768 token. Stora appar går inte att uppdatera lokalt alls.
• Kvaliteten varierar med modellen. En liten generalistmodell struntar i instruktioner som en större kodmodell följer. Kommer uppdateringar tillbaka i fel format är modellen oftast orsaken, inte prompten.
• Ingen tillförlitlig förhandsvisning av planen. Du ser koden strömma in, men en svagare modell producerar mindre pålitliga fasmarkörer, så förloppsvisningen kan säga mindre än den gör vid molnbyggen.
• Ett omförsök vid formatfel. Struntar en modell i det begärda redigeringsformatet kör editorn ett striktare omförsök och ger sedan upp i stället för att loopa. Det är avsett beteende, inte ett hängt läge.

Felsökning

Om editorn inte når modellen, gå igenom det här i ordning. De flesta problem är något av de tre första.

"Kunde inte ansluta till Ollama." Bekräfta att Ollama faktiskt servar genom att öppna http://localhost:11434 i en webbläsarflik – den ska svara, inte gå i timeout. Bekräfta sedan att du startade den med origins-variabeln satt, inte som vanlig bakgrundstjänst. Bekräfta sedan att modellnamnet i editorn exakt matchar det ollama list rapporterar.

Det fungerade i går men inte i dag. Ollama startades om utan origins-variabeln, troligen för att datorn startades om och bakgrundstjänsten kom tillbaka i stället för din terminalprocess. Variabeln är inte bestående om du inte sätter den på systemnivå.

Porten svarar men webbläsaren nekas ändå. Två instanser körs, och den som håller port 11434 är den som startades utan CORS. Stoppa alla, kontrollera att ingenting svarar på porten, och starta sedan om med variabeln.

"Appen är för stor för den lokala modellens minnesfönster." Du har slagit i taket på 32768 token. Gör en mindre och mer specifik ändring, eller uppdatera appen via molnet.

Genereringen körs men ger inget användbart. Prova en kodtränad modell i liknande storlek. Det är ett problem med modellens förmåga, inte med anslutningen, och ingen omformulering av prompten räddar en modell som är för liten för uppgiften.

Reglaget är på men genereringen gick uppenbart till molnet. Kontrollera om en WebGPU-modell är laddad. WebGPU har prioritet över Ollama, och molnet används bara när ingen av de lokala motorerna är aktiv.