OpenHands: 60,6% SWE-Bench Score i 12 Trin [2026]

Open source-agenten OpenHands har på under to år bevæget sig fra et forskningsprojekt under navnet OpenDevin til en af de mest omtalte autonome kodeagenter i 2026. Projektet, der drives af selskabet All Hands AI, ligger frit tilgængeligt på GitHub under MIT-licens og kan installeres lokalt, i eget cloud-miljø eller hos en enterprise-udbyder. Den nyeste udgivelse, version 1.17.0, landede den 9. september 2026, og den understøtter i dag både Anthropics Claude-modeller, OpenAIs GPT-modeller og Googles Gemini-familie gennem én samlet platform.

Denne guide viser dig, hvordan du sætter OpenHands op fra bunden: fra Docker-installation til din første løste GitHub-issue. Du får 12 konkrete trin, ti kodeeksempler, en liste over faldgruber du bør kende på forhånd, og en fejlfindingssektion til de problemer, der oftest sender nye brugere ud i lange Discord-tråde. Du behøver ikke være ekspert i containerteknologi for at følge med, men du skal have en API-nøgle til mindst én sprogmodel klar, før du starter.

Guiden er skrevet med et dansk og nordisk udviklerteam for øje. Netop fordi OpenHands kan køre helt lokalt eller i eget cloud-miljø, er det relevant for organisationer, der arbejder under GDPR og skal kunne dokumentere, hvor kildekode og kundedata bevæger sig hen, når en AI-agent får adgang til dem. Det vender vi tilbage til i et separat afsnit, før vi går i gang med selve installationen.

Hvad er OpenHands, og hvorfor er det relevant i 2026?

OpenHands er en modeluafhængig platform til autonome kodeagenter, som du kan læse mere om på projektets officielle side. I stedet for at foreslå enkelte kodelinjer, som en klassisk autocomplete-assistent gør, kan en OpenHands-agent selv åbne filer, køre terminalkommandoer, navigere i en browser og oprette pull requests, alt sammen inde i en isoleret Docker-sandkasse. Platformen består af fire hoveddele: en Agent Server, der styrer selve agentlogikken, en Sandbox Server, der kører koden isoleret, Agent Canvas, som er den webbaserede kontrolflade du arbejder i, og en Software Agent SDK til udviklere, der vil bygge deres egne agent-integrationer.

Det, der gør arkitekturen interessant i praksis, er, at de fire dele kan skaleres og udskiftes uafhængigt af hinanden. Du kan for eksempel køre Sandbox Server på en kraftig maskine med mange CPU-kerner, mens Agent Canvas kører på en almindelig bærbar, og selve sprogmodellen ligger hos en ekstern udbyder. Kommunikationen mellem delene foregår via det, projektet kalder Agent Control Protocol (ACP), som også er grunden til, at OpenHands kan invitere tredjepartsagenter som Claude Code eller Codex ind som gæstearbejdere i din egen opsætning, i stedet for at du skal vælge én agent og leve med den for evigt.

Projektet hed oprindeligt OpenDevin, men skiftede navn til OpenHands, da det flyttede fra et rent forskningsprojekt til en produktionsklar platform under All Hands AI, som beskrevet på projektets Wikipedia-side. Det ligger i dag på GitHub under organisationen OpenHands, og ifølge en sammenligning fra Codesota har projektet passeret 87.000 stjerner på GitHub med ugentlige udgivelser, hvilket sætter det blandt de mest aktive open source-projekter inden for autonome kodeagenter. All Hands AI beskrives i flere brancheprofiler som venturefinansieret, men der findes ingen offentligt bekræftede tal for finansieringsrunden, så det tal springer vi bevidst over her.

Navneskiftet er ikke bare kosmetisk. Hvor OpenDevin var et akademisk eksperiment bygget til at teste, hvor langt en åben agent kunne komme på forskningsbenchmarks, er OpenHands i dag bygget til at blive kørt af rigtige teams, med de kedelige, men nødvendige ting som adgangsstyring, logging og en supporteret opgraderingssti mellem versioner. Det er den udvikling, der gør platformen relevant for en artikel som denne, fremfor blot endnu et forskningsprojekt på GitHub, der aldrig kommer længere end en README-fil.

Det, der adskiller OpenHands fra mange lukkede alternativer, er kombinationen af fuld gennemsigtighed i koden og en reel benchmark-track record. På SWE-bench Verified, som tester, om en agent selvstændigt kan løse rigtige GitHub-issues fra åbne kodebaser, når OpenHands 60,6 procent i én enkelt forsøgsrunde med Claude 3.7 Sonnet og 66,4 procent, når agenten får lov til fem forsøg pr. opgave, ifølge tal fra AI Wiki. Det gør platformen til et af de stærkeste offentligt dokumenterede scaffolds i sin klasse, men som du skal se i næste afsnit, er de allerhøjeste tal, du støder på i markedsføring, sværere at verificere uafhængigt.

