Grok Build er blitt open source – men Grok-modellen er fortsatt lukket

Grok Build er blitt open source, så du kan endelig se hva kodeagenten faktisk gjør bak terminalvinduet. xAI publiserte kildekoden på GitHub under Apache 2.0-lisens 15. juli, kort tid etter at det ble kjent at verktøyet kunne laste opp hele arbeidsmapper til selskapets skylagring.

Det er et stort og nyttig steg. Utviklere kan lese kildekoden, bygge klienten selv og koble den til en annen modell enn Grok. Sikkerhetsfolk kan kontrollere påstander mot faktisk kode i stedet for å lete etter tekststrenger i en lukket binærfil. Etter en personvernhendelse er innsyn bedre enn enda et løfte på X.

Men ordene «open source» trenger en liten fotnote her. xAI har åpnet selve agenten og terminalgrensesnittet, ikke Grok-modellen eller modellvektene. Selskapet tar heller ikke imot eksterne pull requests. Dette er først og fremst åpen kildekode for innsyn, lokale bygg og egne varianter – ikke et vanlig fellesskapsprosjekt der alle kan bidra til hovedversjonen.

Hva er egentlig open source i Grok Build?

xAI har publisert Rust-koden til Grok Build-klienten, terminalgrensesnittet og agentens kjøremiljø under Apache License 2.0. Det offentlige xai-org/grok-build-repoet inneholder verktøy for filredigering, shell-kommandoer og søk, i tillegg til støtte for headless kjøring, Agent Client Protocol, plugins, skills, hooks og MCP-servere.

Det betyr at dette er langt mer enn en pen kommandolinje rundt et API-kall. Simon Willison talte 844 530 linjer Rust-kode uten kommentarer og blanke linjer, hvor omtrent 3 prosent så ut til å være kode som følger med fra andre prosjekter. Ved publisering lå historikken som én stor commit. Vi får dermed et omfattende øyeblikksbilde, men ikke historien om hvordan beslutningene ble tatt.

Repoet inneholder blant annet hovedprompten, en egen subagent-prompt, verktøyimplementasjoner og kode for sandkasse, sesjoner, terminalvisning og konfigurasjon. Det har også porter av enkelte verktøy fra OpenAI Codex og OpenCode, med lisensmerknader i repoet. At moderne kodeagenter deler ideer og bygger videre på åpen kode er ikke spesielt rart. Omfanget er likevel en påminnelse om at en terminalagent er blitt et helt programvaresystem, ikke bare en chatbot som kan skrive filer.

Kan Grok Build nå kjøres uten xAI?

Ja, selve agenten kan bygges fra kildekoden og brukes med et valgfritt modellendepunkt. Den offisielle dokumentasjonen for Grok Build viser at en egendefinert modell kan settes opp med modell-ID, API-adresse og nøkkel i ~/.grok/config.toml. Det åpner for andre skytjenester og for lokal inferens gjennom et kompatibelt API.

Det betyr ikke at Grok-modellen er blitt lokal. xAI har åpnet agentlaget – altså programmet som samler kontekst, spør modellen, tolker svaret og bruker verktøy på maskinen. Selve Grok-modellen kjører fortsatt hos xAI når du velger den vanlige tjenesten. Skal alt holdes lokalt, må du velge en annen modell som du faktisk kan kjøre på eget utstyr, og gi Grok Build adressen til den lokale modelltjeneren.

Dette skillet er viktig. En åpen agent gir kontroll over hvilke filer som leses, hvordan verktøykall godkjennes og hvor forespørslene sendes. Den gjør ikke en ekstern modell privat av seg selv. Bruker du et API i skyen, må nødvendig prompt og kode fortsatt sendes til leverandøren du har valgt. Bruker du en lokal modell, kan både kode og inferens bli på egen maskin, men da overtar du også ansvaret for modell, maskinvare, ytelse og sikker konfigurasjon.

For utviklere er dette likevel den mest interessante delen av åpningen. Jeg liker Grok-kodemodellene godt, men modellen og agentprogrammet er to forskjellige valg. Nå kan du bruke Grok Build som grensesnitt med en annen modell, eller bruke Grok 4.5 i en agentløkke du kontrollerer selv. Jeg har tidligere gått gjennom Grok 4.5, API-tilgang og OpenRouter. Åpningen gjør det lettere å velge modell og verktøylag hver for seg.

Hva viser kildekoden om opplastingen?

Koden viser at opplastingsmekanismen fortsatt finnes, men at funksjonen som sender sesjonstilstanden nå stopper med en hardkodet feilmelding. Willison fant GCS-koden i xai-grok-shell/src/upload/gcs.rs, mens upload_session_state() i upload/trace.rs returnerer feilen session_state_upload_unavailable. Det stemmer med selskapets påstand om at funksjonen er deaktivert.

Dette er relevant fordi den forrige hendelsen ikke bare handlet om at en skymodell måtte få noen kodefiler for å utføre en oppgave. Grok Build kunne pakke hele arbeidsområdet og sende pakken til en Google Cloud Storage-bøtte. En bruker som startet verktøyet i hjemmemappen, rapporterte at SSH-nøkler, passorddatabase, dokumenter, bilder og videoer ble tatt med. Jeg har allerede dekket hva Grok Build lastet opp og hvilke nøkler tidligere brukere bør rotere.

