Narzędzia za 150 dolarów i 60 fakturowanych godzin to 2,50 dolara doliczone do każdej godziny w wycenie

Faktura za narzędzia przychodzi pierwszego dnia miesiąca, a projekt rozlicza się po odbiorze — i to jest cała przyczyna problemu. Abonament widać w księgowości jako koszt stały, więc do wyceny konkretnej strony nikt go nie dolicza. Tymczasem dzielnikiem, który decyduje o tym, czy ten koszt wraca, nie jest liczba osób w zespole ani liczba godzin w miesiącu, tylko liczba godzin, które naprawdę zafakturowałeś.

Niżej jest ten rachunek rozpisany: co z cennika narzędzi jest kosztem projektu, jak policzyć narzut na godzinę, dlaczego limity dostawców odnawiają się w innym rytmie niż tydzień odbioru i w której z trzech konstrukcji rozliczyć to z klientem.

Co z cennika narzędzi trafia do wyceny strony

Trzy cenniki, trzy różne konstrukcje. Cursor sprzedaje pulę zużycia dopisaną do planu: cennik Cursora podaje Plus za 8 dolarów miesięcznie, Premium za 30 z pulą czterokrotnie większą, Super za 100 i Ultra za 200, a plan zespołowy od 30 dolarów za użytkownika. GitHub liczy kredytami: strona planów Copilota wycenia Pro na 10 dolarów, Pro+ na 39 i Max na 100, przy kursie jednego kredytu równym 0,01 dolara, a dokumentacja rozliczeń dokłada Business za 19 dolarów za stanowisko z 1900 kredytami na użytkownika i Enterprise za 39 z 3900 kredytami. Anthropic rozdziela dostęp i zużycie: cennik Claude wymienia Pro za 20 dolarów miesięcznie i stanowisko zespołowe za 25, a przy Enterprise zapisuje wprost, że zużycie dolicza się ponad abonament według stawek API.

Dla wyceny istotny jest podział tych kwot na dwie kategorie, bo zachowują się inaczej.

Trzeci wiersz jest tym, o który najłatwiej się potknąć. Cennik Cursora zapisuje, że modele firm trzecich nie wchodzą w cenę planu i rozliczają się osobno po stawkach API. Jeśli zespół w połowie projektu przestawi się na inny model, bo lepiej radzi sobie z tym repozytorium, koszt nie rośnie o kilka procent — przechodzi do innej konstrukcji rozliczenia, z inną zmiennością.

Samo zużycie rozkłada się na pozycje o bardzo różnych cenach: wejście, wyjście, zapis do cache i odczyt z cache, przy czym w pracy agentowej dominuje wejście, bo historia kroków jedzie w kontekście przy każdym wywołaniu. Rozbicie tego rachunku na strumienie i to, dlaczego rośnie przy niezmienionym wolumenie pracy, jest osobnym tematem — opisuje je tekst o tym, dlaczego rachunek za agenta rośnie co miesiąc. Do wyceny strony wystarczy jedna konsekwencja: zużycie jednego developera pracującego w repozytorium z agentem bywa wyższe niż cena jego stanowiska, więc abonament jako jedyna pozycja w kalkulacji zaniża koszt o połowę.

Dzielnikiem jest godzina sprzedana, nie godzina w miesiącu

Tu wycena przelicza się najczęściej. Koszt narzędzi na osobę dzieli się nie przez 160 godzin etatowych, tylko przez godziny, które w danym miesiącu wystawiłeś na fakturze. Przy zestawie stanowisk z cennika wyżej — plan zespołowy w edytorze, stanowisko Business i stanowisko zespołowe u dostawcy modelu — wychodzi 74 dolary na osobę miesięcznie. Z rezerwą na zużycie ponad plan, przyjętą tu na 75 dolarów, daje to okrągłe 150 dolarów. Ta liczba jest założeniem do podmiany na własną, nie pomiarem.