OpenHands vs Devin og Claude Code: sådan adskiller agenterne sig

Før du investerer tid i opsætningen, er det værd at forstå, hvor OpenHands passer ind blandt de andre autonome agenter, du sandsynligvis allerede kender. Devin er et lukket, kommercielt produkt, mens Claude Code er Anthropics egen kodeassistent, bygget som et enkelt-agent-værktøj snarere end en flerlags platform. OpenHands adskiller sig ved at være åbent, selvhostet og i stand til at køre andre agenter, inklusive Claude Code selv, som en integreret komponent via sin ACP-grænseflade (Agent Control Protocol).

På benchmark-siden skal tallene læses med et kritisk blik. SWE-bench Verified er i dag en af de mest brugte målestokke for, hvor godt en kodeagent klarer sig på virkelige, uåbnede GitHub-issues, netop fordi testene stammer fra rigtige projekter og ikke syntetiske øvelser. Flere brancheprofiler citerer et tal på 72 til 77 procent på SWE-bench Verified for OpenHands’ egen SDK kørt med Claude Sonnet 4.5 eller Opus 4.5 med udvidet tænkning, men det tal stammer fra OpenHands’ eget forskningspaper og er ifølge en gennemgang fra BestAIQ ikke blevet uafhængigt genskabt. Samme gennemgang peger på, at tredjepartstests med andre modelkombinationer typisk lander omkring 53 procent. En sammenligning fra GTM Directory sætter Devin 2.0’s score omkring 27 point lavere end OpenHands’ højeste selvrapporterede tal, men også her er der tale om en ekstern sammenligningsside og ikke en officiel, uafhængig audit. Konklusionen for dig som bruger: brug de konservative 60,6 til 66,4 procent som dit realistiske udgangspunkt, og betragt alt over 70 procent som et bedste-tilfælde-scenarie, der kræver den dyreste model og den mest optimerede prompt-opsætning.

Egenskab	OpenHands	Devin	Claude Code
Licensmodel	Open source (MIT)	Lukket, kommerciel	Lukket, kommerciel
Selvhosting mulig	Ja, lokalt eller i egen VPC	Nej	Delvis, via CLI lokalt
Understøttede LLM-udbydere	Anthropic, OpenAI, Google, m.fl.	Proprietær model	Primært Anthropics egne modeller
SWE-bench Verified (konservativt tal)	60,6-66,4%	Ikke offentligt sammenligneligt	Ikke direkte sammenlignet i samme test
Web-UI med indbygget editor	Ja (Agent Canvas)	Ja	Nej, terminalbaseret
Multi-agent-delegering	Ja	Begrænset	Nej
Enterprise-funktioner (RBAC, audit log)	Ja	Ja	Delvis via Anthropic Console

Ifølge Stack Overflows Developer Survey 2025 bruger 84 procent af respondenterne allerede AI-værktøjer i deres udviklingsarbejde, eller planlægger at gøre det, og 51 procent af professionelle udviklere bruger AI-værktøjer dagligt (Stack Overflow, 2025). Samtidig viser samme undersøgelse, at kun 31 procent af udviklerne rent faktisk bruger AI-agenter i dag, mens yderligere 17 procent planlægger at gøre det (Stack Overflow, 2025). Det gab mellem “bruger AI-værktøjer” og “bruger AI-agenter” er præcis den niche, OpenHands forsøger at lukke: det er ikke bare et forslagsværktøj, men en agent, der selv gennemfører opgaven fra start til pull request.

OpenHands og GDPR: hvorfor selvhosting betyder noget for nordiske teams

For danske og nordiske virksomheder er spørgsmålet om, hvor koden og de tilhørende data rejser hen, sjældent akademisk. Når en kodeagent får adgang til et helt repository, kan det repository indeholde alt fra kundedata i testfixtures til interne API-nøgler i konfigurationsfiler. Med et lukket, cloud-baseret agentværktøj har du typisk ingen mulighed for at se, hvilken infrastruktur dine data passerer igennem, eller hvor længe leverandøren opbevarer logs af, hvad agenten har læst og skrevet.

