OpenCode CLI Opsætning: 75+ AI-Modeller i 12 Trin [2026]

Terminalen er blevet det nye slagmark for AI-kodeassistenter. Mens Cursor og GitHub Copilot kæmper om IDE-brugerne, har et open source-projekt ved navn OpenCode stille og roligt samlet over 160.000 stjerner på GitHub og en placering øverst i flere rangeringer af AI-udviklerværktøjer i 2026, ifølge en oversigt fra LogRocket i juli 2026. Værktøjet er gratis, kører i din terminal, og du kan koble det til over 75 forskellige AI-modeller uden at være låst til én udbyder. I denne guide sætter vi OpenCode op fra bunden, forbinder det til flere modeller, konfigurerer MCP-servere og bygger et lille, fungerende projekt sammen med agenten. Du får 12 konkrete trin, syv kodeblokke du kan kopiere direkte, og en liste over de fejl der oftest sender nye brugere ud i frustration.

Hvad er OpenCode, og hvem står bag det?

OpenCode er en open source AI-kodeagent bygget til terminalen. Projektet er udviklet af teamet bag serverless-rammeværket SST (nu en del af virksomheden Anomaly), og det er udgivet under MIT-licensen. Det betyder, at koden er fri, at du kan læse hver linje, og at du ikke betaler noget for selve værktøjet. Det du betaler for, er API-kald til den model du vælger at bruge, medmindre du kører en lokal model via Ollama.

Det centrale designvalg i OpenCode er, at agenten er model-agnostisk. Ifølge den officielle dokumentation på opencode.ai bruger værktøjet AI SDK og Models.dev til at understøtte mere end 75 LLM-udbydere, fra Anthropics Claude-familie og OpenAIs GPT-modeller til Googles Gemini, DeepSeek, Kimi og det nyere Poolside. Du kan altså skifte model fra dag til dag, alt efter hvad opgaven kræver, uden at skifte værktøj. Den nyeste udgivelse i skrivende stund er version 1.18.27 fra begyndelsen af september 2026, og projektet har også fået en Android-companion-app, OpenCode Mobile, som blev opdateret den 4. september 2026 og lader dig følge og styre en kørende session fra telefonen via en selvhostet server.

OpenCode kører som en Terminal User Interface (TUI), men den samme motor kan også køre som desktop-app, webgrænseflade eller headless server. Det gør værktøjet velegnet både til den enkelte udvikler, der arbejder lokalt, og til teams, der vil dele en central agent-server over HTTP med Server-Sent Events (SSE).

OpenCodes arkitektur: sådan hænger værktøj, agent og modeller sammen

Det er nemmere at fejlsøge og konfigurere OpenCode rigtigt, når man forstår, hvordan de tre lag i systemet spiller sammen. Nederst ligger klienten, altså den TUI, desktop-app eller webgrænseflade du interagerer med. Klienten taler med en agent-motor, som håndterer selve arbejdsgangen: at læse filer, planlægge ændringer, kalde værktøjer og skrive kode. Øverst ligger modellaget, hvor den faktiske sprogmodel, du har forbundet via /connect, genererer svar og beslutninger.

Fordi de tre lag er adskilt, kan du bytte modellaget uden at røre resten af systemet. Det er også grunden til, at samme AGENTS.md og opencode.json virker uanset om du kører Claude, GPT eller en lokal Ollama-model. Agenten selv er desuden opdelt i to indbyggede roller, build og plan, som beskrevet i trin 4, og du kan i teorien definere flere brugerdefinerede agent-roller til specifikke opgaver, for eksempel en “reviewer”-agent, der kun må kommentere kode, eller en “migration”-agent, der er sat op med adgang til en bestemt MCP-server og intet andet. Denne lagdeling er en af hovedårsagerne til, at OpenCode har vundet indpas hos teams, der allerede bruger flere forskellige modeller til forskellige formål, og som ikke ønsker at vedligeholde en separat konfiguration for hver af dem.

Sammenligner man med hvordan Claude Code eller GitHub Copilot er bygget, er der en klar arkitektonisk forskel. De værktøjer bundter typisk klient og model tættere sammen, hvilket giver en mere strømlinet oplevelse ud af boksen, men mindre frihed hvis du senere vil skifte model eller selvhoste dele af stakken. OpenCodes løsere kobling kræver lidt mere opsætning i starten, men betaler sig hurtigt tilbage, når en ny model lander, og du blot skal ændre en enkelt linje i opencode.json i stedet for at vente på, at leverandøren selv understøtter den.