Wniosek jest nieintuicyjny: narzut rośnie wtedy, gdy masz mniej pracy. W miesiącu z 60 sprzedanymi godzinami ten sam koszt narzędzi zabiera z marży ponad dwa razy więcej niż w miesiącu pełnym, a to jest dokładnie ten miesiąc, w którym negocjujesz stawkę w dół, żeby zdobyć zlecenie. Narzut policzony na pełnym obłożeniu nie pokrywa się w żadnym innym miesiącu.

Policz to na własnych danych, zamiast przyjmować kwotę z czyjegoś tekstu:

// narzut.mjs - koszt narzedzi na godzine fakturowana
// Kurs bierzemy z dnia obciazenia karty, nie z dnia wyceny - inaczej roznica
// kursowa wchodzi do marzy po cichu.
const KURS = Number(process.env.KURS_USD_PLN);

export function narzutNaGodzine({ stanowiskaUsd, zuzycieUsd, godzinyFakturowane }) {
  if (!godzinyFakturowane) throw new Error('brak godzin fakturowanych w okresie');
  const usd = (stanowiskaUsd + zuzycieUsd) / godzinyFakturowane;
  return { usd: +usd.toFixed(2), pln: +(usd * KURS).toFixed(2) };
}

// Trzy ostatnie miesiace, nie jeden: narzut liczony na najlepszym z nich
// nie pokryje sie w pozostalych.
export function narzutZOkresu(miesiace) {
  const koszt = miesiace.reduce((s, m) => s + m.stanowiskaUsd + m.zuzycieUsd, 0);
  const godziny = miesiace.reduce((s, m) => s + m.godzinyFakturowane, 0);
  return narzutNaGodzine({ stanowiskaUsd: koszt, zuzycieUsd: 0, godzinyFakturowane: godziny });
}

Jeżeli fakturujesz w złotych, a narzędzia kupujesz w dolarach, do rachunku wchodzi jeszcze różnica kursowa i rozliczenie podatku od usługi kupionej spoza kraju. Kursu z przyszłości nikt nie zna, więc albo liczysz narzut z zapasem, albo zapisujesz w ofercie przeliczenie po kursie z dnia obciążenia.

Limit odnawia się co tydzień, a odbiór trwa trzy dni

Rytm rozliczenia dostawcy nie ma nic wspólnego z rytmem projektu i to jest osobne źródło kłopotu. Cursor odnawia pulę zużycia co tydzień, Copilot wydziela kredyty w cyklu miesięcznym, a przy planach Claude limity liczą się w okienkach pięciogodzinnych i tygodniowych. Tydzień przed oddaniem strony wygląda inaczej niż każdy inny: wchodzą poprawki po przeglądzie, zmiany treści od klienta i druga runda testów. Zużycie w tych trzech dniach bywa wielokrotnością spokojnego tygodnia.

Skutki są dwa. Pula wyczerpana w środę nie wraca na życzenie — zostaje doładowanie za dodatkowe pieniądze albo przestój do odnowienia, a przestój w tygodniu odbioru kosztuje więcej niż doładowanie. Drugi: budżet na zużycie ponad plan trzeba ustawić, zanim się przyda. Strona planów Copilota opisuje budżet jako kwotę ustawianą przez Ciebie, z alertami przy 75, 90 i 100 proc. jego wykorzystania, a cennik Cursora przewiduje limity wydatków po stronie konta. Budżet zerowy oznacza, że narzędzie przestaje działać w najgorszym możliwym momencie; budżet bez limitu oznacza, że o kwocie dowiadujesz się po fakcie.

Ustawienie progu to decyzja operacyjna, nie techniczna, więc powinna mieć właściciela i miejsce obok reszty ustaleń o tym, kto co zatwierdza — najłatwiej powiesić ją na cyklicznym przeglądzie z wypełnioną agendą, bo wtedy ktoś patrzy na zużycie, zanim przyjdzie faktura. Bez takiego miejsca zużycie modelu będzie pierwszą pozycją, o której nikt nie wiedział, że jest jego.

Trzy konstrukcje rozliczenia i kto w nich ryzykuje