OpenHands’ arkitektur giver dig et alternativ, fordi hele stakken, Agent Server, Sandbox Server og Agent Canvas, kan køre på din egen infrastruktur, uden at kildekoden nogensinde forlader jeres eget netværk. Den eneste eksterne trafik, du ikke kan undgå, er selve API-kaldet til sprogmodellen, medmindre du vælger en lokalt hostet model. Det betyder, at du stadig skal forholde dig til, hvilken databehandleraftale du har med din LLM-udbyder, men du fjerner mindst ét lag af tredjepartsafhængighed sammenlignet med en fuldt hostet SaaS-agent. For teams, der allerede har styr på egen VPC-drift, er det ofte den afgørende faktor for, om et autonomt agentværktøj overhovedet kan godkendes internt.

Forudsætninger: dette skal du bruge, før du starter

OpenHands er ikke et enkelt program, du installerer med ét klik. Det er en samling af tjenester, der kører sammen via Docker, så du skal bruge en fungerende container-opsætning og mindst én API-nøgle til en sprogmodel, før agenten kan gøre noget som helst. Sæt 30-45 minutter af til selve installationen, hvis det er første gang du arbejder med Docker Compose. Kender du ikke Docker i forvejen, er Dockers egen introduktion et godt sted at starte, før du går videre til trin 1.

Krav	Anbefalet version/omfang	Formål
Docker Desktop eller Docker Engine	Nyeste stabile version med Docker Compose v2	Kører Agent Server, Sandbox Server og Agent Canvas isoleret
Git	Nyeste stabile version	Henter kildekoden fra github.com/OpenHands/openhands
Python	Nyeste stabile 3.x-udgave	Kræves, hvis du bygger egne agenter med Software Agent SDK
RAM	Mindst 8 GB, gerne 16 GB	Sandkassen kører en fuld udviklingsmiljø-container pr. session
API-nøgle	Anthropic, OpenAI eller Google (mindst én)	Selve “hjernen” bag agenten køres via en ekstern model
Diskplads	Mindst 10 GB ledig	Docker-images til sandkassemiljøet fylder mere, end de fleste forventer

Bemærk at OpenHands selv er gratis og MIT-licenseret, men du betaler stadig for hvert API-kald til den model, du vælger. Det er den reelle omkostning ved at køre platformen, og den kan løbe op, hvis en agent kører i mange forsøgsrunder på en svær opgave. Vi kommer tilbage til, hvordan du holder styr på det i trin 11.

Trin 1-2: Installer Docker og hent OpenHands fra GitHub

Trin 1: Verificér din Docker-installation

Start med at bekræfte, at Docker kører korrekt, og at Compose-pluginet er tilgængeligt. Åbn en terminal og kør følgende to kommandoer.

docker --version
docker compose version

Hvis begge kommandoer returnerer et versionsnummer uden fejl, er du klar. Får du “command not found”, skal du installere Docker Desktop (Windows/Mac) eller Docker Engine plus Compose-plugin (Linux), før du går videre.

Trin 2: Klon repositoriet og gå ind i mappen

Hent den officielle kildekode fra GitHub-organisationen OpenHands. Undgå ældre forks eller spejle, da de kan mangle de seneste sikkerhedsrettelser.

git clone https://github.com/OpenHands/openhands.git
cd openhands
ls -la

Du bør nu se mapper som agent-server, sandbox, canvas og en docker-compose.yml i roden. Er nogen af disse mapper tomme, er clone-processen sandsynligvis blevet afbrudt, og du bør køre git status for at tjekke.

Trin 3-4: Konfigurer din LLM-udbyder og start serverne

Trin 3: Opret din konfigurationsfil

OpenHands er modeluafhængig, så du skal fortælle den, hvilken udbyder og model den skal bruge. Kopiér eksempelfilen og udfyld din egen nøgle.

cp .env.example .env

# Rediger .env og udfyld:
LLM_PROVIDER=anthropic
LLM_MODEL=claude-sonnet-4-5
ANTHROPIC_API_KEY=din-api-noegle-her
WORKSPACE_DIR=./workspace

Vil du i stedet bruge OpenAI eller Google som udbyder, ændrer du blot LLM_PROVIDER og indsætter den relevante nøgle. Fordi platformen er modeluafhængig, kan du senere skifte model uden at ændre resten af opsætningen, hvilket er nyttigt, hvis du vil sammenligne, hvordan forskellige modeller løser den samme opgave.

Trin 4: Start Agent Server, Sandbox Server og Agent Canvas

Med konfigurationen på plads kan du starte hele stakken med én kommando.

docker compose up -d

# Tjek at alle tre tjenester kører:
docker compose ps

Første opstart tager typisk to til fem minutter, fordi Docker skal hente og bygge sandkasse-imagen. Når docker compose ps viser status “running” for alle tre tjenester, kan du åbne Agent Canvas i din browser, som som standard kører på http://localhost:3000.

