Claude Code vs Gemini CLI: Portabilitet för agentfärdigheter 2026

Jämförelsen mellan Claude Code och Gemini CLI har i grunden förändrats. Länge kretsade diskussionen kring kontextfönstrets storlek och vilken agent som hade bäst inbyggda förmågor. Men två nyliga förändringar har gjort den debatten förlegad. För det första stödjer båda agenterna nu samma öppna standard för färdigheter. För det andra är Gemini CLI inte längre ett verktyg riktat mot enskilda utvecklare.

Detta omformulerar hela frågan om Claude Code vs Gemini CLI. Fokus ligger inte längre på de proprietära funktionerna i varje körmiljö, utan på portabiliteten hos själva färdigheterna. Vad krävs för att en färdighet ska fungera tillförlitligt på alla plattformar som stödjer standarden? Och vad säger vår testdata – från att ha kört 2116 färdigheter i en Claude Code-miljö – om varför de går sönder?

Den gemensamma grunden: Agent Skills-standarden

Innan vi jämför körmiljöerna är det viktigt att förstå vad de har gemensamt. Frågan "fungerar färdigheter i gemini cli" har ett enkelt, direkt svar: ja. Detta beror på att både Claude Code och Gemini CLI, tillsammans med en växande lista av andra klienter som Codex, Cursor och OpenCode, har anammat det öppna Agent Skills-formatet.

Formatet, som ursprungligen utvecklades av Anthropic och nu underhålls som en öppen standard på agentskills.io, definierar en färdighet som en fristående katalog. Kärnan är en SKILL.md-fil som innehåller YAML frontmatter för metadata (som name och description) och en markdown-kropp med instruktioner för agenten. Denna katalog kan valfritt inkludera egna resurser, såsom skript i en scripts/-mapp eller referensdokument i references/.

Denna gemensamma standard innebär att en färdighet skriven för Claude Code i princip bör kunna läsas av Gemini CLI, och vice versa. Själva färdigheten är portabel. Skillnaderna uppstår i hur varje agents körmiljö upptäcker, laddar och exekverar den.

Körmiljöns mekanik: Hur Claude och Gemini kör färdigheter

Även om färdighetsformatet är detsamma, skiljer sig den operativa mekaniken hos Claude Code och Gemini CLI på viktiga punkter. Dessa skillnader påverkar hur färdigheter hanteras, hur de laddas in i kontexten och hur de interagerar med agentens säkerhetsmodell.

Exekvering av färdigheter i Claude Code

Claude Code letar efter färdigheter på två huvudsakliga platser: en global katalog på ~/.claude/skills/<name>/SKILL.md för personliga färdigheter, och en projektspecifik katalog på .claude/skills/<name>/SKILL.md. Den upptäcker också färdigheter i nästlade .claude/skills/-kataloger när den går igenom ett projekt.

När en uppgift utlöser en färdighet, renderar Claude Code hela SKILL.md-filen in i konversationen som ett enda meddelande. Denna kontext kvarstår under resten av sessionen; filen läses inte om vid efterföljande turer. Detta är ett enkelt, filbaserat tillvägagångssätt. Frontmatter-delen i SKILL.md tillåter också viss kontroll över agentens verktygsuppsättning under färdighetens exekvering. Nyckeln allowed-tools kan förhandsgodkänna specifika verktyg för den tur som anropar färdigheten, medan disallowed-tools temporärt kan ta bort verktyg från agentens räckvidd medan färdigheten är aktiv.

Exekvering av färdigheter i Gemini CLI

Gemini CLI använder ett mer strukturerat, flernivås upptäcktssystem och en tvåstegs laddningsprocess. Den söker efter färdigheter i en specifik prioritetsordning: inbyggda färdigheter, extensionsfärdigheter, användarfärdigheter (~/.gemini/skills/ eller aliaset ~/.agents/skills/), och slutligen arbetsytefärdigheter (.gemini/skills/ eller dess alias .agents/skills/).

Till skillnad från Claude Code laddar Gemini CLI inte hela färdigheten omedelbart. I början av en session injicerar den endast name och description för varje aktiverad färdighet i systemprompten. Detta håller den initiala kontexten liten. Först när modellen bedömer att en uppgift matchar en färdighet anropar den verktyget activate_skill. Detta utlöser en samtyckesfråga till användaren, som specificerar färdighetens namn, dess syfte och den katalogsökväg den kommer att beviljas åtkomst till. Efter användarens godkännande läggs hela SKILL.md-innehållet och dess mappstruktur till i konversationshistoriken, och färdighetens katalog läggs till i agentens lista över tillåtna filsökvägar.