Derfor vælger flere udviklere OpenCode frem for Copilot og Cursor

Den store forskel mellem OpenCode og de fleste konkurrenter handler om ejerskab og fleksibilitet. GitHub Copilot og Cursor bygger på lukkede backends, hvor du betaler et fast abonnement og accepterer den model, udbyderen har valgt for dig. OpenCode vender det om: du ejer værktøjet, du vælger modellen, og du betaler kun for det du reelt bruger. For danske og nordiske virksomheder, der har skærpet fokus på databehandling efter NIS2 og GDPR, er det en reel fordel, at kildekoden aldrig behøver forlade jeres egen infrastruktur, hvis I selvhoster både agent og model.

Sammenlignet med Aider, som også er et open source terminal-værktøj, tilbyder OpenCode en bredere vifte af overflader (terminal, desktop, web, mobil) og en indbygget model-markedsplads kaldet OpenCode Zen, hvor modeller er testet og benchmarket specifikt til agent-brug. Sammenlignet med Claude Code, som er tæt bundet til Anthropics egne modeller og abonnementer fra 20 til 200 dollar om måneden, giver OpenCode dig valget mellem alle de store udbydere i samme grænseflade. Andre terminal-baserede agenter som Warp og Kiro løser en lignende opgave, men med en anden balance mellem lukket infrastruktur og åbenhed.

Selvhosting er der, hvor forskellen bliver konkret for en dansk virksomhed. Kør du både OpenCode-serveren og en selvhostet eller lokal model på egen infrastruktur, forlader kildekoden aldrig jeres netværk, og I undgår at skulle vurdere en tredjeparts databehandleraftale for hvert eneste API-kald. Det er en anden risikoprofil end at sende kode til en ekstern chatbot i browseren, og det er en af grundene til, at open source-agenter som OpenCode og Aider dukker oftere op i interne retningslinjer hos virksomheder, der er omfattet af NIS2-kravene om leverandørstyring og dokumenteret risikohåndtering.

Værktøj	Licens	Prismodel	Modelvalg	Kører som
OpenCode	MIT (open source)	Gratis værktøj, betal kun udbyder	75+ udbydere, frit valg	Terminal, desktop, web, server
Claude Code	Proprietær	20-200 USD/md	Kun Anthropic-modeller	Terminal, IDE-plugin
Aider	Apache 2.0 (open source)	Gratis værktøj, betal udbyder	Bredt udvalg via API-nøgler	Terminal
GitHub Copilot	Proprietær	0-100 USD/md	Fast sæt af modeller	IDE-plugin, CLI

Det er værd at understrege, at “gratis værktøj” ikke betyder gratis at bruge i praksis. En session, hvor agenten læser en stor kodebase, planlægger en refaktorering og kører flere iterationer med testkørsler, kan sagtens forbruge et par dollars i modeltokens, afhængigt af hvilken model du har valgt. Fordelen ved OpenCodes tilgang er, at du selv ser og styrer det forbrug direkte hos udbyderen, i stedet for at det er skjult i et fast abonnement, du betaler uanset hvor meget eller lidt du bruger værktøjet.

Forudsætninger: Det skal du bruge, før du går i gang

Før du installerer OpenCode, skal et par ting være på plads. Listen herunder er baseret på den officielle dokumentation og dækker de fleste opsætninger, du støder på i praksis. Spring ikke listen over, selv om den ser triviel ud: langt de fleste supportspørgsmål om OpenCode i praksis handler om et manglende punkt herfra, typisk en forkert terminal eller en model, der aldrig blev forbundet ordentligt.

Et af følgende operativsystemer: macOS, Linux, eller Windows (Windows kræver WSL for den bedste oplevelse, men native support findes via Chocolatey, Scoop, npm eller Docker)
En moderne terminalemulator med true color-understøttelse, for eksempel WezTerm, Alacritty, Ghostty eller Kitty (standard cmd.exe på Windows giver en ødelagt visning)
Node.js version 18 eller nyere, hvis du installerer via npm, samt Bun eller pnpm som alternativer
Mindst én API-nøgle fra en model-udbyder (Anthropic, OpenAI, Google eller DeepSeek), medmindre du bruger OpenCode Zen eller en lokal Ollama-model
Git installeret, så AGENTS.md og opencode.json kan versionsstyres sammen med resten af projektet
Cirka 45 minutter til hele opsætningen, inklusive det lille testprojekt i trin 8