Narzut na stawkę godzinową działa przy krótkich zleceniach i nie wywołuje rozmowy: 1,5 dolara na godzinę jest kwotą, której w negocjacji stawki nikt nie zauważy. Haczyk siedzi w tabeli wyżej — narzut jest poprawny tylko dla tego obłożenia, dla którego go policzono. To ten sam rachunek, który trzeba zrobić, zaczynając we freelancingu z modelem w zestawie narzędzi: koszt stały rozkłada się na godziny, których jeszcze nie sprzedałeś.

Osobna pozycja w ofercie jest uczciwsza i trudniejsza do obrony, bo klient widzi kwotę i pyta, dlaczego ma płacić za Twoje narzędzia. Odpowiedź, która działa, nie dotyczy narzędzi, tylko wyniku: pozycja pokrywa środowisko, w którym powstaje i jest sprawdzany kod oddawany w tym projekcie. Jeśli rozmowa schodzi na to, że „przecież to robi model, więc powinno być taniej”, zużycie jest argumentem za Tobą — to koszt, którego przy pracy bez modelu nie było.

Trzecia konstrukcja, czyli klucz i stanowiska kupowane przez klienta, jest najczystsza przy projektach dłuższych niż dwa miesiące i przy utrzymaniu. Klient płaci dostawcy wprost, widzi zużycie w swoim panelu, a Ty fakturujesz tylko pracę. Warunek trzeba ustalić na starcie: ktoś po stronie klienta odpowiada za dostępy i limity, inaczej pierwszy wyczerpany budżet zatrzyma Twoją pracę, a nie jego. Zakres tych dostępów wymaga przy okazji tej samej ostrożności, co nadawanie narzędziom modelowym uprawnień w systemach firmy — klucz do rozliczeń i klucz do danych produkcyjnych to dwie osobne decyzje.

Cztery zapisy, które muszą być w ofercie

Konstrukcję wybiera się raz, a broni w każdej rozmowie o zakresie. Te cztery zdania robią to za Ciebie, bo przenoszą rozmowę z „czy płacić za narzędzia” na „ile tego zamawiasz”.

• Liczba rund poprawek w cenie. Zużycie rośnie z liczbą iteracji, a te zamawia klient. Bez zapisanej liczby rund ryczałt jest otwarty w jedną stronę.
• Kurs przeliczenia. Jeśli pozycja jest w złotych, a koszt w dolarach — kurs z dnia obciążenia albo narzut z zapasem, zapisany wprost.
• Próg i właściciel budżetu na zużycie. Kwota, po której przekroczeniu rozmawiacie, zamiast cichego doładowania albo cichego przestoju.
• Czyje stanowiska i czyj klucz. Przy utrzymaniu i projektach wielomiesięcznych — po stronie klienta, razem z nazwiskiem osoby, która tym administruje.

Zanim wyślesz wycenę

• Policz narzut z trzech ostatnich miesięcy, nie z najlepszego — dzielnikiem są godziny sprzedane, nie 160.
• Sprawdź w cenniku dostawcy, które modele są w puli planu, a które rozliczają się osobno po stawkach API.
• Ustaw budżet na zużycie ponad plan i przypisz mu właściciela przed startem, nie po pierwszym alercie.
• Rozpisz tygodnie odbioru osobno: zużycie w nich bywa wielokrotnością tygodnia spokojnej pracy.
• Zapisz liczbę rund poprawek w cenie, bo to ona napędza zużycie w drugiej połowie projektu.
• Przy projekcie dłuższym niż dwa miesiące zaproponuj stanowiska i klucz po stronie klienta.
• Zanotuj, na jakim zestawie narzędzi robiłeś wycenę — zmiana modelu w trakcie potrafi podwoić pozycję zużycia.

Decyzja do podjęcia przed następną ofertą jest jedna: w której z trzech konstrukcji rozliczasz narzędzia i zużycie. Przy zleceniach do miesiąca narzut na stawkę wystarcza, pod warunkiem że policzyłeś go na realnym obłożeniu, a nie na pełnym. Przy dłuższych projektach i utrzymaniu przenieś stanowiska i klucz na klienta — inaczej bierzesz na siebie ryzyko, którego nie kontrolujesz, bo liczbę iteracji zamawia ktoś inny.