Innhold Vis
Claw Compactor er et åpen kildekode-verktøy som komprimerer LLM-tokens med opptil 54 prosent – uten en eneste ekstern ML-avhengighet. Det er ikke en liten optimalisering. Det er halvparten av kontekstvinduet tilbake i lomma, helt gratis, med MIT-lisens.
Prosjektet dukket opp på GitHub nylig og fikk raskt oppmerksomhet på Hacker News. Og med rette. Token-kostnader er en av de aller mest reelle flaskehalsene når man bygger AI-agenter og automatiserte workflows. Jeg har selv kjent på det – sender du store JSON-payloads, kodeblokker, eller bygglogger gjennom Claude eller GPT-5, tikker kostnadene fort opp til nivåer som gjør prosjektet ulønnsomt. Claw Compactor angriper akkurat det problemet.
Her er hva det faktisk gjør, og hvorfor det er interessant for alle som jobber med LLM-er i produksjon.
Hva er Claw Compactor?
Claw Compactor er en tokenkomprimeringsmotor bygget rundt en 14-trinns fusjonspipeline. Ingen nevrale nettverk, ingen modellvekter å laste ned, ingen avhengigheter utover standardbiblioteker. Det kjøres som mellomvare mellom applikasjonen din og LLM-API-et.
Prinsippet er enkelt: før du sender kontekst til modellen, kjøres innholdet gjennom en serie spesialiserte kompressorer. Hvert trinn sjekker innholdstype og velger riktig komprimeringsteknikk. Kode behandles annerledes enn JSON, som igjen behandles annerledes enn naturlig tekst. Det er det som gjør det effektivt.
Resultatet sendes til LLM-et. Og det viktige: komprimeringen er reversibel. Hvis modellen trenger det originale innholdet, kan den hente det via et innebygd «Rewind»-verktøy. Ingenting går tapt, det tar bare færre tokens å representere det.
Hva er ytelsestallene?
Her er tallene fra prosjektets egne benchmarks, og de er ganske overbevisende:
- JSON (100 elementer): 81,9% komprimering
- Python-kode: 25,0% komprimering
- Bygglogger: 24,1% komprimering
- Søkeresultater: 40,7% komprimering
- Vektet gjennomsnitt på blandet innhold: 53,9%
JSON-komprimering på nesten 82 prosent er sinnssykt bra. Jobber du med agenter som henter store JSON-strukturer – tenk API-svar, databaseresultater, konfigurasjonsfiler – kan du i praksis sende fire ganger så mye data for samme pris.
De sammenligner seg også mot LLMLingua-2 (Microsofts tokenkomprimeringsbibliotek) og hevder ROUGE-L-poengsum på 0,653 mot konkurrentens 0,346 ved samme komprimeringsrate. ROUGE-L måler hvor mye av meningsinnholdet som bevares. Høyere er bedre – og 0,653 vs 0,346 er en betydelig forskjell.

Hvordan fungerer de 14 trinnene?
Pipelinen bruker en «gate-before-compress»-arkitektur. Hvert trinn inspiserer innholdet og avgjør om det har noe å bidra med, før det eventuelt komprimerer. Det unngår at feil kompressor kjøres på feil innholdstype.
Noen av de sentrale komponentene:
- Cortex: Auto-detekterer innholdstype og programmeringsspråk (støtter 16 språk)
- Neurosyntax: AST-bevisst kodekomprimering via tree-sitter – forstår kodets struktur, ikke bare tekst
- Ionizer: JSON-arraysampling med skjemaoppdagelse
- Abbrev: Forkortelse av naturlig språk (kun for tekstinnhold)
Hele datastrømmen er immutable – hvert trinn produserer nye FusionResult-objekter uten å mutere originaldataene. Det gjør det lettere å debugge, og det er pent designet.

Hvem er dette nyttig for?
Er du hobbyist som chatter med Claude en gang iblant? Sannsynligvis ikke det mest kritiske verktøyet for deg akkurat nå.
Men jobber du med noe av dette, bør du se nærmere:
- AI-agenter som prosesserer store mengder data automatisk
- n8n-workflows eller lignende automatisering der API-kall til LLM-er er dyrt
- Kodegenerasjon og code review-verktøy der kodeblokker sendes som kontekst
- RAG-systemer der søkeresultater pakkes inn i prompts
- Applikasjoner som sender JSON-API-svar videre til en LLM for analyse
Kontekstvindu-problematikken er noe jeg har skrevet om tidligere – Anthropic reduserte for eksempel token-bruken med 37% ved å bytte fra JSON-basert tool calling til Python-scripting. Claw Compactor er et annet angrep på samme problem: jo mindre du sender inn, jo billigere og raskere blir alt.
Og kontekstvindu-størrelse er én ting – Claude har nå 1 million tokens tilgjengelig – men hva det faktisk koster å fylle det opp er en annen sak.
Teknisk implementering – slik brukes det
Prosjektet er tilgjengelig på GitHub under open-compress-organisasjonen med MIT-lisens. Null ekstern ML-avhengighet betyr at det ikke krever PyTorch, transformers eller noen modellnedlasting. Det kjører rett i Python-prosessen din.
Bruken er tenkt som mellomvare: input går gjennom Claw Compactor, komprimert versjon sendes til API-et, og om modellen trenger originalt innhold på noe punkt bruker den Rewind-verktøyet for å hente det fra cache. Hele 1 676 tester er inkludert i pakken, noe som tyder på at dette er ment for produksjonsbruk og ikke en proof-of-concept.
En bruker på Hacker News spurte om det kan kjøres som HTTP-proxy – altså et lag mellom applikasjonen og LLM-API-et uten kodeendringer. Det ville gjort det enda mer tilgjengelig. Ingen svar ennå, men det er åpenbart en fornuftig use case.
Er det for godt til å være sant?
Skeptisismen min blafrer litt her. 54% komprimering med null kvalitetstap høres nesten for fint ut. Og benchmarks i README-filer er alltid best case.
Men konseptet er solid. JSON er ekstremt verbose av natur – det er masse boilerplate, gjentatte nøkkelnavn, og mønstre som en smart kompressor kan kollapse kraftig. Bygglogger og søkeresultater inneholder masse repetisjon. At man kan fjerne halvparten av tokens på blandet innhold uten å miste mening er faktisk plausibelt.
Det at de sammenligner positivt mot LLMLingua-2 fra Microsoft er interessant. LLMLingua bruker en liten språkmodell til å finne uviktige tokens – det krever altså ML. Claw Compactor gjør det med rene heuristikker. Ingen ML = ingen latency, ingen GPU-krav, ingen modellvekter. Det er et tydelig designvalg og det gjør integrasjon mye enklere.
Prosjektet er nytt. Det vil dukke opp edge cases. Men 1 676 tester og MIT-lisens er et godt utgangspunkt for å teste det i et kontrollert miljø.
Hva tenker du – er token-kostnader et problem du har støtt på? Og er komprimering en bedre strategi enn bare å vente på at prisene faller? Send meg gjerne en kommentar.
2 kommentarer