GitHub mijenja način na koji neka poduzeća kupuju Copilot. Organizacije koje rade putem GitHub ili Microsoftovog tima za račune sada mogu omogućiti Copilot pristup svakom korisniku pokrivenom GitHub Enterprise licencom, bez kupnje zasebnog Copilot mjesta za svaku osobu.
Uključivanje je pristup, a ne paket AI dopuštenja. Potrošnja kopilota mjeri se od prvog zahtjeva prema proračunu poduzeća, a aranžman ne daje mjesečne AI kredite po licenciranom korisniku. Ta razlika čini promjenu manje sličnom paketu neograničenog softvera, a više sličnom pravu na platformu potkrijepljenom potrošnjom temeljenom na korištenju.
Što GitHub uključuje
Prema novom dogovoru, poduzeće može učiniti Copilot dostupnim cijeloj svojoj licenciranoj GitHub populaciji. Korisnici bez GitHub Enterprise licence još uvijek mogu biti pokriveni putem Copilot Standalone-a, koji GitHub navodi 10 USD po korisniku mjesečno.
Ne prestaje svaka funkcija Copilot-a kada tvrtka nema dostupan AI proračun. GitHub kaže da dovršavanje koda i prijedlozi za sljedeće uređivanje nastavljaju raditi. Copilot Chat, pregled koda i funkcionalnost oblaka, međutim, zahtijevaju raspoloživ proračun. Administratori stoga moraju razumjeti tko ima pristup i koje značajke ostaju upotrebljive nakon što se dosegnu ograničenja potrošnje.
Uvođenje također nije dovršeno. GitHub rekao je da će dostupnost samoposluživanja stizati u fazama i nije je otvorio u vrijeme objave. Za sada, ispunjavanje uvjeta i kupnja mogu ovisiti o postojećem odnosu računa i tima, a ne o postavci koju svaka organizacija može odmah omogućiti.
Pristup i potrošnja postaju odvojene kontrole
Tradicionalna nabava softvera po sjedalu daje financijskim timovima relativno predvidljivu gornju granicu: broj dodijeljenih licenci pomnožen s fiksnom cijenom. Nova struktura GitHub odvaja pravo korištenja Copilota od iznosa potrošenog korištenjem njegovih značajki mjerenja.
To može pojednostaviti početno pružanje jer administratori više ne moraju točno predviđati koji će Enterprise korisnici trebati Copilot prije odobravanja pristupa. Također pomiče operativni rad prema proračunima, pripisivanju korištenja i upozorenjima. Široko dostupna značajka može generirati neujednačene troškove među timovima, spremištima i tijekovima rada, tako da će organizacije morati odlučiti kako se centralno financirana upotreba interno dodjeljuje.
Ovdje AI API kontrole potrošnje za timove postaju dio rutinske administracije razvojne platforme. Tvrtka može trebati gornje granice za cijelu tvrtku, dodjele odjela i upozorenja koja stižu prije nego značajke chata ili pregleda postanu nedostupne. Zamjensko ponašanje također je važno: dostizanje granice proračuna ne proizvodi jedno jedinstveno stanje Copilot-a jer se neka pomoć pri uređivanju nastavlja dok druge mogućnosti prestaju.
Zašto je promjena važna i nakon GitHub
Dogovor jača model kupnje u kojem je pristup AI-u združen u veću razvojnu platformu dok se varijabilna potrošnja naplaćuje zasebno. To stvara drugačiju usporedbu za tvrtke koje procjenjuju neovisne pomoćnike kodiranja, API-je za izravne modele ili multi-model API pristupnik za timove.
Relevantno pitanje više nije jednostavno košta li jedno Copilot mjesto više ili manje od drugog alata. Kupci moraju usporediti cjelokupnu kombinaciju radnog opterećenja: koliko korištenja otpada na dovršetak, chat, pregled ili funkcije u oblaku; koja aktivnost troši proračun; i mogu li se troškovi pripisati timovima koji su ih stvorili. Bez podataka o korištenju, usporedba cijene sjedala može prikriti stvarnu financijsku razliku.
Operateri pristupnika i preprodavača također bi trebali očekivati da poslovni korisnici traže slično jasno odvajanje između pristupa računu i naplative potrošnje.Proizvodi koji nude objedinjenu AI API naplatu trebat će izvješćivanje koje može stajati pored proračuna ugrađenih u glavnu razvojnu platformu, uključujući atribuciju na razini modela ili na razini ključa, a ne samo zbirnu fakturu.
Ono što ostaje nejasno
GitHub nije objavio točan datum za opću dostupnost samoposluživanja. Financijski učinak također je nemoguće generalizirati samo iz objavljenih uvjeta. Organizacija s intenzivnom upotrebom značajki chata, pregleda i oblaka s odmjeravanjem vremena mogla bi vidjeti drugačiji ishod od one čiji razvojni programeri uglavnom koriste prijedloge za dovršetak i sljedeće uređivanje.
Poduzeća koja razmatraju dogovor trebaju uspostaviti osnovnu liniju prije promjene modela nabave: aktivni korisnici, kombinacija značajki, trenutni troškovi kopilota i prihvatljivo ponašanje prekida kada je proračun iscrpljen. Najava proširuje pristup, ali će praktični rezultat biti određen obrascima korištenja i time koliko precizno administratori mogu predvidjeti, dodijeliti i nametnuti povezani proračun.