Sådan vælger du den rigtige LLM-model til opgaven

Fordi OpenHands er modeluafhængig, står du med et reelt valg hver gang du starter en ny samtale, og det valg påvirker både pris, kvalitet og hastighed markant. En tommelfingerregel er at matche modellens “tænkekraft” til opgavens kompleksitet, i stedet for altid at gribe efter den dyreste model, som var tilgængelig, da du sidst tjekkede nyhederne.

Til rutineopgaver som at tilføje en enkelt test, opdatere en afhængighed eller rette en lint-fejl, er en hurtigere og billigere model ofte tilstrækkelig, fordi opgaven har et snævert løsningsrum og en klar succesmåling. Til komplekse opgaver, hvor agenten selv skal finde årsagen til en fejl på tværs af flere filer, eller hvor der ikke findes en eksisterende test at læne sig op ad, giver det mening at bruge en model med udvidet tænkning, kombineret med multi-attempt scaling fra trin 8. Har du adgang til flere udbydere, er det en god vane at køre den samme afgrænsede opgave gennem to forskellige modeller en enkelt gang, når du sætter et nyt projekt op, for at få en fornemmelse af, hvilken model der passer bedst til netop jeres kodestil og sprog. Dokumentationen for Software Agent SDK’et, som du støder på i trin 9, beskriver de tekniske detaljer for, hvordan modelskift konfigureres, på All Hands AI’s udviklerdokumentation.

Trin 5-6: Opret din første samtale og giv agenten en opgave

Trin 5: Åbn Agent Canvas og forbind dit repository

Agent Canvas er webfladen, hvor du starter samtaler, overvåger agentens handlinger og ser filændringer i realtid, inklusive en indbygget editor, der minder om VS Code. Klik på “New Conversation”, og vælg om agenten skal arbejde i en tom sandkasse eller mod et eksisterende Git-repository, du forbinder via HTTPS eller SSH.

Trin 6: Giv agenten din første rigtige opgave

Skriv en konkret, afgrænset instruks. Vage opgaver som “forbedr min kode” giver dårlige resultater, mens specifikke opgaver med et klart succeskriterium fungerer markant bedre. Et eksempel på en god første opgave:

Opgave: Tilføj enhedstest for funktionen calculate_discount() i utils/pricing.py.
Testene skal dække: normal rabat, rabat på 0%, rabat på 100%, og negativ pris (skal kaste ValueError).
Brug pytest. Kør testene til sidst og vis output.

Agenten vil nu selv åbne filen, analysere funktionen, skrive testfilen, køre pytest i sandkassen og vise dig resultatet. Et typisk output-eksempel ser sådan ud:

$ pytest tests/test_pricing.py -v
tests/test_pricing.py::test_normal_discount PASSED
tests/test_pricing.py::test_zero_discount PASSED
tests/test_pricing.py::test_full_discount PASSED
tests/test_pricing.py::test_negative_price_raises PASSED

4 passed in 0.31s

Ser du i stedet fejl eller et tomt output, er det som regel fordi agenten ikke har adgang til de rigtige afhængigheder i sandkassen. Vi dækker den fejl konkret i fejlfindingsafsnittet.

Trin 7-8: Sikkerhedspolitikker og multi-attempt scaling

Trin 7: Begræns, hvad agenten må røre ved

Selvom sandkassen isolerer agentens handlinger fra dit værtssystem, bør du stadig sætte eksplicitte grænser, især hvis flere personer på et team deler den samme opsætning. Opret eller rediger policy-filen i roden af projektet.

# policy.yaml
allowed_commands:
  - pytest
  - npm test
  - git diff
  - git commit
blocked_paths:
  - .env
  - secrets/
max_tokens_per_task: 200000
max_attempts_per_task: 3

Denne type policy-fil svarer til den rolle-baserede adgangskontrol og de audit-spor, som flere gennemgange fremhæver som en af OpenHands’ styrker i teamsammenhænge, sammenlignet med enklere enkelt-agent-værktøjer.

Trin 8: Slå multi-attempt scaling til for svære opgaver

Husk tallene fra tidligere: 60,6 procent i ét forsøg mod 66,4 procent med fem forsøg på SWE-bench Verified. Den forskel kommer fra en indstilling, du selv kan aktivere for komplekse opgaver, hvor agenten får lov at prøve flere strategier og vælge den bedste løsning ud fra testresultater.

agent_config:
  scaling_strategy: multi_attempt
  attempts: 5
  selection_criteria: test_pass_rate

Vær opmærksom på, at fem forsøg betyder op mod fem gange så mange API-kald til din sprogmodel. Brug kun denne indstilling til opgaver, hvor kvalitet vejer tungere end omkostning, for eksempel en kompliceret bugfix, ikke en simpel formattering.