Trin 1-2: Installer OpenCode og forbind din første model

Det hurtigste installationsspor er det officielle install-script. Åbn din terminal og kør følgende kommando.

curl -fsSL https://opencode.ai/install | bash

Foretrækker du en pakkehåndtering, understøtter OpenCode flere veje ind. Vælg den, der passer til dit setup.

# npm (kræver Node.js 18+)
npm i -g opencode-ai@latest

# Homebrew (macOS og Linux)
brew install opencode

# Chocolatey (Windows)
choco install opencode

# Docker, uden lokal installation
docker run -it --rm ghcr.io/anomalyco/opencode

Når installationen er færdig, skal du forbinde mindst én AI-model, før agenten kan gøre noget som helst. Naviger til din projektmappe, start OpenCode, og brug kommandoen /connect inde i grænsefladen.

cd mit-projekt
opencode
# Skriv derefter i TUI'en:
/connect

Her får du valget mellem to spor. Det ene er OpenCode Zen, som dokumentationen anbefaler til nye brugere, fordi det er en kurateret liste af modeller, der allerede er testet og benchmarket til agent-arbejde. Det andet er Bring Your Own Key (BYOK), hvor du indsætter din egen API-nøgle fra for eksempel Anthropic eller OpenAI og betaler direkte til udbyderen. De fleste erfarne brugere ender med BYOK, fordi det giver fuld kontrol over, hvilken model der bruges til hvilken opgave, og hvad den koster.

Efter forbindelsen er sat op, er det en god vane at bekræfte, at alt virker, før du går videre. Kør versionskommandoen for at se, hvilken build du kører, og bed derefter agenten om en triviel opgave for at teste forbindelsen.

opencode --version
# forvent noget i stil med: opencode 1.18.27

Viser /connect ingen modeller på listen, eller fejler test-opgaven med det samme, er det næsten altid enten en netværksblokering mod Models.dev eller en API-nøgle, der endnu ikke er aktiveret hos udbyderen. Se fejlfindingsafsnittet længere nede for de konkrete rettelser.

Trin 3: Initialiser projektet og generér AGENTS.md

Med en model forbundet er næste skridt at lade OpenCode lære din kodebase at kende. Kør /init inde i TUI’en.

/init

Kommandoen scanner projektets filstruktur, afhængigheder og eksisterende konventioner, og genererer en fil kaldet AGENTS.md i roden af projektet. Filen fungerer som et levende manifest: den beskriver arkitektur, kommandoer til at bygge og teste projektet, og de regler agenten skal følge, når den skriver kode. Dokumentationen anbefaler eksplicit at committe AGENTS.md til Git, så hele teamet arbejder med samme kontekst, og så en ny udvikler kan læse filen på fem minutter i stedet for at spørge rundt i teamet.

Indholdet i en genereret AGENTS.md er almindelig Markdown, og du kan redigere den i hånden bagefter. Et typisk udsnit fra et Node.js-projekt kunne se sådan ud: en overskrift med projektnavn, en kort beskrivelse af arkitekturen (for eksempel “Express-server med SQLite som datalag”), en liste over kommandoer som npm run dev, npm test og npm run lint, og til sidst en sektion med kodekonventioner, som at alle nye endpoints skal have en tilhørende test. Jo mere præcis denne fil er, jo mindre skal du gentage dig selv i hver eneste prompt, fordi agenten automatisk læser filen som en del af sin kontekst i hver session.

Et typisk output efter /init på et lille Node.js-projekt ser sådan ud i terminalen.

✔ Analyserede 34 filer på tværs af 6 mapper
✔ Fandt package.json, express som afhængighed, jest til test
✔ Genererede AGENTS.md (612 tokens)
✔ Klar. Skriv en opgave, eller tryk Tab for Plan-mode.

Trin 4: Skift mellem Plan-mode og Build-mode

OpenCode har to indbyggede tilstande, og forskellen på dem er vigtig at forstå, før du peger agenten mod rigtig kode. Plan-mode er skrivebeskyttet. Agenten analyserer, foreslår en løsning og viser dig, hvilke filer den vil ændre, men rører intet. Build-mode giver agenten fuld adgang til at skrive filer og køre shell-kommandoer.

