Synthetic Sciences har lanceret OpenScience, et open-source AI‑workbench til forskning i maskinlæring, biologi, fysik og kemi. Licensen er Apache 2.0, og softwaren kan køres på egen infrastruktur uden konto eller paywall. Pointen er model-agnosticitet og lokal drift, ikke låsning til én leverandør. Ifølge MarkTechPost præsenteres det som et uafhængigt alternativ til Anthropics nye Claude Science, som udkom i slutningen af juni 2026 [kilde: MarkTechPost].
Det korte overblik først. OpenScience samler hele forskningssløjfen i en browser: litteratur, hypoteser, kode, forsøg, analyse og write‑up. Du kan skifte model per anmodning, gemme sessioner og artefakter på disk og koble agenter til fagspecifikke databaser. Ambitiøst – spørgsmålet er, om det holder i driften og i governance.
Markedet har ventet på et åbent modstykke
Det sidste år er værktøjer til videnskabelig AI accelereret, ofte som lukkede, hostede produkter med bekvemmelighed og skalering i salgsargumentet. Claude Science er det aktuelle pejlemærke. Netop derfor lander timingen for et Apache 2.0‑projekt bag egen firewall stærkt. Ejerkontrol og udskiftelighed i modellen er ikke kun filosofi, men et konkret compliance‑spørgsmål i regulerede domæner.
Der er også en kulturel dimension. Forskning trives dårligt i sorte bokse. Når metadata, kode og artefakter kan ligge lokalt, bliver sporbarhed og reproducerbarhed mindre ideal og mere praksis. Det er løftet – og det skal prøves i virkeligheden.
Hvad OpenScience faktisk gør
OpenScience kører en lokal server, der hoster brugerfladen, agent‑runtime og et tool‑lag. Ifølge MarkTechPost tæller værktøjslaget shell, editor, sprogservere (LSP), MCP‑servere og en række videnskabelige konnektorer. Agenten planlægger gennem et “research harness” og kalder de relevante værktøjer, mens arbejdet strømmes tilbage til browseren. Det hele fungerer i sessions, der gemmes på disk sammen med artefakter og provenance.
Model‑agnosticiteten er central. Brugeren vælger model i UI’et per forespørgsel. Artiklen nævner kompatibilitet med både frontier‑modeller og open‑weights – fra Claude, GPT og Gemini til GLM, Kimi, DeepSeek og lokale fine‑tunes. Det muliggør hurtig A/B‑test og at matche opgave og omkostning mere præcist – men kræver også dokumentation af modelvalg og evaluering.
Arkitekturen i drift
I arkitekturen bor alt lokalt under kørslen, mens modelkald går direkte til den valgte udbyder ved bring‑your‑own‑key. MarkTechPost viser et konkret eksempel, hvor nøglen sættes i miljøvariabel og klienten startes: “export ANTHROPIC_API_KEY=sk-ant-… openscience” [kilde: MarkTechPost]. Pointen er, at nøgler og data ikke skal igennem en fremmed mellemmand. Godt for privatliv – krævende for nøglestyring.
Tool‑laget er ikke pynt. Kombinationen af terminal, editor, LSP og MCP‑servere skal gøre det realistisk at gennemføre hele sløjfen uden at hoppe ud i en separat IDE. Der loves også visualiseringer inline – molekyler, strukturer, genomer, plots – hvilket mindsker friktionen i arbejdet. Sessions og artefakter kan deles som links, men den præcise delingsmekanik – lokalt, via delt lager eller andet – er ikke fuldt belyst i kilderne.
Pakkeindhold og workflow
OpenScience leveres med 250+ redigerbare “skills”. MarkTechPost nævner områder som træning med DeepSpeed, PEFT og TRL, evaluering, datasæt‑arbejde og cheminformatik. Hertil kommer molekylær og klinisk biologi, artikler, LaTeX, figurer og cloud compute. Konnektorerne dækker bl.a. UniProt, PDB, Ensembl, ChEMBL, PubChem, arXiv, OpenAlex og Semantic Scholar – plus cirka 30 yderligere databaser.
Specialist‑agenter til biologi, fysik og ML er også en del af pakken. En standard forskningsagent kører som udgangspunkt, suppleret af underagenter til kritik og litteraturreview. Der er også en læse‑kun plan‑tilstand. I hverdagen kan det fjerne manuelt klikarbejde – søgning, udvælgelse, førsteudkast til kode – så forskeren kan koncentrere sig om de faglige valg.
Installation og første opstart
Installationen er, ifølge kilden, enkel. MarkTechPost gengiver kommandoen “npm install -g @synsci/openscience” efterfulgt af “openscience” for at åbne arbejdsrummet i browseren. Man kan også springe global installation over og køre “npx synsci” [kilde: MarkTechPost]. Første kørsel tilbyder tre veje: Atlas‑managed modeller, egne provider‑nøgler eller gratis demo‑modeller.
Hurtig onboarding er fint. I en organisation følger straks et sikkerhedsreview: node‑afhængigheder skal scannes, netværksregler afstemmes, og nøgler håndteres korrekt. Valget mellem Atlas’ forvaltede lag eller egne nøgler er også et governance‑spørgsmål. Atlas tilføjer efter sigende en vedholdende forskningsgraf og cloud compute, men kernen i OpenScience kan køre uden.
Hvorfor organisationer kan få reel værdi
Dataprivatliv og sporbarhed er det mest håndgribelige. Når sessioner, artefakter og provenance ligger lokalt, kan man bygge revisionsspor og reproducerbare eksperimenter ind i sin almindelige dataplatform. Ingen skygge‑eksport. Fleksibiliteten i modelvalg er næste gevinst. At kunne skifte model per opgave eller per delopgave reducerer både omkostning og risiko for leverandørlåsning.
Licensafhængigheder falder, når kernen er Apache 2.0 og BYOK. Til gengæld stiger kravet til intern driftskompetence: nøgler, rate‑limits hos eksterne databaser, versionsstyring af “skills”, CI/CD for agenter, sikkerhedspatching. Klassisk tradeoff: frihed mod ansvar.
Begrænsninger og risici
Der mangler dokumenterede infrastrukturkrav i de tilgængelige kilder. CPU/GPU‑behov, hukommelse, netværksprofil – uvist. Det samme gælder skaleringsscenarier for parallelle brugere. Uden officiel dokumentation eller praktisk test er det ikke muligt at vurdere throughput eller omkostning per forsøg med sikkerhed.
Sikkerhedsmodellen er heller ikke fuldt beskrevet. Hvordan håndteres secrets, caching af tokens og eventuelle remote model‑kald i praksis under lokalkørsel? Her bør man forlange en sikkerheds‑readme eller kodegennemgang. Og så er der vedligehold: Hvem er core maintainere, hvad er patch‑rytmen, og findes der en offentlig roadmap? Det kræver flere kilder end én artikel.
En kort implementeringscheckliste
- Infrastruktur og netværk: vælg lokal datacenter, VPC i cloud eller hybrid. Afgræns udgående net for model‑API’er og databaser.
- Nøglehåndtering: brug secrets‑management, rotation og mindst mulige rettigheder. Undgå plain env‑filer i delte miljøer.
- Audit og logging: definér metadata for sessions og artefakter, centralisér logs, og versionér “skills” og agenter.
- Modellivscyklus: etabler benchmarks, A/B‑tests og godkendelsesflow for modelvalg per use case.
- Datasæt og konnektorer: afklar licenser, API‑rater og adgangsrettigheder for UniProt, PDB, ChEMBL, arXiv m.fl.
- Backup og deling: aftal hvor artefakter lagres, hvordan links deles, og hvilken retention der gælder.
- Sårbarhedsstyring: automatisér dependency‑scans og patch‑processer for den lokale server.
Sammenligning med lukkede løsninger
Hosted værktøjer leverer typisk SLA’er, klik‑klar skalering og supportkanaler. Det får man ikke automatisk i et open‑source‑projekt. Til gengæld får man fuld dataposition, frit modelvalg og mulighed for tæt integration i egne pipelines. For mange forskningsmiljøer vil de tre fordele trumfe de savnede SLA’er – hvis der findes en intern driftsevne.
Feature‑mæssigt dækker OpenScience og Claude Science meget af den samme bane, hvis man læser MarkTechPosts beskrivelse. Forskellen ligger i ejerskab og portabilitet. Skulle en leverandør hæve priser eller ændre vilkår, kan et lokalt workbench i teorien flyttes og tilpasses. I praksis afhænger det af kodekvalitet, community og tempo på vedligehold.
Hvad det kan bruges til her og nu
Cheminformatik er oplagt, fordi konnektorer og visualiseringer kan minimere skift mellem værktøjer. Protein‑ og genomforskning kan drage nytte af UniProt og PDB kombineret med specialistagenter til litteratur og hypoteser. På ML‑siden er reproducerbare eksperimenter og versionsstyret artefaktlager lavthængende frugter – forudsat at governance er på plads fra dag ét. To startopgaver går igen: automatiseret litteraturreview med kildeannotering samt kode‑generering til små eksperimenter, der valideres i CI.
En note i margen: Når lokale modeller blandes med frontier‑API’er, vil performance svinge. Et lille, skarpt benchmarksæt til egne opgaver er derfor guld værd – ikke kun for hastighed, men for konsistens i output, især hvor dokumentation og sporbarhed er afgørende.
Kildegennemgang og validering
Følgende påstande er eksplicit understøttet af MarkTechPosts gennemgang: at Synthetic Sciences har frigivet OpenScience som open‑source workbench; at licensen er Apache 2.0; at værktøjet er model‑agnostisk og nævner både frontier‑ og open‑weight modeller; at det kan køres på egen infrastruktur med bring‑your‑own‑key uden gate; at det ikke er affilieret med eller godkendt af Anthropic og positioneres som et åbent alternativ til Claude Science.
Desuden er følgende bekræftet i samme kilde: fuld forskningssløjfe i et browser‑workspace med lokal agent‑runtime; 250+ redigerbare skills; konnektorer til UniProt, PDB, ChEMBL, arXiv og ~30 flere; en lokal server der hoster UI, agent‑runtime og tool‑lag inklusive shell, editor, LSP, MCP og konnektorer. Installationsveje via “npm install -g @synsci/openscience” og “npx synsci”, samt første‑run valgene mellem Atlas, egne nøgler eller demo‑modeller, er også specificeret i MarkTechPost.
Ikke fuldt verificeret ud fra de foreliggende kilder: krav til hardware, anbefalet infrastruktur, præcise delingsmekanismer for sessions/artefakter via links, sikkerhedsdesignet for hemmelige nøgler og caching, samt vedligeholdelses‑ og patch‑processer. Her bør man søge officiel dokumentation eller udføre egne tests.
Skeptikerens blik
En kritiker vil pege på vedligeholdelsesrisikoen i et nyt open‑source‑projekt uden offentlig roadmap. Fragmentering er også en risiko, hvis teams begynder at redigere “skills” uden fælles versionering og review. Dertil usikkerhed om performance på tværs af modeller og omkostninger ved at flytte compute hjem. Og ja, governance: Uden et konsekvent regelsæt for modelvalg, datakilder og logging bliver gevinsterne hurtigt spist af uorden.
Der er også spørgsmålet om support. Uden en stærk community og aktive maintainere kan fejl hænge for længe. Omvendt kan en åben kodebase inspiceres og patches hurtigere internt, hvis kompetencerne er der. Valget er ikke binært, men kræver en bevidst strategi – og en ansvarlig ejer i organisationen.
En kort vurdering
OpenScience ligner et reelt bud på at tage forsknings‑AI hjem, både teknisk og styringsmæssigt. Kombinationen af Apache 2.0, lokal runtime, model‑agnosticitet og et bredt katalog af konnektorer taler klart. Der er huller i den offentlige dokumentation, og en del skal verificeres i praksis. Retningen er dog tydelig: mindre låsning, mere kontrol.
Det mest lovende er tempoet i eksperimenter, når man kan skifte model per opgave og gemme hele konteksten lokalt. Det mest risikable er governance og vedligehold. Man mærker først forskellen, når det sættes i drift.
Kommandoer og kilder
Installationskommandoer ifølge MarkTechPost: “npm install -g @synsci/openscience” og derefter “openscience”, alternativt “npx synsci”. Eksempel på BYOK‑kørsel: “export ANTHROPIC_API_KEY=sk-ant-… openscience”. Primær kilde: MarkTechPosts artikel “Synthetic Sciences Releases OpenScience: An Open-Source, Model-Agnostic AI Workbench for Machine Learning, Biology, Physics, and Chemistry Research”. Supplerende kontekst om AI‑agenter og kollektive processer kan findes hos VentureBeat, men ikke som dokumentation for OpenScience specifikt.
