FrogNano-4B-2609: Microsoft släppte en 4B-kodagent till Hugging Face och tillkännagav det aldrig

Repositoriet lades upp den 17 september 2026 med den inledande commiten, och själva checkpointen landade fyra minuter senare. Sedan ingenting. Ingen tweet från Microsoft AI, inget inlägg på Microsoft Research-bloggen, ingen lanseringssida. Sju veckor senare microsoft/FrogNano-4B-2609 — en kodagent av fyramiljardklass byggd på Qwen3.5-4B — har fortfarande inget tillkännagivande bakom sig, och den tystnaden är det enskilt viktigaste faktumet om den här modellens publicering. Det den däremot har är ett modellkort som påstår en artikel och ett testramverk, ett GitHub-repositorium som visar sig vara testramverket och inte artikeln, samt en createdAt från den 17 september som ligger under ett kort där det står "Releasedatum 22-SEP-2026". Båda datumen är improviserade; inget av dem är fel; de motsäger varandra.

Vad publiceras egentligen?

Allt nedan går att kontrollera på hubben just nu, och varje siffra i den här artikeln kommer från Microsofts eget kort eller från byte-antalen i själva repositoryt. Ingenting har reproducerats av en tredje part – det finns ingen Artificial Analysis-post, inget arena-betyg och ingen oberoende utvärdering av FrogNano någonstans.

• Vikter — ett publikt arkiv under Microsoft-organisationen, utan grind, MIT-märkt på hubben, 15 filer, ingen nedladdningsgrind och inget avtal att skriva under.

• Vikter på disk — 9,32 GB fördelade på två safetensors-shards, 59,6 miljarder byte repository-data inklusive den optimerarfria filuppsättningen, 738 tensorer i indexet.

• Arkitektur — Qwen3_5ForConditionalGeneration, den densa hybridstacken med 32 lager som ärvts från Qwen3.5-4B, med ett visionstorn med 24 lager som kortet säger ärvdes och aldrig eftertränades.

• Kortets eget parameterfält – "500M-5B". Det är ett band, inte ett nummer, och nedladdningen är det mer exakta dokumentet.

• Licens — kortets inledande metadata säger MIT. Kortets egen brödtext säger Apache License 2.0, och GitHub-harnesset levererar verkligen en LICENSE-fil med MIT. Dessa två påståenden gäller olika artefakter i samma utgåva.

• Tillkännagivande – inget. Inte på Microsoft Research-bloggen, inte på teamets egen forskningswebbplats, inte i Hugging Faces organisationsflöde som något annat än en repo-listning.

Den där sista raden är den som bör sätta en läsares hållning för resten av den här texten. En tyst uppladdad checkpoint är inte en underlägsen artefakt jämfört med en annonserad — dess kort är ofta längre, eftersom ingen kortar ner det för ett pressmeddelande. Men den har inte gått igenom det enda filter som en annonserad release får gratis: att andra människor tittar på den.

Poängen, och vem som producerade varenda en av dem.

Microsoft rapporterar att FrogNano når 61,5 % på SWE-bench Verified, 37,6 % på SWE-bench Pro, 31,1 % på Terminal-Bench 2.0 och 47,3 % på PatchEval-Verified, alla som Avg@3-lösningsfrekvenser mätta genom Leaf-harnessen. Samma kort anger utgångspunkten: Qwen3.5-4B fick 39,4 % på SWE-bench Verified under identisk harness och budget. Fem iterationer av förstärkningsinlärning tog den genom 49,1 %, 53,1 %, 56,7 %, 59,1 % och 61,5 % – 22,1 punkter över basmodellen, vilket Microsofts egen formulering avrundar till cirka 56 % relativ förbättring.

Två saker med den stegen är värda att stanna upp vid, eftersom de är platser där en sammanfattning kan gå fel snarare än platser där leverantören gjorde det.

Den första är Iter 5-avvikelsen. Kortets rubriktabell anger 61,5 % för den sista iterationen; artikelns egen effektivitetsbilaga rapporterar samma utveckling över fem kontrollpunkter som 48,2 %, 53,4 %, 58,3 %, 58,6 % och 61,6 %. Endast det sista talet ligger nära, och endast det sista talet är det som någon citerar. Behandla den slutliga siffran som det stabila resultatet och de mellanliggande stegen som mätningar av olika saker, för under en annan aggregering är de uppenbarligen det.