Du skifter mellem de to med et enkelt tastetryk: Tab. Den praktiske arbejdsgang, som de fleste erfarne brugere lander på, er at starte enhver ny og risikabel opgave i Plan-mode, læse forslaget igennem, og først derefter trykke Tab og bede agenten udføre planen i Build-mode. Det tager få sekunder ekstra, men det er forskellen på at opdage en dårlig plan før eller efter den rammer produktionskoden.

Trin 5: Konfigurer opencode.json til dit team

Når du vil styre agentens adfærd mere præcist, gør du det i en konfigurationsfil kaldet opencode.json. Den kan ligge to steder: globalt i ~/.config/opencode/opencode.json, hvor indstillingerne gælder for alle dine projekter, eller lokalt i projektets rodmappe, hvor den kun gælder det ene projekt og typisk committes til Git. Projektfilen vinder altid over den globale, hvis de to er i konflikt.

{
  "$schema": "https://opencode.ai/config.json",
  "model": "anthropic/claude-sonnet-4-5",
  "small_model": "anthropic/claude-haiku-4-5",
  "provider": {
    "anthropic": {
      "options": {
        "timeout": 600000,
        "setCacheKey": true
      }
    }
  },
  "tools": {
    "write": true,
    "bash": true
  },
  "autoupdate": true,
  "snapshot": true
}

Feltet small_model er værd at bemærke. Det lader dig pege billige, hurtige delopgaver, som filsøgning og opsummering, mod en mindre model, mens den tunge kodegenerering går til den dyrere hovedmodel. Det er en simpel måde at holde regningen nede på, uden at gå på kompromis med kvaliteten der, hvor det tæller. Feltet tools lader dig i øvrigt slå skriveadgang og shell-kommandoer helt fra, hvilket er relevant, når agenten kun skal bruges til analyse i et delt eller produktionsnært miljø.

De øvrige felter under provider.anthropic.options styrer, hvordan OpenCode taler med udbyderens API. timeout sætter, hvor længe agenten venter på et svar, før den giver op, angivet i millisekunder, hvilket er relevant at hæve, hvis du arbejder med lange, komplekse opgaver, der kræver flere minutters ræsonnement fra modellen. setCacheKey aktiverer prompt-caching hos udbydere, der understøtter det, hvilket kan sænke omkostningerne markant på gentagne kald med samme systemprompt eller AGENTS.md-indhold. Justerer du disse værdier forkert, ender du typisk med enten unødvendigt lange ventetider på fejlende kald, eller en unødigt høj regning, så det er værd at teste ændringer på et enkelt projekt, før du ruller dem ud globalt.

Trin 6: Tilføj flere AI-modeller

Styrken ved OpenCode viser sig for alvor, når du begynder at skifte model efter opgave. En stor refaktorering af en gammel kodebase kan kræve en model med lang kontekst, mens en hurtig fejlrettelse klares fint af en billigere model. Tabellen herunder viser et udsnit af de udbydere, dokumentationen og aktuelle anmeldelser fra 2026 nævner som understøttet gennem Models.dev.

Udbyder	Eksempel på model	Bedst til
Anthropic	Claude Sonnet 4.5, Claude Opus 4.6	Generel kodegenerering og refaktorering
OpenAI	GPT-5.2, GPT-5.1 Codex	Komplekse ræsonnementer og debugging
Google	Gemini 3 Pro	Store kodebaser med lang kontekst
Poolside	Laguna S 2.1 (118B parametre, 8B aktive)	Agentisk kodning med op til 1 mio. tokens kontekst
DeepSeek	DeepSeek-modeller via API	Budgetvenlig kodning i stor skala
Lokal / Ollama	Enhver OpenAI-kompatibel lokal model	Offline-arbejde og følsom kode

Poolside-modellen Laguna S 2.1 er værd at fremhæve, fordi den er blandt de nyeste tilføjelser i økosystemet. Poolside udgav modellen den 21.-22. juli 2026 som en åben, selvhostbar Mixture-of-Experts-model med 118 milliarder parametre i alt, hvoraf kun 8 milliarder aktiveres per token, og med en kontekstgrænse på op til en million tokens. Du forbinder den samme vej som alle andre udbydere: generér en API-nøgle hos Poolside, kør /connect i OpenCode, og vælg Poolside fra listen.