Detta system hanteras via en dedikerad uppsättning kommandon, som gemini skills install <git-url-or-dir> --consent och /skills link <path> --scope user|workspace.

Här är en sammanfattning av de viktigaste skillnaderna:

Funktion	Claude Code	Gemini CLI
Sökväg för färdighet	~/.claude/skills/, .claude/skills/	~/.gemini/skills/, .gemini/skills/ (plus aliaset .agents/skills/)
Anrop	Hela SKILL.md injiceras vid första användning, kvarstår	Namn/Beskrivning i systemprompt; SKILL.md injiceras vid aktivering
Användarsamtycke	Implicit vid installation/placering	Explicit fråga vid första aktivering per session
Hantering	Filhantering	CLI-kommandon (gemini skills ..., /skills ...)

Den verkliga situationen 2026: Gemini CLI upphörde att vara ett konsumentverktyg

Den tekniska jämförelsen är nu till stor del akademisk för de flesta utvecklare. Den 19 maj 2026 meddelade Google att de övergår från Gemini CLI till ett nytt verktyg kallat Antigravity CLI. Från och med den 18 juni 2026 slutade Gemini CLI och de tillhörande Gemini Code Assist IDE-tilläggen att hantera förfrågningar för enskilda Google AI Pro- och Ultra-prenumeranter, samt för gratisnivån (som tidigare var 60 förfrågningar/minut och 1 000/dag).

Tjänsten fortsätter för företagskunder med Gemini Code Assist Standard- och Enterprise-licenser och för de som använder Gemini API via direktfakturering. gemini-cli-repot förblir publikt under en Apache-2.0-licens och är fortfarande under aktiv utveckling.

Avgörande är att Google har uppgett att de centrala agentteknologierna – Agent Skills, Hooks, Subagents och Extensions – kommer att föras över till Antigravity CLI, som beskrivs som en omskrivning i Go för prestanda. Tillkännagivandet nämnde inget om licensen för Antigravity CLI. Denna förändring omdefinierar vad valet mellan Claude Code och Gemini CLI ens innebär år 2026. För en enskild utvecklare utan företagslicens eller direkt API-fakturering är det inte längre ett val mellan två konsumentverktyg. Den praktiska frågan är om investeringen i att bygga ett personligt bibliotek av färdigheter kommer att vara portabel till framtida agent-körmiljöer.

Kontextfönster vs. färdighetsdjup

Mycket har sagts om Geminis annonserade kontextfönster på 1M tokens. Även om konfigurationer med stor kontext finns på båda sidor, missar man poängen om man fixerar sig vid antalet tokens. Kontextstorlek och färdighetsdjup löser olika typer av problem.

Ett massivt kontextfönster är kraftfullt för uppgifter som kräver en holistisk förståelse av en stor kodbas. Det gör att agenten kan hålla mer av ditt repo i sitt omedelbara minne, vilket kan vara ovärderligt för komplex refaktorering eller analys. Det löser dock inte problemet med att utföra handlingar.

Ett 1M token-fönster kan inte installera en saknad binärfil. Det kan inte provisionera en API-nyckel. Det kan inte fixa en SKILL.md-fil som är för vagt skriven för att utlösas tillförlitligt. Dessa är problem som rör färdighetsdjup – en agents förmåga att utföra en precis, repeterbar, miljömedveten uppgift. Det är domänen för en välskriven färdighet, och dess framgång beror ofta mindre på kontextfönstrets storlek och mer på miljön den körs i.

Vad vår data visar om varför färdigheter misslyckas (på alla plattformar)

Detta för oss till kärnan av problemet: varför misslyckas färdigheter? På SkillProof installerar och kör vi färdigheter för att publicera ett ärligt omdöme. Av de 2116 färdigheter vi har testat blir 1307 (62%) godkända, 704 markeras som "Fungerar med konfiguration" – de gör jobbet, men först efter konfiguration som måste specificeras – och 105 får ett underkänt omdöme: vissa kördes och lämnade dig i ett sämre läge än utan färdigheten, andra kunde inte köras alls.