xAI sier at standard lagring ble slått av for alle Grok Build-brukere fra 12. juli, at beholdte kodedata skal slettes, og at opplastingsfunksjonen er deaktivert. Kildekoden gjør den siste delen lettere å undersøke. Den beviser derimot ikke i seg selv at alle kopier hos leverandøren er slettet. Lokal kode kan vise hva klienten gjør nå. Den kan ikke gi oss et vindu inn i sikkerhetskopier, logger og lagringssystemer på serversiden.

Det er derfor åpningen er et godt svar, men ikke hele svaret. Jeg savner fortsatt en presis hendelsesrapport med berørte versjoner, tidsrom, datatyper, antall brukere og verifisert sletting. Når et verktøy har hatt tilgang til private kodearkiver og sensitive filer, er «funksjonen er av nå» bare første punkt på oppryddingslisten.

Er dette et ekte open source-prosjekt?

Lisensen er ekte og romslig. Apache 2.0 lar deg bruke, endre og distribuere koden, også kommersielt, så lenge lisensvilkårene følges. Du kan bygge din egen variant, kontrollere endringer mellom publiserte versjoner og beholde en intern fork dersom xAI går i en retning du ikke liker.

Men xAIs egne bidragsregler sier uttrykkelig at eksterne pull requests og uoppfordrede patcher ikke tas imot. xAI utvikler programvaren internt og publiserer kildekoden for innsyn og lokale bygg. GitHub-repoet er dermed mer et åpent speil enn stedet der produktet utvikles i fellesskap.

Det er lov å mene at «source available» beskriver arbeidsformen bedre, men lisensen gjør likevel koden til open source i juridisk og praktisk forstand. Forskjellen ligger i styringen. Fellesskapet får rett til å lese, bygge, endre og forke. Fellesskapet får ikke en direkte vei inn i xAIs offisielle versjon. Finner noen en feil og lager en god rettelse, må xAI selv velge å kopiere ideen tilbake.

For tillit har også et speil verdi. Sikkerhetsforskere kan søke etter nettverkskall, filinnsamling og standardvalg. Bedrifter kan sammenligne en installert versjon med den publiserte koden. Utviklere kan se hvordan systemprompt, verktøytillatelser og sandkasse faktisk er bygget. Det er vesentlig bedre enn å måtte gjette ut fra oppførselen til en lukket binærfil.

Hva betyr åpningen for vanlige Grok Build-brukere?

For de fleste endrer ikke GitHub-repoet arbeidsdagen over natten. Den ferdige Grok Build-klienten installeres fortsatt enklest som før, og standardoppsettet bruker fortsatt xAIs tjeneste. Den store forskjellen er at påstander om klienten nå kan etterprøves, og at avanserte brukere ikke er låst til den ferdige binærfilen eller én modellleverandør.

Hvis du bare vil bruke verktøyet, bør du fortsatt tenke som før: start det i en avgrenset prosjektmappe, ikke i hjemmemappen. Hold nøkler utenfor repoet, bruk kortlivede tokens der det er mulig, og velg en passende sandkasse. Offisiell dokumentasjon beskriver fem profiler fra off til strict, og off er standarden. Åpen kildekode beskytter deg ikke hvis du gir agenten ubegrenset tilgang og godkjenner alt den ber om.

Det samme gjelder utvidelser. Jeg har tidligere sett på plugin-markedsplassen i Grok Build. Plugins, hooks, skills og MCP-servere gjør agenten langt mer nyttig, men øker også antall steder kode kan kjøre og data kan flytte seg. Nå kan de som trenger det, kontrollere integrasjonen helt ned i kildekoden. Det fritar ingen fra å lese hvilke tillatelser en utvidelse får.

Bedrifter får en mer konkret gevinst. De kan forke klienten, fjerne funksjoner, låse konfigurasjon og peke den mot en godkjent modellendepunkt. Grok Build har støtte for policyfiler, sandkasse og styrte innstillinger, men en intern fork gir enda mer kontroll. Ulempen er selvfølgelig at noen må vedlikeholde den. En fork er frihet med en fast følgesvenn: oppdateringsarbeid.

Åpen kode gjenoppretter ikke tillit automatisk

xAI reagerte raskt etter kritikken. Opplastingen ble deaktivert, standard lagring ble slått av, tidligere data ble lovet slettet, og kildekoden kom ut under en lisens som faktisk tillater egne varianter. Det er langt bedre enn å møte en alvorlig personvernhendelse med taushet og en ny formulering i vilkårene.

Samtidig kom innsynet først etter at brukere og sikkerhetsfolk oppdaget oppførselen utenfra. Den rekkefølgen betyr noe. Åpen kode gjør neste kontroll enklere, men forklarer ikke hvorfor hele mapper kunne bli lastet opp som standard i utgangspunktet. Det er nettopp designbeslutningen mange vil forstå.

Jeg synes derfor dette er en god nyhet med en ganske stor stjerne i margen. Grok Build er nå en av de mest innsynsvennlige store kodeagentene, og muligheten til å bruke egne modeller er reell. Men kildekode er ikke tryllestøv. Tillit bygges når den åpne klienten, serverpraksisen og det selskapet sier, fortsetter å stemme overens over tid.

Det fine er at du ikke lenger trenger å stole blindt på alle delene samtidig. Nå kan utviklere kontrollere agentprogrammet, velge modellleverandør og beholde en egen fork. Etter denne ukens hendelse er akkurat den muligheten mer verdifull enn den ville vært for noen dager siden.

Ofte stilte spørsmål