Trin 9-10: Integrer med dit eget repository og automatisér med Canvas Apps

Trin 9: Byg en tilpasset integration med Software Agent SDK

Vil du bruge OpenHands som en del af et eget script eller CI/CD-flow i stedet for at åbne Agent Canvas manuelt hver gang, kan du bruge Python-SDK’et direkte.

from openhands_sdk import Agent, Task

agent = Agent(provider="anthropic", model="claude-sonnet-4-5")
task = Task(
    instruction="Ret fejlen beskrevet i issue #482 og opret en pull request",
    repo_path="./my-project",
)

result = agent.run(task)
print(result.summary)
print(result.pull_request_url)

Dette mønster gør det muligt at trigge agenten automatisk, for eksempel når et nyt issue oprettes med et bestemt label i dit repository. En simpel udgave af sådan en trigger i en CI-pipeline kan se sådan ud, hvis du bruger GitHub Actions til at reagere på nye issues:

# .github/workflows/openhands-trigger.yml
on:
  issues:
    types: [labeled]
jobs:
  run-agent:
    if: github.event.label.name == 'openhands-fix'
    runs-on: self-hosted
    steps:
      - name: Kør OpenHands-agent på issue
        run: python trigger_agent.py --issue "${{ github.event.issue.number }}"

Her kalder trigger_agent.py det samme SDK-kald, du så ovenfor, blot med issue-nummeret indsat dynamisk. Det gør, at et team kan sætte en fast konvention op, hvor et label som “openhands-fix” er nok til at sætte en agent i gang, uden at nogen behøver åbne Agent Canvas manuelt for rutineopgaver.

Trin 10: Automatisér gentagne opgaver med Canvas Apps

Agent Canvas understøtter det, projektet selv kalder Canvas Apps, altså foruddefinerede automationsflows. Et typisk eksempel er en app, der ugentligt gennemgår åbne issues, kategoriserer dem efter sværhedsgrad, og sender en opsummering til et Slack-kanal eller en anden notifikationskanal. Det kræver ingen kode fra din side ud over selve trigger-opsætningen i Canvas-fladen, og det er den type funktion, der gør platformen relevant for teams, der vil have løbende overblik uden at skulle overvåge hver samtale manuelt.

Trin 11-12: Styr omkostninger og skalér til enterprise og VPC

Trin 11: Hold styr på token-forbrug

Fordi OpenHands selv er gratis, men afhænger af betalte API-kald, er det klogt at sætte en øvre grænse på forbrug pr. opgave, som du så i policy-filen i trin 7. Tjek desuden dashboardet hos din LLM-udbyder løbende i den første uge, så du har en realistisk fornemmelse af, hvad en typisk opgave koster, før du skalerer op til hele teamet.

Trin 12: Vælg mellem lokal drift, OpenHands Cloud og VPC

Når du har testet opsætningen lokalt, kan du vælge mellem tre driftsmodeller: fortsat lokal drift på egen maskine, OpenHands Cloud som en hostet SaaS-løsning, eller en Enterprise-installation i din egen VPC med udvidet logging og compliance-funktioner. Lokalt er billigst og bedst til test, Cloud er hurtigst at komme i gang med for et lille team, og VPC-modellen er den, der giver mest kontrol til organisationer med krav om, at kildekoden aldrig forlader eget miljø.

For et lille udviklerteam på under ti personer er lokal drift eller Cloud typisk tilstrækkeligt, fordi behovet for rollestyring og revisionsspor endnu er begrænset. Så snart flere teams eller afdelinger begynder at dele samme installation, eller så snart et compliance-krav dukker op internt, giver Enterprise- og VPC-sporet mere mening, fordi du her får de kontroller, der gør det muligt at dokumentere, hvem der har kørt hvilke agent-sessioner mod hvilke repositories, hvilket ofte er en forudsætning for at få et autonomt agentværktøj godkendt af en intern sikkerhedsansvarlig.

Byg et komplet projekt: løs en rigtig GitHub-issue fra start til slut

Lad os samle alle trinene i et konkret, gennemført eksempel. Forestil dig, at du har et lille Node.js-API med en fejlrapport: endpointet /api/users/:id returnerer 500 i stedet for 404, når et bruger-id ikke findes. Sådan ser hele processen ud fra din opsatte OpenHands-installation.

