Maximum Copilota za minimum tokenů

Praktický průvodce optimalizací nákladů pro GitHub Copilot po přechodu na token-based billing

Úvod

Od 1. června 2026 používá k účtování agentní práce Microsoft usage-based billing (info). Místo premium requestů se nově účtují tzv. AI Credits na základě skutečné spotřeby tokenů. Účtují se input, output i cached tokeny, přičemž každý model má vlastní cenu, kterou určuje vydavatel daného modelu. Jeden AI kredit odpovídá ceně 0,01 USD. Při nákupu balíčku za cenu 39 USD tak Microsoft přidělí 3900 AI kreditů a k nim zpravidla i bonusové kredity, které však dlouhodobě nejsou garantované. V případě cloud agenta a cloud code reviews se dále účtují action minuty na základě běhu prostředí. Code completions a Next Edit Suggestions zůstávají zdarma.

PREREQ#

  1. účet a sledování spotřeby tokenů u tasků Video
  2. debug logs a sledování spotřeby a použití cache (doc)
  3. úprava modelů v pickeru (ponechat jen preferované)
  4. lze použít BYOK, například u levně nakoupených tokenů na Azure (doc)

💡 TIP

Microsoft představil nový balíček Max pro individuální uživatele. Za cenu 100 USD dočasně nabídne zdarma dalších 100 USD v AI kreditech. Tato nabídka se může v průběhu času měnit, ale aktuálně se zdá jako velmi výhodná.

Instrukce

