Michael JohnsonPokud vývojář používá Copilot prostřednictvím nástroje třetí strany, běžné statistiky podle IDE nemusí ukázat, odkud požadavky přicházejí. Dne 23. října 2026 GitHub přidal do API Copilot usage metrics pole totals_by_client, které seskupuje používání modelů podle klientů, včetně OpenCode, Claude Code, Codex a Zed. Správcům tak umožňuje nahlédnout na část aktivity mimo editor a přesněji řešit interní pravidla používání AI.
Co nový přehled obsahuje
Každá položka v totals_by_client uvádí klienta, počet úspěšných volání modelu, počet relací a objem vstupních i výstupních tokenů spolu s jejich průměrným počtem na jedno volání. Vnořené pole totals_by_model rozděluje tyto ukazatele podle modelů a zobrazuje režim výběru: model zvolil přímo uživatel, vybral se automaticky, nebo jej určil produkt.
Pole je dostupné v jednodenních a 28denních přehledech pro podniky a organizace i v uživatelských přehledech na těchto úrovních. V souhrnném 28denním přehledu jsou údaje podle klientů uvedeny pro každý den. Jde o doplňkovou změnu: dosavadní pole zůstávají zachována a při nedostupnosti dat je pole prázdné. Podrobnosti GitHub popsal v oznámení nového přehledu usage metrics.
Na jaké otázky data odpovídají
Tým může porovnat objem požadavků a tokenů přicházejících z různých nástrojů a rozhodnout, které integrace podporovat nebo zahrnout do firemních pravidel. Například růst podílu OpenCode v přehledu může naznačovat, že vývojáři používají Copilot jako poskytovatele modelů mimo IDE. Porovnání klientů a modelů pomáhá zjistit, které modely ve skutečnosti vytvářejí největší zátěž.
Při rozpočtové analýze je užitečné začít u tokenů a počtu volání a následně je porovnat s platnými cenovými podmínkami. request_count počítá volání modelu, nikoli uživatelské prompty: jeden prompt může vyvolat několik volání. Toto pole se proto hodí k analýze zátěže modelové služby, ale ne k přímému počítání interakcí vývojářů.
Jak metriku začlenit do pracovního postupu
- Ověřte přístup. Zásady Copilot usage metrics musí být zapnuté. Přehledy mohou získávat oprávnění vlastníci podniku nebo organizace, správci fakturace a role s oprávněním zobrazovat příslušné metriky.
- Porovnávejte stejná období. Jednodenní přehled použijte ke kontrole změn po zapnutí nástroje a 28denní přehled ke sledování dlouhodobého rozložení aktivity. V každém přehledu rozlišujte volání, tokeny a relace — jde o různé ukazatele zátěže.
- Nastavte prahové hodnoty pro kontrolu. Můžete například označit klienta, jehož podíl tokenů nebo volání výrazně vzrostl oproti jeho vlastnímu předchozímu období. Prahovou hodnotu zvolte podle svých požadavků a obvyklé zátěže; GitHub žádnou univerzální hodnotu nestanovuje.
- Porovnejte přehled s nastavením přístupu. Nové údaje lze využít při rozhodování o podpoře a správě nástrojů. Samotné přehledy zachycují zaznamenané používání, nenahrazují však kontrolu oprávnění ani inventarizaci integrací.
Oficiální dokumentace API Copilot usage metrics popisuje přehledy, požadavky na oprávnění i dostupné řezy. Než automatizaci nastavíte, ověřte v dokumentaci aktuální schéma požadovaného přehledu a používejte odpovídající oprávnění.
Co označení klienta znamená
GitHub určuje klienta podle integration ID, které nástroj předává spolu s požadavkem. Společnost označuje toto seskupování za přibližnou identifikaci: hodnota pomáhá agregovat provoz, sama o sobě však nepotvrzuje totožnost uživatele ani pravost aplikace. Neznámí klienti se zařazují do skupiny other a hodnoty, které nelze normalizovat, se mohou zobrazit jako unknown.
Existují také zvláštní případy: volání Copilot code review a Copilot cloud agent mají režim výběru product_selected, protože model vybírá produkt; u code review se model může zobrazit jako unknown. To je důležité zohlednit při porovnávání přehledů modelů napříč nástroji.
Praktický závěr: totals_by_client pomáhá zaplnit mezeru v evidenci volání Copilotu z externích nástrojů na straně serveru a poskytuje správcům nové údaje pro analýzu zátěže a rozhodování o podpoře. Chcete-li z těchto podrobností získat spolehlivý obraz používání, porovnávejte je s oprávněními a dalšími interními zdroji a názvy klientů chápejte jako kategorie provozu, nikoli jako potvrzenou identitu.