Vi har valgt netop denne type opgave som eksempel, fordi den er repræsentativ for den kategori af arbejde, hvor autonome agenter i dag leverer mest pålideligt: en afgrænset fejl, en tydelig forventet adfærd, og en kodebase, der allerede har en testsuite at læne sig op ad. En erfaren udvikler ville typisk bruge 15-30 minutter på denne opgave manuelt, inklusive at finde den relevante fil, forstå konteksten og skrive en ordentlig test. Med OpenHands kører det samme forløb autonomt på baggrund af én instruks, mens du bruger tiden på noget andet, og du bruger efterfølgende et par minutter på at gennemgå diffen, før du merger den.

1. Forbind repositoriet i Agent Canvas (trin 5) og opret en ny samtale.
2. Indsæt instruksen: “Undersøg hvorfor GET /api/users/:id returnerer 500 i stedet for 404 ved ukendt id. Ret fejlen, tilføj en test, der dækker det manglende bruger-scenarie, og kør testsuiten.”
3. Agenten læser routeren, finder den manglende null-tjek i controlleren, og retter koden.
4. Agenten tilføjer en ny testcase i den eksisterende testfil og kører hele testsuiten i sandkassen.
5. Agenten viser dig en diff og et testresultat, før den (afhængigt af din policy) enten committer direkte eller venter på din godkendelse.

Et realistisk sluttresultat i terminalen ser sådan ud:

$ npm test
  GET /api/users/:id
    ✓ returns user data for valid id (42ms)
    ✓ returns 404 for unknown id (18ms)

2 passing (60ms)

Agent summary: Fixed missing null-check in userController.js line 27.
Added regression test in tests/users.test.js.
Ready for review: git diff --stat shows 2 files changed, 9 insertions(+), 1 deletion(-)

Det er præcis den type afgrænsede, testbare opgave, hvor OpenHands i praksis leverer tættest på de dokumenterede 60-66 procent succesrate. Jo mere afgrænset opgaven er, og jo bedre testdækning din kodebase allerede har, desto højere er sandsynligheden for, at agenten løser den korrekt i første eller andet forsøg. Selv når resultatet ser rigtigt ud, bør du altid læse diffen igennem manuelt, før du merger den, på samme måde som du ville gennemgå en kollegas pull request. Agenten kan levere en teknisk korrekt løsning, der alligevel ikke passer til jeres kodekonventioner, eller som løser symptomet uden at ramme den dybere årsag til fejlen.

Almindelige faldgruber, du bør undgå

De fleste problemer med OpenHands opstår ikke, fordi platformen fejler, men fordi opsætningen eller opgaveformuleringen er upræcis. De fleste af disse fejl koster dig kun et par minutters frustration, hvis du ved, hvad du skal kigge efter, men de kan koste timer, hvis de opdages sent i et forløb. Her er de fem faldgruber, der går igen oftest.

• For vage instrukser. “Gør koden bedre” giver agenten ingen målbar succes at sigte efter. Skriv altid et konkret filnavn, en funktion og et forventet resultat, gerne med et eksempel på, hvordan output skal se ud, når opgaven er løst korrekt.
• Ingen grænse på token-forbrug. Uden en max_tokens_per_task-grænse kan en fastlåst agent i teorien blive ved med at forsøge sig frem og generere en uventet stor regning, især hvis den støder på en opgave, der er sværere end forventet, og selv fortsætter med at prøve nye tilgange.
• Manglende testdækning i kodebasen. Agenten er kun så god som de tests, den kan bruge til at verificere sit eget arbejde. Uden tests arbejder den reelt blindt og kan i værste fald erklære en opgave løst, selvom den bare har fjernet symptomet uden at rette den underliggende fejl.
• At stole blindt på selvrapporterede benchmarks. Som beskrevet tidligere er de høje 70+ procent-tal ikke uafhængigt verificerede. Planlæg din workflow, dit tidsforbrug og dine forventninger til teamet ud fra de konservative 60-66 procent i stedet.
• At give agenten adgang til produktionshemmeligheder. Glem ikke blocked_paths i policy-filen. En agent, der ved et uheld læser en .env-fil, kan utilsigtet inkludere hemmeligheder i en commit-besked eller et log-output, som efterfølgende bliver svært at fjerne fuldstændigt fra Git-historikken.

Sikkerhedsovervejelser: sandkassen fjerner ikke alt ansvar

Det er fristende at tænke på Docker-sandboxing som en fuldstændig sikkerhedsgaranti, men det er den ikke. Sandkassen beskytter primært dit værtssystem mod, at agenten ved et uheld sletter eller ændrer noget uden for det tiltænkte arbejdsområde. Den beskytter derimod ikke automatisk mod, at agenten committer følsomme data til et repository, kalder eksterne API’er på jeres vegne, eller installerer en pakke med en sårbarhed, fordi den så ud til at løse opgaven hurtigst.