Det andra är att FrogNano inte är genomgående bättre än modellen den utgick från på alla axlar. Dess publicerade frekvens för parallella verktygsanrop är 1,71 %. Kortet är uppriktigt om att senare iterationer förlorade förmågan att avfyra flera verktygsanrop i en enda tur, och att teamets konsolideringsarbete delvis syftar till att återställa den. En modell som löser fler problem samtidigt som den utfärdar nästan inga samtidiga anrop är en verklig ingenjörsmässig avvägning, inte en fotnot.

Riggen är produkten, och repositoriet är riggen.

FrogNano kör inte av sig själv. Det skickar strukturerade anrop till fem verktyg – Read, Write, Edit, Glob och Bash – och något måste köra dem i en isolerad miljö och lämna tillbaka utdata. Det är Leaf, och här gör spåret något lite ovanligt.

Modellkortets rad för "ytterligare relaterade resurser" länkar till en teknisk rapport på aka.ms/frognano-tech-report och ett utvärderingsramverk på github.com/microsoft/FrogNano. aka.ms-länken pekar inte på en PDF; den omdirigerar direkt till arXivs abstraktsida, vilket är där den faktiska rapporten finns. GitHub-repositoriet innehåller däremot ingen träningskod, inget RL-recept och inga checkpoints. Dess egen README beskriver ett utvärderingsramverk som kör kodningsagenter i Kubernetes-sandboxar mot en OpenAI-kompatibel slutpunkt och hänvisar tillbaka till arXiv-artikeln för träningshistorien. Så kortets två resursslänkar är en pekare till artikeln och en pekare till artikelns svar, och namnet är gemensamt.

Detta är viktigt för alla som planerar att använda modellen, av ett praktiskt skäl. Det dokumenterade serveringsreceptet är SGLang med --reasoning-parser qwen3 och --tool-call-parser qwen3_coder, och testramverket vill ha en slutpunkt som redan talar verktygsanrop och resonemang. Får du parsningskonfigurationen lite fel producerar modellen text där testramverket förväntar sig JSON, vilket utifrån sett ser ut precis som en dålig modell snarare än en dålig konfiguration. Kortet säger uttryckligen att varje matchande poäng kräver en matchande checkpoint, tokenizer, serveringskonfiguration, uppgiftsbilder och utvärderingsprotokoll — det är leverantören som säger att testramverket är halva resultatet.

Det är också värt att säga rakt ut för alla som dimensionerar hårdvara: en checkpoint på 9,32 GB vid kortets utvärderade kontext är inte ett inferensproblem på 9,32 GB. Utvärderingarna kördes vid ungefär 131K kombinerade tokens med en budget på 150 steg. Minnet skalas med kontexten, inte med vikterna, och kortet säger att den lägsta GPU-konfigurationen fortfarande "måste valideras före release" – en fras som förekommer på en modell som redan går att ladda ner.

Vad träningen faktiskt gjorde, i ett stycke

Artikelns bidrag är inte modellen, det är loopen. TaskPilot genererar kandidatuppgifter inom programvaruteknik från verkliga repository-ögonblicksbilder, kör rollouts från den aktuella checkpointen mot dem, behåller dem som ligger nära gränsen för vad policyn ibland kan lösa, och kasserar kandidater som är permanent triviala eller permanent omöjliga. Den accepterade uppsättningen tränar nästa checkpoint. Den därpå följande checkpointen kalibrerar sedan följande omgång av uppgiftsgenerering, så att uppgiftsfördelningen rör sig i takt med att policyn rör sig. Ungefär 1 500 validerade miljöer totalt. Ingen destillation: kortet säger rakt ut att agentspecifik efterträning inte använde några lösningsbanor, åtgärder, resonemangsspår eller patch-mål från starkare modeller. Starkare modeller skriver uppgifter; de demonstrerar inte svar.

Microsoft körde den loopen i fem iterationer och rapporterar en förbättring på 8,7 punkter innan någon konsolidering, med en straffavgift för logglängd som lades till mitt i körningen eftersom resonemangsspåren växte snabbare än de förbättrades.