Du behøver ikke forlade en session for at skifte model. De fleste opsætninger binder en genvejskommando til at åbne en modelvælger midt i samtalen, så du kan starte en opgave på en billig model, og hvis den løber ind i noget svært, skifte til en kraftigere model uden at miste konteksten. Det er især nyttigt i det mini-projekt, vi bygger i næste trin: brug en hurtig model til at generere det første udkast, og skift til en model med længere kontekst, hvis agenten skal forstå sammenhænge på tværs af mange filer på én gang.

Trin 7: Sæt MCP-servere op og udvid værktøjskassen

Model Context Protocol, forkortet MCP, er den standard flere AI-kodeassistenter nu bruger til at koble eksterne værktøjer på agenten, fra Jira og GitHub til interne API’er. OpenCode understøtter både lokale og eksterne MCP-servere, konfigureret i samme opencode.json-fil under nøglen mcp.

{
  "mcp": {
    "github": {
      "type": "local",
      "command": ["npx", "-y", "@modelcontextprotocol/server-github"],
      "enabled": true
    },
    "jira": {
      "type": "remote",
      "url": "https://jira.example.com/mcp",
      "headers": { "Authorization": "Bearer {env:JIRA_TOKEN}" },
      "enabled": true
    }
  }
}

Lokale servere starter en kommando på din egen maskine, typisk via npx, mens eksterne servere kobles på via en URL med egne headers til autentificering. Bemærk syntaksen {env:JIRA_TOKEN}, som lader dig hente hemmeligheder fra miljøvariabler i stedet for at skrive dem direkte i filen. Det er en detalje, der ofte overses, men som forhindrer, at API-nøgler ender i Git-historikken. Skal en server bruge OAuth i stedet for en fast nøgle, håndterer OpenCode det automatisk via dynamisk klientregistrering, og du kan trigge login manuelt med opencode mcp auth server-navn.

Hvorfor er det overhovedet vigtigt at koble MCP-servere på en kodeagent? Fordi den model, der driver OpenCode, i sig selv kun kender til det, den kan se i din lokale kodebase. Uden MCP kan agenten ikke selv slå et GitHub-issue op, oprette en Jira-billet eller læse status fra en intern service. Med MCP bliver de eksterne systemer en del af den samme samtale, så du for eksempel kan bede agenten om at “ret fejlen beskrevet i issue 482 og luk billetten, når testene er grønne”, og den kan udføre hele kæden selv, forudsat at de rette servere er konfigureret og godkendt. Brug opencode mcp list jævnligt til at holde styr på, hvilke servere der reelt er aktive i dit projekt, særligt hvis flere kolleger har tilføjet servere over tid.

Trin 8-9: Byg et komplet mini-projekt med OpenCode

Teori er godt, men den bedste måde at forstå OpenCode på er at lade den bygge noget fra bunden. Vi laver et lille Express-API med en SQLite-database og en håndfuld endpoints til en simpel opgaveliste. Start i en tom mappe.

mkdir todo-api && cd todo-api
npm init -y
opencode

Tryk Tab for at sikre dig, at du starter i Plan-mode, og bed derefter agenten om at skitsere projektet.

> Byg en lille Express-server med SQLite. Jeg vil have
  endpoints til at oprette, liste, opdatere og slette
  opgaver i en tabel "tasks" med felterne id, title og done.
  Skriv også tre grundlæggende tests med Jest.

I Plan-mode svarer agenten typisk med en filliste og en kort begrundelse, for eksempel server.js, db.js, routes/tasks.js og tests/tasks.test.js, plus hvilke npm-pakker den vil installere (express, better-sqlite3, jest, supertest). Gennemgå listen. Ser den fornuftig ud, trykker du Tab igen for at skifte til Build-mode og skriver:

> Udfør planen, og kør testene bagefter.

Agenten opretter filerne, installerer afhængighederne via en shell-kommando, og kører til sidst npm test. Et typisk afsluttende output ser sådan ud.

PASS tests/tasks.test.js
  Tasks API
    ✓ opretter en ny opgave (42 ms)
    ✓ henter listen af opgaver (11 ms)
    ✓ markerer en opgave som færdig (9 ms)

Tests: 3 passed, 3 total
✔ Ændrede 5 filer, oprettede 4 nye
✔ Snapshot gemt. Skriv /undo for at fortryde ændringerne.