Behandl derfor agent-genereret kode med samme skepsis, som du ville behandle kode fra en ny, ukendt bidragyder til projektet. Kør altid jeres eksisterende sikkerhedsscanninger og linting-værktøjer på agentens ændringer, før de merges, og lad aldrig en agent få adgang til produktionsdatabaser eller betalingssystemer direkte. Kombinerer du sandboxingen med policy-filens blocked_paths, et obligatorisk godkendelsestrin før commit, og jeres normale CI-pipeline, får I et lag af forsvar, der ligner den måde, I allerede burde behandle bidrag fra eksterne udviklere på.

Fejlfinding: 8 typiske problemer og løsninger

Herunder finder du de problemer, nye brugere oftest støder på, og hvordan du løser dem hurtigt. De fleste stammer fra de samme tre kilder: en konfigurationsfejl i .env-filen, en sandkasse der mangler et afhængighedslag, eller en policy-fil, der er for stram eller for løs i forhold til, hvad teamet reelt har brug for.

Problem	Sandsynlig årsag	Løsning
“docker compose up” fejler med portkonflikt	Port 3000 er allerede optaget af et andet program	Ret port-mappingen i docker-compose.yml, f.eks. til 3001:3000
Sandkassen starter, men agenten svarer aldrig	Ugyldig eller manglende API-nøgle i .env	Kør docker compose logs agent-server og tjek for 401-fejl
Testene fejler i sandkassen, men virker lokalt	Sandkassen mangler afhængigheder fra requirements.txt eller package.json	Tilføj en build-step i Dockerfilen, der installerer projektets afhængigheder
Agenten “hallucinerer” filstier, der ikke findes	Repositoriet blev ikke korrekt monteret i sandkassen	Bekræft workspace-stien i .env matcher det faktiske repo-rodpunkt
Meget langsom første opstart	Docker bygger sandkasse-imagen fra bunden	Normalt, tag 2-5 minutter, brug docker compose pull for at hente cachede lag først
Uventet høj API-regning	Multi-attempt scaling kørte på en for bred opgave	Sæt max_attempts_per_task ned til 1-2 for rutineopgaver
Canvas viser “sandbox disconnected”	Sandbox Server-containeren er crashet eller løbet tør for RAM	Kør docker stats og øg RAM-allokeringen i Docker Desktop
Agenten laver ændringer, du ikke godkendte	Policy-filen mangler restriktion på auto-commit	Sæt et eksplicit godkendelsestrin i policy.yaml, før commits tillades

Kan du ikke løse et problem ud fra tabellen ovenfor, er det næste skridt altid at læse loggen fra den relevante container i sin fulde længde i stedet for kun de sidste par linjer, fordi den egentlige fejlårsag ofte ligger tidligere i opstartsforløbet end selve fejlmeddelelsen, der stopper processen.

Avancerede tips til produktionsbrug

Når den grundlæggende opsætning kører stabilt, er der en håndfuld justeringer, der gør forskellen mellem et sjovt sideprojekt og et værktøj, teamet reelt kan stole på i den daglige drift.

Kør altid agenten mod en dedikeret branch, aldrig direkte mod main, uanset hvor godt policy-filen er sat op. Brug ACP-grænsefladen til at lade OpenHands orkestrere andre agenter, for eksempel ved at sende research-tunge opgaver til én model og selve kodeændringen til en anden, mere kodefokuseret model. Det giver dig mulighed for at optimere omkostning og kvalitet uafhængigt af hinanden i stedet for at bruge samme, dyre model til alt.

Overvej desuden at logge alle agent-sessioner til et centralt sted, hvis I kører flere teams på samme installation, så I kan spore, hvilken opgave der genererede hvilken kodeændring, i tilfælde af en fejl senere. Sæt en fast kadence for, hvornår teamet gennemgår afviste eller mislykkede agent-forsøg i fællesskab. Det er ofte her, I opdager mønstre, for eksempel at agenten konsekvent fejler på opgaver, der involverer et bestemt bibliotek, hvilket kan pege på, at netop det bibliotek mangler dokumentation, agenten kan læse fra.

Endelig bør du opdatere til nyeste version jævnligt. Med ugentlige udgivelser fra projektet rettes sikkerhedshuller og ydelsesproblemer hurtigere, end de fleste andre open source-projekter i denne kategori formår, men det betyder også, at en installation, der ikke opdateres i flere måneder, hurtigt kommer bagud i forhold til både sikkerhedsrettelser og nye funktioner som Canvas Apps og udvidet multi-agent-delegering.

Hvornår giver OpenHands mest værdi for dit team?