Instrukční soubory navazují na fine-tuning modelů a řešení v podobě RAG, aby umožnily jazykovým modelům lépe chápat kontext zdrojového kódu, se kterým pracují. Instrukce jsou strukturované markdown soubory obsahující informace o použitých technologiích, spouštění aplikace a základních konvencích a pravidelech. Instrukce se načítají ve dvou režimech:

  • always-on (eager loaded) - instrukční soubory se načtou na začátku session celé do kontextového okna
    • typicky: AGENTS.md, CLAUDE.md, GEMINI.md, .github/.copilot-instructions.md, .github/instructions/**.instructions.md

❗ IMPORTANT

GitHub Copilot v případě always-on instrukcí podporuje nejlépe soubor .copilot-instructions.md. Podpora souborů AGENTS.md a jiných se musí často povolit a je neúplná.

  • on-demand (lazy loaded) - instrukční soubory se načtou až na vyžádání LLM podle situace, místa práce, etc.
    • u on-demand instrukcí je nižší míra jistoty, že se načtou a že si je LLM vyžádá celé
      • důležité instrukce uvést vždy na začátek těchto instrukčních souborů
      • u nezbytně delších souborů dát na první řádky popis nebo stručný obsah

Definovat komunikační pravidla pro agentic AI#

Během reasoningu a agentic loops LLM neustále generuje ohledně své práce text do chatového okna. Jedná se o mnoho zbytečně generovaných tokenů, které nemají užitek. Cena těchto výstupních tokenů je 5x vyšší než cena input tokenů u Anthropic modelů, resp. 6x vyšší u OpenAI modelů.

  • přidat na začátek always-on instrukcí AI pravidlo ve smyslu:
## Agentic communication

Applies to all reasoning and agentic loops.
- Code only. Bullets, not paragraphs. Explain only if asked.
- No progress narration. No "Now I will...". No recaps.
- No summaries of what you just did unless requested.

Odstranit zbytečné instrukce#

Nástroje jako /init dokážou analyzovat repository a vygenerovat instrukční soubory. Tyto instrukční soubory ale často obsahují zbytečné a duplicitní informace, které LLM dokáže zjistit nebo je ani nepotřebuje znát. Kontextové okno tak obsahuje zbytečné až matoucí informace.

  • odstranit zbytečné instrukce a duplicity z always-on instrukčních souborů

Extrahovat instrukce specifické pro moduly#

Nechceme, aby instrukce specifické pro různé moduly nebo zřídka upravované části aplikace zbytečně a bez využití zaplňovaly kontextové okno každé session. Efektivnější je načítat specifické instrukce v režimu on-demand (na vyžádání).

  • extrahovat specifické instrukce do:
    • AGENTS.md - na úrovni podsložek, pro obecné instrukce spojené s moduly, nástroji nebo web parts
    • user invokable agents - když vědomě pracujeme na specifické oblasti (např.: security, design, REST API)
    • skills - tam, kde chceme univerzální použití v různých situacích (např.: brand design rules)

Psát stručné direktivy#

Instrukční soubory se načítají kompletně celé do kontextového okna. Jejich správa a velikost není udržitelná, pokud obsahují dlouhé textové odstavce. LLM preferují strukturovanou podobu a stručné imperativní instrukce. Související instrukce by měly být blíže u sebe.

  • psát krátké strukturované instrukce místo odstavců textu
  • používat zkratky, kterým LLM rozumí (repo, env, doc)
  • použít preferovaný model na přegenerování instrukcí do stručné podoby

Eliminovat zbytečné soubory z repository#

LLM často požaduje od agenta vylistovat obsah adresáře (list_dir) a číst celou řadu souborů, než najde ty správné. Nástroj grep_search zobrazí LLM i úryvky z nerelevantních souborů, ve kterých se nachází hledaná fráze.

  • odstranit z repository nerelevantní adresáře a soubory, které by mohl agent explorovat
  • lze použít .gitignore nebo ve VS Code použít nastavení files.exclude

Použít v instrukcích angličtinu#

Různé rodiny LLM používají různé tokenizery, které převádějí text na tokeny, za které probíhá účtování. V současné době se ukazuje, že modely Anthropic generují nad stejným českým textem o více než 10% více tokenů. Dále Anthropic Opus 4.7 a novější používá tokenizer, který oproti starším Anthropic modelů generuje až o 35% více tokenů. Dle dosavadních pozorování je tokenizace anglického textu oproti českému přibližně o 1/3 úspornější.

  • přeložit strukturovaný instrukční soubor do angličtiny

💡 TIP

Použití anglických instrukcí nebrání promptování v českém jazyce. Pro větší jistotu lze nastavit ve VS Code localeOverride na preferovaný jazyk.

Vylepšovat instrukce#

V průběhu času se může ukázat, že některé instrukce už nemusí dávat smysl nebo se mohou začít rozcházet s reálnou implementací. Zahozená inference znamená zbytečné náklady. Proto je důležité instrukce stále udržovat. VS Code umí ukládat sessions a následně u nich provádět analýzu a navrhnovat cílená doporučení.

  • použít funkci /chronicle improve (VS Code, Copilot CLI) pro návrh vylepšení instrukcí
Nástroje

GitHub Copilot agent používá ke své práci další custom agenty, subagenty, skills a nástroje. Na začátku každé chat session se připojují k systémovým instrukcím:

  • skills (name, description, file path)
  • agents (name, description, argumentHint)

Vedle systémových instrukcí se do LLM posílá i seznam nástrojů (tools). Tyto nástroje se posílají ve formátu JSON a obsahují velmi bohaté množství metadat. Každý jeden nástroj spotřebuje několik set až tisíc tokenů.

Optimalizovat seznam nástrojů a MCP serverů#

Každý MCP server se skládá z mnoha nástrojů (tools). Tools jsou popsány pomocí JSON struktur a konzumují velký prostor v kontextovém okně. Například azure_mcp obsahuje desítky nástrojů, jejichž JSON má velikost přes 58 kB, které se musí tokenizovat. Pro pohodlnou práci vám přitom dost možná postačí jen 2-3 nástroje z celého serveru.

  • projít si v nastavení VS Code nastavení MCP serveru a vybrat jen používané tools
  • Copilot CLI nepodporuje výběr nástrojů, zde je nutné tedy zbytečné servery vynechat

💡 TIP

Někdy je těžké určit, jaké tools z MCP serveru skutečně potřebujete. Až dokončíte task, který tools z daného MCP serveru použije, jednoduše napište do chatu: "Vypiš mi názvy MCP tools, které jsi během komunikace použil."

Optimalizovat seznam agentů a skills#

Agenti a skills se uchovávají nejen ve workspace, ale i ve složkách ~/.copilot a ~/.agents. Copilot vždy najde metadata všech agentů a skills a přidá je do systémových instrukcí v kontextovém okně. Nepoužívané agenty a skills je proto vhodné označit jako nevolatelné LLM modelem (a agent je pak do LLM nepošle). VS Code může též používat pluginy, které instalují vlastní (zbytečné) skills a agenty.

  • agenti, kteří jsou pouze user invocable skrýt pro LLM: disable-model-invocation: true
  • ověřit, zda nejsou zahrnuté zbytečné skills přidané v rámci VS Code pluginů
  • nepoužívané skills lze schovat pomocí nastavení disable-model-invocation: true
  • ověřit délku descriptions u skills a agentů (musí být stručné a věcné)

Preferovat skills před agenty a MCP tools#

Ačkoliv představují skills větší bezpečnostní rizika, nabízejí optimálnější možnosti použití v agentic AI. Místo nákladného volání tools lze vytvořit vlastní skripty a volat vzdálené nebo lokální služby s použitím skills.

  • ověřit, zda místo MCP serveru lze použít například REST API a vytvořit HTTP klienta + skill
Tradiční engineering

Mnoho jednoduchých úloh lze stále udělat jednoduchým zásahem do kódu. Jedná se o legitimní, rychlou a levnou strategii, během které můžete zároveň dělat review dosavadní práce LLM.

Pro vysvětlení kódu a menší editace použít Ask mode#

GitHub Copilot Chat nabízí režim Agent a Ask. Režim Ask je primárně určen pro levné dotazování nad code base. Lze ho ale používat i pro drobné editace.

  • pro vysvětlení více snippetů kódu používat multiselect a označit více snippetů do jednoho chatu
  • pro editaci metod a menších částí kódu použít Ask režim a navržený kód aplikovat přes ApplyTo

Cílené úpravy ve známých souborech provést ručně#

Žádat LLM o přidání číselníkové položky bez vazby na existující kód je nejen neekonomické, ale i časově neefektivní. Podobně například úpravy textů, popisy formulářových prvků nebo validační zprávy je daleko rychlejší provádět manuální úpravou kódu.

  • drobné změny v souborech, přidání číselníků atd. je vždy rychlejší a levnější přímo upravit
  • pro generování podobných částí kódu lze nadále použít zdarma code suggestions nebo next edit suggestions... funkci NES je nutné zapnout nastavením nextEditSuggestions.enabled
Prompt Engineering

Definice promptu zásadně ovlivňuje chování LLM a agenta. Přesnější prompt vede k menšímu množství agentic loops, zkracuje rychlost implementace a výrazně snižuje náklady. V neposlední řadě snižuje riziko, že celá úloha bude nepoužitelná. Mezi hlavní nástroje, které agent používá pro vyhledání relevantních code snippetů patří:

  • file_search - hledání souborů
  • grep_search - vyhledávání dle patternů (text, název třídy, názvy metod)
  • list_dir - seznam souborů v adresáři
  • read_file - čtení souboru, obvykle po desítkách (Anthropic) až stovkách řádků (OpenAI modely)

Každý neúspěšný pokus použití těchto nástrojů vede k dalšímu hledání a zbytečné inferenci.

Uvádět názvy souborů, třídy a identifikátory#

Aby nemusel LLM odhadovat relevantní názvy a instrukovat agenta ke zbytečým vyhledáváním code snippetů, vyjmenujte přesné názvy objektů, se kterými chcete pracovat.

  • uvádět přesný název souboru nebo část cesty pro dohledání, např.: Pages/Articles
  • uvádět přesné názvy metod, např.: GetUsers v Articles.cshtml
  • uvádět v rámci stránek konkrétní orientační body, např.: pod nadpisem "Aktuality"
Ve složce Pages/Admin/Users chci přidat v Index.razor vyhledávání.
Vyhledávat budeme v zaměstnancích (User.cs) dle (Name, Role, Description)
Vyhledávací pole umístit nad HTML sekci ID #results
Neměň metodu GetUsers, neměň DB schéma, neměň User.cs
...

Upravit code base pro lepší orientaci#

Instrukce obsahující zbytečné informace o cestách k souborům, hierarchických stromech a další informace obvykle jen suplují špatně organizovanou strukturu aplikace. Každá session pak obsahuje kontextové okno s instrukcemi, které jsou plné opakujících se informací, které lze eliminovat refaktoringem aplikace.

  • vytvářet pro každou třídu samostatný soubor a pojmenovat ho dle třídy
  • vytvářet menší třídy s vysokou kohezí, využívat například UseCase pattern místo Services
  • strukturovat repository dle paradigmatu feature folders, vertical slice architecture
  • logicky zanořovat složky, aby bylo snadnější instruovat AI, např.: Api/Payments

Rozdělit složité tasky na více menších#

Složitější tasky pracující na více částech aplikace, jako je například design databáze, návrh formulářů a backend implementace, trvají delší dobu a mají větší riziko kompaktování okna. Větší kontextové okno nese větší náklady s každým agentic loop a každý compact nese nepřesnost, která zvyšuje riziko, že výsledek práce se zahodí nebo se bude muset přepracovat.

  • složité tasky rozdělit na menší a pro každý zvolit nákladově optimální LLM model

Zvolit správný model#

Vybrat si menší množství LLM modelů a používat je pro specifické úlohy dle náročnosti. Ve většině případů je vhodné zvolit menší kontextové okno (200k spíše než 1M tokenů). Pro většinu agentních úloh splní práci velmi dobře Claude Sonnet 4.6, přičemž Anthropic doporučuje pro agentické kódování úroveň reasoningu medium. Dobré výsledky lze získat validací práce modelem jiné rodiny (např.: kontrola pomocí GPT 5.4). Reasoning generuje větší množství reasoning tokenů, které jsou zpravidla zpoplatněny jako output tokeny (cena 5-6x vyšší než input tokeny).

  • najít si svůj general purpose model pro většinu úloh (doporučuji začít s Claude Sonnet 4.6 / GPT 5.4)
  • pro složitější úlohy volit TOP frontier modely (Opus 4.6+ nebo GPT 5.5)
  • nepoužívat auto model selection (velké riziko slabého modelu, zahozená inference)

Respektovat cache a vyhnout se cache miss#

Každý LLM provider používán jinou strategii cachování. Microsoft optimalizuje cache pro Anthropic modely, které podporují explicit cache. Prefix tvoří nejprve top tools, dále systémové instrukce, zprávy a poslední 2 zprávy. Cache funguje zatím 5 minut (brzy zřejmě MS použije 1h TTL pro top tools). Každý model má vlastní prefix, takže změna modelu znamená cache miss a nové cachování. Modely OpenAI používají implicitní systém cachování. Obecné zásady nicméně platí i pro ně.

  • definovat si sadu tools a držet ji mezi sessions (případně plan, execute, validate)
  • od začátku do konce session neměnit zbytečně MCP tools a instrukce (vč. agentů a skills)
  • je-li větší kontextové okno, nesnižovat model na drobnou úpravu (např.: opus -> sonnet)
  • používat /compact pro kompakt kontextového okna (protože se větší část cache nadále použije)

Nepoužívat plan mode u jednoduchých úloh#

Plan mode je speciální plan.agent.md soubor, který používá vlastní sadu nástrojů a specifické instrukce pro plánování úlohy. U jednoduché úlohy není výhodné provést handoff, protože dochází k novému cachování a následně práci s plánem. Jednoduché úlohy zvládne agent i bez plánovací režie.

  • pro jednoduché úlohy použít rovnou agent mód bez plánování
  • pro pečlivě připravené implementační instrukce lze též rovnou použít agenta bez plánu
  • plánování lze zadat i ve formě promptu agentovi jako první krok ("navrhuj, neimplementuj")

Rozdělit exekuci na plan / implement / validate u složitých úloh#

U složitých úloh s obecným zadáním se může agent během práce vydat různými směry. Výhodnější je proto nejprve zadat vytvoření stručného implementačního plánu a ten následně ručně upravit. V další fázi lze použít specializované agenty pro implementaci a validaci. Každé dvě po sobě jdoucí fáze lze sloučit do jedné použitím funkce rubber-duck (aktuálně jen pro Copilot CLI) Video

  • složité úlohy nechat navrhnout nejprve plánovacím agentem
  • návrh plánu lze nechat ověřit jiným modelem, případně použít rovnou rubber-duck

Steerovat práci agenta, když jde špatným směrem#

Zejména u složitějších úloh se může stát, že se vývoj úlohy začne odebírat špatným směrem. Zahození všech změn a zahájení nové session představuje největší náklady. Zastavení úlohy a následné spuštění s sebou nese též menší režii. GitHub Copilot podporuje funkci steer, díky které lze nasměrovat agenta bez přerušení agentic loops.

  • pro korekci úlohy napište do VS Code chatu instrukci a u send šipky zvolte možnost steer

Pro UI úpravy používat integrated browser ve VS Code#

Pokud se v promptu nepopíše velmi přesně, kde má provádět LLM úpravy, může dojít k situaci, kdy LLM žádá agenta o mnoho zbytečných seznamů souborů (list_dir) a zbytečné načítání souborů, než najde správné místo. Integrated browser umožňuje přesně vybrat UI element, jehož metadata připojí do chatu a usnadní LLM najít konkrétní místa rychleji a s nížší spotřebou tokenů. Připojený obrázek má vždy malou velikost, která se účtuje u Anthropic vzorcem vyska*sirka/750.

  • při úpravě UI prvků používat browser a připojit související element Video
  • při opravách UI bugů připojovat screenshoty nebo aktivní záložku z integrated browser

Batchovat související úlohy do jedné session#

Vytvoření nové session pro sebemenší úpravu kódu s sebou nese dodatečné náklady, protože se musí v nejhorším případě poprvé cachovat celé kontextové okno. Uložení attention stavu do cache je přibližně 1,25x dražší než input tokeny (Anthropic modely). Je proto výhodné úlohy soustředit do jedné session. Díky nástroji multi_replace_string_in_file je dále výhodné provádět více drobných úprav najednou.

  • více drobných úprav na stránce nebo komponentě soustředit do jedné společné session
  • 2-3 velmi úzce související úpravy lze soustředit i do jednoho promptu

Kompaktovat delší konverzaci s drobnými úpravami#

Do LLM se posílá vždy kontextové okno obsahující kompletní instruktáž a historii konverzace. Pokud konverzace probíhá delší dobu, obsahuje nerelevantní detaily, které se neustále posílají do LLM. Konverzaci za systémovou instruktáží lze za minimální cenu (jednotky tokenů) kompaktovat.

  • dlouhé konverzace nebo velké kontextové okno včas kompaktovat pomocí /compact

Alternativní řešení zkoumat s pomocí funkce fork#

V některých situacích potřebujeme prozkoumat alternativní řešení určité úlohy. Vytvoření nové git branch a následné promptování od začátku k alternativní verzi úprav je spojeno s dodatečnými náklady. Výhodnější je využít dosavadní konverzaci včetně cachovaných dat a provést fork přímo z ní.

  • využít funkci fork ve VS Code chatu z místa, kde chceme zkoumat alternativní řešení
  • v případě drobné opravy lze použít restore checkpoint pro návrat o krok zpět
Workflow

Code Review v IDE může stačit oproti Cloud Code Review#

Visual Studio Code podporuje Code Review nad změněnými soubory. K tomuto Code Review se typicky používají modely z rodiny GPT od OpenAI a nabízí rychlou zpětnou vazbou nad vzniklým kódem. Tato review jsou levnější než komplexní Code Review v cloudu, která kromě tokenů spotřebují i action minutes.

  • používat code reviews ve VS Code v situacích, kdy postačuje rychlé review nad změněnými soubory

Opakující se plány přepsat do skills#

Některé typy úloh se na projektech neustále opakují. Například přidání API endpointu může zahrnovat čtení specifikace, generování DTOs, tvorbu validačních entit a samotnou implementaci. Pokud již jednou vznikne plán pro takovou implementaci, je škoda ho v budoucnu nepoužít a začít implementaci vždy od nuly.

  • nad funkčním plánem udělat fork a následně použít /create-skill pro vytvoření skillu

Používat šablony a generovat deterministické skripty#

Například při generování reportů vzniká velké množství kódu, které se musí tokenizovat a představuje velké náklady. Přitom opakované generování pomocí LLM není deterministické a vyžaduje nekonečné ladění.

  • po vygenerování složitých reportů pokračovat generováním šablony a skriptu pro opakované použití
  • při generování různých vizuálních prvků poskytnout odladěné ukázky (např.: přes skills)

Použít subagenty pro specifické úkoly během složitých tasků#

U velmi složitých úloh zvolíme pokročilý frontier model s high reasoningem. Pokud však v rámci session potřebuje takový model provádět rutinní úlohy, inference je zbytečně nákladná. Místo toho by mohl drahý LLM požádat subagenta s jednodušším modelem o levnější inferenci. Zvolit lze i opačnou strategii.

  • delegovat těžké rešerše na subagenty s levným modelem (např.: hledání v dlouhých md souborech)
Web Analytics

Rejoining the server...

Rejoin failed... trying again in seconds.

Failed to rejoin.
Please retry or reload the page.

The session has been paused by the server.

Failed to resume the session.
Please reload the page.