För att vara helt tydlig: vi kör dessa tester uteslutande i en Claude Code-körmiljö. Vi har aldrig kört en färdighet på Gemini CLI eller Antigravity CLI, och vi gör inga påståenden om deras godkännandefrekvens. Hela vår process beskrivs i vår metodik.

Vår data om varför färdigheter misslyckas är dock högst relevant för alla körmiljöer. Vi skannade testanteckningarna för varje färdighet som inte blev helt godkänd. Resultaten är talande.

Av de 704 färdigheter som krävde konfiguration:

• 195 nämnde en saknad CLI eller binärfil.
• 99 var beroende av att en separat MCP-server var konfigurerad och igång.
• 92 krävde en API-nyckel eller annan autentiseringsuppgift.
• 64 behövde ett betalkonto eller en prenumeration.

Av de 105 färdigheter som fick ett underkänt omdöme:

• 27 involverade en saknad CLI eller binärfil.
• 12 var beroende av en MCP-server.
• 10 krävde ett betalkonto.
• 7 behövde en API-nyckel.

Dessa är antal från en nyckelordsskanning av våra egna testanteckningar, inte en uttömmande taxonomi av orsaker, och kategorierna överlappar: en enskild färdighet kan behöva både en CLI och en nyckel. Men mönstret är svårt att missa. Den överväldigande anledningen till att en färdighet underpresterar är ett beroende av den externa miljön. En färdighet som kräver en binärfil du inte har installerat kommer att misslyckas oavsett om du kör den via Claude Code eller Gemini CLI. En färdighet som behöver en API-nyckel kommer inte att fungera utan en, oavsett agentens kontextfönster.

Fallstudier: Var färdigheter blir godkända och underkända

Att titta på specifika exempel gör detta tydligt. Skillnaden mellan en godkänd färdighet och en som behöver konfiguration har ofta inget att göra med agentens körmiljö.

• Sync Agent Instructions: Denna coding-färdighet blev godkänd i våra tester. Dess syfte är att synkronisera instruktioner mellan CLAUDE.md-, GEMINI.md- och AGENTS.md-filer. Den fungerar eftersom den inte har några externa beroenden; den använder bara grundläggande skalkommandon som cp, git diff och git add. Dess logik är helt portabel. Värdet den tillförde jämfört med en naiv baslinje var dess precision – den "stageade" målfilerna korrekt via git add medan källfilen lämnades "unstaged".

• AI Multimodal: Denna data-färdighet fick omdömet "Fungerar med konfiguration". Dess skript är rena och använder den officiella google-genai Python SDK:n. Den kräver dock att SDK:n är installerad och, ännu viktigare, en aktiv GEMINI_API_KEY i miljön. Vi kunde inte provisionera en nyckel för testet, så dess output mättes aldrig. Detta är en Gemini-driven färdighet som misslyckas av en anledning som skulle blockera den lika effektivt inuti Gemini CLI självt.

• Amazon Alexa QA: Ett annat exempel på "Fungerar med konfiguration", denna seo-färdighet illustrerar problemet med dolda beroenden. Dess instruktioner nämner aldrig att den tyst kräver ett separat browser-act-cli-verktyg, som måste installeras via uv tool install browser-act-cli. Den behöver också ett aktivt, inloggat Amazon-konto. Detta felmönster är helt oberoende av agenten.

• AI Search Hub: Denna godkända data-färdighet är ett exempel på ett verktyg som bara fungerar. Vi körde dess dokumenterade kommando, och det returnerade ett korrekt svar på första försöket. Baslinjen – samma modell utan färdigheten – krävde tre försök och gav noll resultat.

Att jämföra Gemini CLI vs Claude Code för kodning är alltså mindre en fråga om de två verktygen och mer om de färdigheter du kör på dem. En gemensam standard är ett verkligt steg framåt, men som vår data visar, handlar portabilitet om huruvida en färdighet är ärlig med vad den behöver från den underliggande maskinen.

Relaterad läsning: vi ställde samma portabilitetsfråga mot OpenAI:s agent i Claude Code vs Codex CLI, och behandlade hur instruktionsfiler skiljer sig från färdigheter i AGENTS.md vs Claude Skills.

Detta är problemet som SkillProof byggdes för att lösa. Vi installerar varje färdighet, kör den på verkligt arbete och publicerar omdömet – inklusive de som misslyckas. Hela katalogen med 2116 testade färdigheter är gratis att bläddra i; om du hellre vill börja med en kortlista säljer vi även rollbaserade paket med tio färdigheter för $10 styck.