Bemærk den sidste linje. Fordi snapshot er slået til i konfigurationen, kan du altid fortryde med /undo, hvis testene fejler eller output ikke er, hvad du forventede, og bagefter gøre det om igen med /redo. Det er den samme sikkerhedsmekanisme, der gør det forsvarligt at lade agenten køre shell-kommandoer uden at overvåge hver eneste linje.

Åbner du en af de genererede filer, ser du typisk ren, læsbar kode uden overflødige kommentarer. Route-filen til opgaverne kan for eksempel se sådan ud.

// routes/tasks.js
const express = require('express');
const router = express.Router();
const db = require('../db');

router.get('/tasks', (req, res) => {
  const tasks = db.prepare('SELECT * FROM tasks').all();
  res.json(tasks);
});

router.post('/tasks', (req, res) => {
  const { title } = req.body;
  const info = db
    .prepare('INSERT INTO tasks (title, done) VALUES (?, 0)')
    .run(title);
  res.status(201).json({ id: info.lastInsertRowid, title, done: 0 });
});

module.exports = router;

Vil du udvide projektet, er den naturlige næste opgave at bede agenten om validering af input, pagination på listen, eller en Dockerfile til at pakke API’et. Fordi AGENTS.md og opencode.json nu ligger i projektet, husker agenten konventionerne fra første prompt, også i en ny session dagen efter.

Det er også her, du mærker forskellen mellem en autocomplete-assistent og en agent. En klassisk kodeassistent foreslår den næste linje, mens du selv styrer filstruktur, afhængigheder og testkørsel. OpenCode tager hele kæden: den opretter filerne, kører npm install, skriver testene og verificerer selv, at de består, før den melder opgaven færdig. Det er den samme arbejdsgang, der gør værktøjet nyttigt til større opgaver som at tilføje autentificering til API’et, eller flytte datalaget fra SQLite til Postgres, uden at du skal styre hvert enkelt underskridt manuelt.

Trin 10-11: Kør OpenCode som selvhostet server og del sessioner

Ud over terminalbrug kan OpenCode køre som en server, du selv hoster, hvilket åbner for teamsamarbejde og adgang fra mobilen. Server-delen konfigureres også i opencode.json.

{
  "server": {
    "port": 4096,
    "hostname": "0.0.0.0",
    "cors": ["http://localhost:5173"]
  }
}

Med serveren kørende kan du følge og styre en session fra OpenCode Mobile-appen til Android, som blev opdateret den 4. september 2026 og kobler sig på den selvhostede server via HTTP og Server-Sent Events. Det giver dig mulighed for at godkende værktøjskald, se diffs og guide en igangværende Claude- eller GPT-session, mens du er væk fra tastaturet. Inde i en session kan du desuden dele en samtale med kollegaer via /share, hvilket genererer et link til gennemsyn, mens /undo og /redo giver jer et fælles sikkerhedsnet, når flere rører ved den samme kodebase.

Trin 12: Lås værktøjer ned til sikker virksomhedsbrug

Det sidste trin er relevant, hvis flere kolleger deler samme agent-opsætning, eller hvis I kører OpenCode i en pipeline. Sæt tools.write og tools.bash til false i den globale konfiguration, hvis agenten kun må analysere og aldrig ændre noget uden eksplicit godkendelse. Kombinér det med glob-mønstre på MCP-servere, så en given agent kun kan tilgå de servere, opgaven kræver, og aldrig hele værktøjskassen. For CI-brug er det en god idé at låse modelversionen fast i stedet for at lade autoupdate hente nye versioner midt i en pipeline, hvor en uventet adfærdsændring kan vælte en build.

Hold desuden snapshot slået til på alle delte maskiner, ikke kun på din egen. Fordi hver ændring bliver gemt som et snapshot, kan I altid rulle en agent-session tilbage, hvis den viser sig at have introduceret en fejl, uden at skulle grave i Git-historikken for at finde ud af, hvad der blev ændret hvornår. Skal I dokumentere for en revisor eller et compliance-team, hvad en AI-agent har rørt ved i en given periode, er snapshot-loggen og AGENTS.md-historikken tilsammen et konkret sted at starte, i stedet for at forsøge at rekonstruere det fra hukommelsen.

Typiske brugssituationer for OpenCode i danske teams