Efter at have gennemgået installation, konfiguration og et konkret eksempel er det værd at stoppe op og spørge, hvornår investeringen i tid faktisk betaler sig tilbage. Svaret afhænger mindre af, hvor avanceret jeres kodebase er, og mere af, hvor godt den allerede er testet og dokumenteret, fordi det er dét, agenten navigerer efter.

Teams med en moden testsuite, klare kodekonventioner og et jævnt tilsig af mindre, veldefinerede issues (bugfixes, mindre features, oprydning i teknisk gæld) vil typisk se den hurtigste gevinst, fordi det er præcis den type opgaver, hvor benchmark-tallene på 60-66 procent er indhentet. Omvendt vil teams med en ældre kodebase uden nævneværdig testdækning, eller med meget projektspecifik forretningslogik, der aldrig er dokumenteret nogen steder, opleve en lavere succesrate og bør starte i det små, for eksempel med afgrænsede vedligeholdelsesopgaver, før de udvider brugen til mere kritiske dele af systemet.

En praktisk tilgang er at lade OpenHands køre parallelt med jeres eksisterende arbejdsgang i fire til seks uger, hvor I bevidst måler, hvor mange agent-genererede pull requests der merges uden større rettelser, og hvor mange der forkastes eller kræver omfattende omskrivning. Det giver et konkret, internt tal at planlægge videre skalering ud fra, i stedet for at læne sig op ad de eksterne benchmark-tal alene, som trods alt er målt på andre kodebaser end jeres egen.

Ofte stillede spørgsmål

Er OpenHands gratis at bruge?
Selve platformen er gratis og open source under MIT-licens. Du betaler kun for API-kaldene til den sprogmodel, du vælger at forbinde, for eksempel Anthropic, OpenAI eller Google.

Kan jeg bruge OpenHands uden Docker?
Nej. Sandboxing via Docker er en kernedel af arkitekturen og sikrer, at agentens handlinger er isoleret fra dit værtssystem. Uden Docker kan du ikke køre Sandbox Server-komponenten.

Hvilken model giver de bedste resultater?
Ifølge de tilgængelige benchmarks leverer Anthropics Claude-modeller med udvidet tænkning de højeste dokumenterede scorer på SWE-bench Verified, men platformen er bevidst modeluafhængig, så du selv kan teste OpenAI- og Google-modeller mod din egen kodebase.

Er OpenHands sikkert nok til produktionskode?
Med korrekt konfigureret policy-fil, adskilte branches og et menneskeligt godkendelsestrin før merge kan det bruges i produktionsnære flows. Uden disse begrænsninger frarådes det at give agenten direkte adgang til kritiske systemer.

Hvor stor er forskellen på Devin og OpenHands i praksis?
Den vigtigste forskel er, at Devin er et lukket, betalt produkt uden mulighed for selvhosting, mens OpenHands er åbent og kan køres i eget miljø. Benchmark-sammenligninger mellem de to findes, men stammer typisk fra tredjepartssider og bør tolkes som vejledende, ikke som officielle, uafhængige tests. Vælger du OpenHands, får du desuden mulighed for at tilpasse policy-filer, modelvalg og infrastruktur langt mere detaljeret, end et lukket produkt normalt tillader.

Kan flere teammedlemmer dele samme OpenHands-installation?
Ja, særligt hvis I bruger Enterprise- eller VPC-opsætningen, som inkluderer rollebaseret adgangskontrol og audit-spor, så I kan se, hvem der har startet hvilke agent-sessioner.

Hvad gør jeg, hvis agenten bruger for mange tokens på én opgave?
Sæt en eksplicit grænse med max_tokens_per_task i policy-filen, og undgå multi-attempt scaling til simple, rutineprægede opgaver, hvor et enkelt forsøg er tilstrækkeligt.

Kan OpenHands erstatte en menneskelig udvikler helt?
Nej. Selv de mest optimistiske, selvrapporterede tal ligger under 80 procent succesrate på afgrænsede benchmark-opgaver, og reelle produktionskodebaser er ofte mere komplekse end benchmark-datasæt. Betragt agenten som en effektiv medarbejder til afgrænsede opgaver, der stadig kræver menneskelig gennemgang, ikke som en fuld erstatning for et udviklerteam.

Skal jeg vælge OpenHands Cloud eller den selvhostede version?
Vælg den selvhostede version, hvis I har krav om, at kildekode og data forbliver inden for eget netværk, eller hvis I allerede driver anden intern infrastruktur i Docker. Vælg Cloud-udgaven, hvis I vil i gang hurtigt uden selv at stå for drift og opdateringer, og jeres compliance-krav tillader, at en tredjepart hoster kontrolfladen.