Modellkortet är ovanligt rakt på sak om var hela metoden är bräcklig. Träningsdata är Python-tunga och huvudsakligen engelska; den angivna uppsättningen naturliga språk som stöds är engelska och inget annat, medan det uttryckligen inte görs anspråk på basmodellens bredare flerspråkiga täckning. Prestandan är känslig för testriggen och för kvaliteten på testerna. Genererade patchar ”kan vara felaktiga eller osäkra trots att de klarar tillgängliga tester”. Modellkortet för 4B avslutar det stycket med den mening som varje läsare bör bära med sig: den får inte användas utan kvalificerad mänsklig granskning och oberoende regressions- och säkerhetstestning. Det är ett leverantörsuttalande om en leverantörsartefakt, och det är en mer användbar mening än någon av raderna på resultattavlan ovanför den.

Vad detta innebär för en köpare, och var en router passar in

FrogNano är inte en modell som du anropar. Det finns inget förstaparts-API, ingen hostad slutpunkt och ingen serverlös image. Det är en checkpoint, och att använda den innebär antingen att sätta upp din egen SGLang-distribution bakom en Kubernetes-hostad sandlåda, eller att utvärdera den som en komponent i en agentstack som du redan kör. Det är hela vägen till införande i dag, och inget tillkännagivande skulle ha ändrat dess form.

Vad ett routinglager ärligt kan göra här är en snävare sak än det först låter. Om planen är att jämföra en självhostad FrogNano mot en hostad kodmodell i din egen harness, är den hostade halvan den halva som tjänar på att ligga bakom en enda nyckel i stället för ett andra avtal: OrcaRouter har över 200 modeller bakom en enda OpenAI-kompatibel slutpunkt med 0 % påslag, vilket innebär att leverantörernas listpriser förs vidare oförändrade och att en leverantörsprisändring är live hos oss samma dag. Det spelar roll för en bake-off där utfallet avgörs av kostnad per löst ärende snarare än av en enda benchmarksiffra. Vi hostar inte FrogNano och det finns inget datum för det; vikterna och serveringsarbetet är ditt.

De tre sakerna som skulle avgöra det

Först, en oberoende reproduktion. Varje siffra i den här artikeln – 61,5, 37,6, 31,1, 47,3 – producerades av labbet som tränade modellen, i en testrigg som samma labb underhåller, mot en basmodellsiffra som samma labb mätte. Det är en komplett och internt konsistent bild, och det är också en sluten loop. Det användbara testet är om någon utan egenintresse reproducerar hoppet från 39,4 till 61,5 på samma 500 uppgifter utan Microsofts kalibreringsarbete på uppgiftsuppsättningen.

För det andra måste någon kontrollera påståendet om testriggen från början till slut. Repositoriet är offentligt, vilket är mer än vad många utgåvor lyckas med, men det är utvärderingsriggen. Om de fem verktygen och sandlådeisoleringen verkligen är prestandamekanismen, bör en tredje part som kör den publicerade konfigurationen hamna nära de publicerade siffrorna. Om den inte gör det, är gapet det egentliga fyndet.

För det tredje, och billigast att svara på: Microsoft bör säga huruvida detta är en produkt eller en pappersartefakt. Kortets distributionsavsnitt behandlar vikterna, kortet och testramverket som leverabeln, vilket framstår som publicering snarare än lansering. "Releasedatum 22-SEP-2026" låter som en lansering. En annonserad modell skulle ha löst den tvetydigheten i första meningen i ett blogginlägg, och det finns inget blogginlägg.

Fram till dess är den rätta hållningen den som släppet självt antyder. FrogNano-4B-2609 är en riktig, nedladdningsbar MIT- och Apache- och kanske-inte-checkpoint med ett ovanligt utförligt modellkort, en offentlig utvärderingsharness, en genuin metodologisk idé och en resultattavla som aldrig har rörts av någon utan en Microsoft-adress. För ett labb är det en komplett och intressant artefakt. För ett team som är på väg att sätta en agent framför ett kodförråd klockan tre på morgonen är det ett spår värt att följa och ännu inte ett beslut värt att fatta.