Opsætningen ovenfor dækker det tekniske, men det er værd at se på, hvor OpenCode reelt gør en forskel i hverdagen. Den første og mest oplagte brug er onboarding. En ny udvikler kan pege agenten mod en ukendt kodebase, bede om en gennemgang af arkitekturen, og få svar på baggrund af det AGENTS.md allerede har kortlagt, i stedet for at bruge den første uge på at spørge kollegaer.

Den anden er migrering af ældre kode. Fordi du kan pege en model med lang kontekst, som Poolsides Laguna S 2.1 eller Googles Gemini 3 Pro, mod en hel kodebase på én gang, bliver store, kedelige opgaver som at opdatere et forældet API-bibliotek eller migrere fra en gammel testramme til en ny langt hurtigere at komme i gang med. Den tredje er automatiserede kodegennemgange i CI, hvor en headless OpenCode-server kører i Plan-mode og kommenterer på et pull request, uden nogensinde at få skriveadgang til grenen. Den fjerde, og måske mest oversete, er dokumentation: fordi agenten allerede har læst hele projektet for at kunne kode i det, er den også god til at generere eller opdatere README-filer og API-dokumentation, når koden ændrer sig.

Almindelige faldgruber, når du sætter OpenCode op

De fleste problemer nye brugere støder på, handler ikke om selve AI-modellen, men om opsætningen omkring den. Her er de fejl, der går igen.

Du glemmer at forbinde en model med /connect, før du prøver at give agenten en opgave, og får en tom eller fejlende session.
Du kører OpenCode i standard Windows cmd.exe i stedet for WSL eller en terminal med true color, og grænsefladen ser ødelagt ud.
Du committer opencode.json med en API-nøgle skrevet direkte i filen i stedet for at bruge {env:NØGLE_NAVN}, og nøglen ender i Git-historikken.
Du lader agenten arbejde direkte i Build-mode på en produktionsgren uden først at se planen i Plan-mode.
Du sætter en dyr model som standard for alle opgaver i stedet for at bruge small_model til de billige, og regningen vokser hurtigere end nødvendigt.
Du glemmer at committe AGENTS.md, så resten af teamet arbejder med en agent, der ikke kender projektets konventioner.
Du giver en MCP-server fuld adgang, uden at afgrænse hvilke agenter der må bruge den, via de glob-mønstre konfigurationen understøtter.
Du antager, at alle modeller opfører sig ens, og bliver overrasket, når en billigere model laver flere fejl på en kompleks refaktorering end den dyrere model, du testede med først.
Du lader autoupdate stå til i et CI-miljø, og en ny version ændrer adfærd midt i en byggeproces uden varsel.

Fælles for de fleste af disse faldgruber er, at de opstår, fordi OpenCode giver dig langt flere håndtag at dreje på end et lukket, abonnementsbaseret værktøj. Det er samtidig styrken ved værktøjet: du kan rette hver af fejlene ovenfor med én linje i en konfigurationsfil, i stedet for at vente på en leverandør ændrer en indstilling for dig.

Fejlfinding: 8 problemer og løsninger

Selv med forudsætningerne på plads støder de fleste brugere på mindst ét af følgende problemer i løbet af de første par uger. Tabellen samler de mest almindelige, sammen med den hurtigste vej til en løsning, så du slipper for at grave dig gennem GitHub-issues for at finde svaret.

Problem	Sandsynlig årsag	Løsning
“command not found: opencode”	Install-scriptets binary-mappe er ikke i PATH	Genstart terminalen, eller tilføj mappen manuelt til PATH
401 Unauthorized fra provider	Forkert, udløbet eller manglende API-nøgle	Kør `/connect` igen, og indsæt en frisk nøgle
TUI’en ser ødelagt ud, uden farver	Terminalen mangler true color-understøttelse	Skift til WezTerm, Alacritty, Ghostty eller Kitty
/connect viser ingen modeller	Firewall blokerer adgang til Models.dev	Tjek netværksadgang, eller brug en lokal Ollama-model
Docker-container ser ikke projektfiler	Manglende volume-mount ved opstart	Tilføj -v $(pwd):/workspace til docker run
MCP-server svarer ikke	Forkert kommando-sti eller manglende npx-adgang	Test kommandoen manuelt i terminalen først
opencode.json bliver ignoreret	Filen ligger forkert sted, eller har en JSON-syntaksfejl	Tjek placering, og valider JSON’en med en linter
Timeout i server-mode fra mobilen	Forkert hostname, port eller lukket firewall-port	Sæt hostname til 0.0.0.0, og åbn den valgte port

Avancerede tips og OpenCode sammenlignet med konkurrenterne

Når grundopsætningen sidder, er der en række mindre kendte funktioner, der løfter arbejdsgangen. Brug variabelsubstitution i konfigurationen, både {env:...} til miljøvariabler og {file:...} til at trække indhold ind fra en anden fil, så du kan genbruge systemprompter på tværs af projekter. Sæt tools.bash til false i et delt review-miljø, hvis agenten kun skal analysere og aldrig køre kommandoer. Brug glob-mønstre som "mcp-navn*" til at styre, hvilke agenter der har adgang til hvilke MCP-servere, i stedet for at give alle agenter adgang til alt. Og hold autoupdate slået til, medmindre I har en god grund til at låse en bestemt version fast i CI.

Nogle flere tips fra erfarne brugere er værd at tage med sig, når værktøjet skal bruges i drift og ikke bare til leg. Sæt et budget-loft hos din model-udbyder, så en agent, der løber løbsk i en løkke, ikke sender en overraskende regning. Brug /share aktivt i teamet, når en agent løser noget uventet svært, så andre kan lære af sessionen. Test altid en ny model på en gren, før den bliver standard, fordi svarstil og kvalitet varierer betydeligt mellem for eksempel Claude, GPT og en lokal Ollama-model. Og hold øje med release-siden på GitHub, da OpenCode med sit tempo på flere udgivelser om måneden ofte tilføjer nye kommandoer og konfigurationsmuligheder, der ikke altid er dokumenteret i detaljer med det samme.

Sammenlignet med Claude Code og GitHub Copilot er OpenCodes styrke fleksibiliteten. Du er ikke bundet til ét abonnement eller én models prisstruktur, og du kan flytte hele opsætningen mellem projekter ved at kopiere to JSON-filer. Prisen for den frihed er, at du selv skal styre nøgler, budgetter og opdateringer, som ellers ville være skjult bag et fast månedsgebyr. For et lille team eller en enkelt udvikler, der allerede er komfortabel i terminalen, vejer fordelene typisk tungere end besværet. For et team, der vil have alt håndteret centralt uden konfiguration, kan et abonnementsbaseret værktøj som Claude Code eller Copilot stadig give mere ro i maskinen.

Ofte stillede spørgsmål

Er OpenCode gratis?
Selve værktøjet er gratis og open source under MIT-licensen. Du betaler kun for de API-kald, du foretager til den model, du vælger, medmindre du kører en lokal model via Ollama, som er helt gratis at bruge.

Kan jeg bruge OpenCode uden internetforbindelse?
Ja, hvis du forbinder en lokal model via Ollama eller en anden OpenAI-kompatibel lokal endpoint. Så kører hele arbejdsgangen offline, og ingen kode forlader din maskine.

Er OpenCode sikkert nok til virksomhedskode under GDPR og NIS2?
Værktøjet i sig selv sender ikke data nogen steder, men den model du forbinder til, gør. Vælg en udbyder med databehandleraftale, eller selvhost både agent og model, hvis kildekoden er følsom.

Hvordan adskiller OpenCode sig fra Claude Code?
Claude Code er bundet til Anthropics egne modeller og et fast abonnement. OpenCode er model-agnostisk, open source, og lader dig frit vælge og skifte mellem over 75 udbydere.

Kan jeg bruge OpenCode i en IDE, eller kun i terminalen?
Primært er OpenCode bygget til terminalen, men den samme motor kører også som desktop-app og webgrænseflade, og en server-tilstand giver adgang fra andre klienter, inklusive den officielle mobilapp.

Understøtter OpenCode danske kommentarer og dokumentation i koden?
Ja. Fordi du selv vælger den underliggende sprogmodel, kan du bede agenten skrive kommentarer, commit-beskeder og dokumentation på dansk, ligesom du ville med enhver anden model.

Hvad koster det typisk at bruge OpenCode med Claude eller GPT?
Det afhænger helt af udbyderens egen prisliste og hvor meget kontekst dine opgaver bruger. Brug feltet small_model til de billige delopgaver, så du ikke betaler hovedmodellens pris for simple søgninger.

Kan jeg køre OpenCode på en server uden grafisk brugerflade?
Ja. Server-tilstanden og Docker-billedet er lavet netop til det, og du kan køre agenten headless på en Linux-server og tilgå den via web eller mobilappen over HTTP og SSE.