Cloud AI bez niespodzianek: API, tokeny, koszty i prywatność w Home Assistant

Cloud AI bez niespodzianek: API, tokeny, koszty i prywatność w Home Assistant

Do tej pory świadomie budowaliśmy lokalny wariant Voice Assist z Ollamą. Teraz otwieramy drugi świat: modele chmurowe. Zanim w kolejnej lekcji podłączymy OpenAI, musimy dokładnie zrozumieć, za co właściwie płacimy, jakie dane mogą opuścić dom, czym różni się abonament aplikacji od API, dlaczego cztery wypowiedziane słowa mogą oznaczać tysiące tokenów kontekstu i jak przygotować Home Assistant tak, żeby pierwszy rachunek nie był eksperymentem na żywym systemie.

1. Dlaczego nie zaczynamy od wklejenia klucza API

Wiele poradników zaczyna od `utwórz API key`, a potem przechodzi od razu do integracji. To jest właśnie moment, w którym początkujący traci kontrolę nad całym obrazem. Klucz API nie jest abonamentem, model nie jest jedynym kosztem, a Home Assistant nie wysyła do LLM wyłącznie krótkiego zdania użytkownika.

W naszym LAB-ie najpierw odpowiadamy na cztery pytania: co wysyłamy, ile tego wysyłamy, ile to kosztuje i co się stanie po przekroczeniu budżetu. Dopiero w Lekcji 22 uruchomimy pierwszego cloud Conversation Agent.

2. ChatGPT Plus nie jest OpenAI API

To jedna z najważniejszych rzeczy przed rozpoczęciem. Subskrypcja ChatGPT i Platforma API są rozliczane osobno. Posiadanie ChatGPT Plus albo Pro nie oznacza, że Home Assistant może korzystać z API w ramach tego abonamentu.

Home Assistant łączy się z OpenAI API przy użyciu API key. W Platformie API trzeba osobno skonfigurować rozliczenia. Dokładnie tę konfigurację zrobimy w kolejnej lekcji.

3. Co właściwie kupujemy, gdy używamy modelu w Home Assistant

W typowym cloud Voice Assist możemy zapłacić za cztery niezależne warstwy:

Dlatego później porównamy nie tylko modele, ale całe pipeline. Bardzo często rozsądny wariant wygląda `Whisper lokalnie → cloud LLM → Piper lokalnie`. Wtedy płacimy tylko za warstwę językową i ograniczamy ilość audio wysyłanego poza dom.

4. Token nie jest słowem

Modele tekstowe nie rozliczają treści według liczby zdań czy słów. Tekst jest dzielony na tokeny. Token może być całym krótkim słowem, fragmentem słowa, znakiem interpunkcyjnym albo innym elementem kodowania.

Nie używamy prostego przelicznika `jedno słowo = jeden token`. Język, model i encoding mają znaczenie. Dla polskiego szczególnie nie warto przenosić wprost popularnego przybliżenia stworzonego dla angielskiego.

5. Cztery typy tokenów, które musisz rozróżniać

Krótkie zdanie wypowiedziane przez człowieka jest więc tylko małym fragmentem całego inputu.

6. Co Home Assistant może dołożyć do krótkiego pytania

Cloud Conversation Agent może otrzymać nie tylko `włącz lampę`. Do requestu dochodzą instructions, historia rozmowy, informacje potrzebne do dostępnych tools, opisy tych tools oraz kontekst wynikający z wybranej LLM API. Wbudowane Assist API pozwala modelowi działać na możliwościach i encjach wystawionych do Assist.

To właśnie dlatego liczba exposed entities i script tools ma znaczenie dla ceny. Home Assistant oficjalnie zaleca wystawianie minimalnej liczby encji także dlatego, że większy kontekst LLM podnosi koszt requestu.

7. Cztery słowa mogą oznaczać duży request

Użytkownik mówi:

Do modelu może jednak trafić znacznie więcej: instrukcja roli asystenta, aktualna rozmowa, schematy tools, nazwy i kontekst wystawionych urządzeń, Areas, aliasy, informacje wymagane przez Assist API i sama wypowiedź użytkownika. Nie oznacza to, że za każdym razem przesyłany jest identyczny zestaw danych przez każdego providera, ale projektowo musimy traktować udostępniony modelowi kontekst jako część kosztu i prywatności.

8. Pierwszy praktyczny audyt: ile Home Assistant widzi przez Assist

Otwórz Settings > Voice assistants > Expose. Nie zmieniaj jeszcze konfiguracji. Policz tylko encje, które są dostępne dla Assist i zapisz wynik w Test Packu.

Następnie sprawdź wystawione scripts. Pamiętaj z Lekcji 19: scripts nie pojawiają się LLM jako zwykłe encje, lecz jako callable tools. Ich description i fields również stają się częścią interfejsu przekazywanego modelowi.

9. Tworzymy dwie liczby bazowe dla całego przyszłego LAB-u

Zapisz:

EXPOSED ENTITIES = ______

EXPOSED SCRIPT TOOLS = ______

Będziemy wracać do tych wartości w OpenAI, Gemini, Claude i późniejszym Token LAB-ie. Dzięki temu różnice pomiędzy providerami będą mierzone na tej samej instalacji, a nie na przypadkowych konfiguracjach.

10. Cloud nie oznacza, że wysyłamy cały Home Assistant

Wbudowane Assist API nie daje LLM administracyjnego dostępu do Home Assistant. Jego możliwości odpowiadają funkcjom i exposed entities dostępnych dla wbudowanego Conversation agent. To ważna granica.

Nie oznacza to jednak, że prywatność przestaje być problemem. Nazwa `Sypialnia Marka`, stan czujnika obecności, lista pomieszczeń czy opis skryptu mogą same w sobie być informacją prywatną. Dlatego ekspozycja nie jest wyłącznie kwestią sterowania. Jest również decyzją o kontekście, który może trafić do zewnętrznego providera.

11. Co może opuścić dom przy cloud Conversation Agent

Najprostszy sposób myślenia jest taki: jeśli cloud model ma na czymś pracować, te dane muszą zostać do niego wysłane w formie odpowiedniej dla danej integracji. Dla tekstowego Conversation Agent będą to przede wszystkim tekst użytkownika, instrukcje, historia rozmowy oraz dane i opisy potrzebne do dostępnych narzędzi.

Jeżeli później wybierzemy cloud STT, poza dom wyjdzie również audio wejściowe. Jeżeli wybierzemy cloud TTS, do providera trafi tekst odpowiedzi przeznaczony do syntezy. Gdy w przyszłości użyjemy AI Task z obrazem kamery, provider otrzyma również attachment.

12. Dlatego hybrid privacy jest bardzo ciekawą architekturą

Voice PE
  -> Whisper lokalnie
  -> cloud LLM
  -> Piper lokalnie

W tym wariancie provider językowy dostaje transkrypcję i kontekst potrzebny do odpowiedzi, ale nie musi otrzymywać surowego nagrania użytkownika ani generować audio. Nie jest to „pełna prywatność”, lecz realne ograniczenie zakresu danych opuszczających instalację.

W kolejnych lekcjach za każdym razem porównamy tę architekturę z pełnym cloud pipeline.

13. API key traktujemy jak hasło administratora do rachunku, nie jak zwykły identyfikator

Klucz API pozwala wykonywać płatne requesty w zakresie uprawnień projektu. Nie wklejamy go do artykułów, screenshotów, GitHuba, publicznego YAML ani wiadomości na forum. Jeśli klucz wycieknie, zakładamy kompromitację i go unieważniamy.

W OpenAI będziemy używać osobnego projektu przeznaczonego dla Home Assistant i klucza ograniczonego do tego projektu. To daje czytelny koszt, prostszy audyt i łatwiejszy rollback niż używanie jednego klucza do wszystkich eksperymentów AI.

14. Projekt API jest jednostką porządku i kosztów

OpenAI Platform pozwala śledzić użycie per projekt, ustawiać dostęp do modeli, rate limits, budżety i alerty. Dlatego w następnej lekcji utworzymy osobny projekt, np. `Home Assistant LAB`.

Nie chodzi wyłącznie o estetykę. Jeżeli później testujesz OpenAI także w innym programie, osobny projekt pozwala odróżnić koszt Home Assistant od reszty konta.

15. Budżet, alert i twardy limit to nie zawsze to samo

To miejsce wymaga ostrożności, bo interfejs i możliwości platform providerów zmieniają się. OpenAI pozwala obecnie definiować limity wydatków i alerty na poziomie organizacji/projektu, ale nie każdy budżet jest automatycznie twardym odcięciem. Część ustawień historycznie pełniła rolę progu monitorującego.

Dlatego w Lekcji 22 nie napiszemy po prostu `ustaw 5 USD i jesteś bezpieczny`. Sprawdzimy w aktualnym panelu, czy dane ustawienie jest monitoringiem czy enforced spend limit. Zapiszemy to w Test Packu.

16. Prepaid jest dobrym startem, ale też nie jest idealnym bezpiecznikiem

OpenAI oferuje przedpłacone credits. Minimalny zakup wynosi obecnie 5 USD. Automatyczne doładowanie można wyłączyć, co jest sensownym ustawieniem na początek LAB-u.

Trzeba jednak znać dwa szczegóły. Credits wygasają po roku i nie podlegają zwrotowi. Po drugie, odcięcie po wyczerpaniu salda może mieć krótkie opóźnienie, więc możliwe jest chwilowe saldo ujemne. Nie traktujemy prepaid jako idealnego wyłącznika bezpieczeństwa.

17. Auto-recharge wyłączamy na start

Przy konfiguracji prepaid automatyczne doładowanie może być proponowane jako aktywne. Na pierwsze lekcje MarkLabs wyłączymy je. Chcemy zobaczyć realne zużycie, zanim pozwolimy platformie automatycznie kupować kolejne środki.

Dopiero po kilku dniach rzeczywistego użycia można świadomie ustawić próg, kwotę doładowania i miesięczny limit automatycznych zakupów.

18. Koszt requestu tekstowego liczymy prostym wzorem

uncached_input = input_tokens - cached_input_tokens

cost =
  uncached_input / 1_000_000 * input_price
+ cached_input / 1_000_000 * cached_input_price
+ output_tokens / 1_000_000 * output_price
+ ewentualne opłaty za tools

Reasoning tokens są w OpenAI zaliczane do wykorzystania wyjściowego, nawet jeśli nie widzisz ich jako tekstu odpowiedzi. Dlatego bardzo krótka odpowiedź nie zawsze oznacza minimalne output usage.

19. Aktualne ceny OpenAI wykorzystujemy tylko jako przykład rachunku

Na dzień przygotowania tej lekcji GPT-5.6 Luna kosztuje 0,20 USD za milion input tokens, 0,02 USD za milion cached input i 1,20 USD za milion output. Terra to odpowiednio 2,00 / 0,20 / 12,00 USD, a Sol 4,00 / 0,40 / 20,00 USD.

Nie oznacza to, że w Lekcji 22 automatycznie wybierzemy najtańszy model. Cena jest tylko jednym parametrem. Potrzebujemy jeszcze poprawnego polskiego, tool calling, target accuracy, czasu odpowiedzi i stabilności.

20. Przykład A: lekki asystent bez dużego kontekstu

Załóżmy hipotetycznie, że pojedynczy request ma 8 000 input tokens i 500 output tokens. W miesiącu wykonujemy 100 takich requestów i pomijamy caching, żeby policzyć górny prosty wariant.

To przykład, nie obietnica rachunku. Twój Home Assistant może mieć zupełnie inny context size.

21. Przykład B: duży kontekst i częste użycie

Załóżmy teraz 20 000 input tokens, 500 output tokens i 1000 requestów miesięcznie. Nadal ignorujemy cache.

Ten przykład pokazuje, dlaczego nie wystarczy stwierdzenie `tokeny są tanie`. Ten sam dom i ta sama liczba rozmów może kosztować zupełnie inaczej w zależności od modelu oraz wielkości kontekstu.

22. Cache może zmienić rachunek, ale najpierw musimy go zmierzyć

Powtarzający się system prompt i podobny zestaw tools mogą kwalifikować się do prompt caching. Provider może wtedy rozliczyć część inputu po niższej stawce.

Nie zakładamy jednak konkretnego procentu cache przed pomiarem. W odpowiedziach API można zobaczyć cached-input usage, a w późniejszym Token LAB-ie będziemy porównywać cold request i kolejne podobne wywołania.

23. Tool call może oznaczać więcej niż jedno przejście przez model

To jeden z najczęściej pomijanych elementów rachunku. Prosta rozmowa może zakończyć się po jednej odpowiedzi modelu. Sterowanie domem może wymagać dodatkowego kroku: model wybiera tool, Home Assistant go wykonuje, wynik wraca do rozmowy, a model formułuje końcową odpowiedź.

Użytkownik
  -> model
  -> tool call

Home Assistant
  -> wykonuje tool
  -> tool result

model
  -> końcowa odpowiedź

Dlatego jedna wypowiedź może generować więcej pracy niż sugeruje jedna linia tekstu w interfejsie.

24. Local-first ma znaczenie również finansowe

Lekcja 18 nie była tylko optymalizacją szybkości. Jeśli `włącz światło` zostanie obsłużone lokalnie przez Home Assistant, cloud model w ogóle nie musi dostać requestu. To oznacza brak kosztu LLM dla tej komendy.

Dlatego w przyszłych cloud pipeline zachowamy `Prefer handling commands locally`. Cloud AI ma być używane tam, gdzie daje wartość, a nie jako kosztowny przekaźnik dla każdej żarówki.

25. Expose minimum to jednocześnie prywatność, wydajność i koszt

Im większy zestaw exposed entities, tym więcej nazw, aliasów i kontekstu system musi przetwarzać. Home Assistant oficjalnie wskazuje, że duża liczba encji pogarsza dopasowanie i przy LLM zwiększa koszt requestu przez większy context size.

Nie będziemy więc wystawiać całego domu „bo model jest mądry”. Zaczynamy od tego samego małego zestawu, który przygotowaliśmy dla Ollamy.

26. Audyt nazw i aliasów przed cloud AI

Przejrzyj exposed entities i zaznacz te, których nazwy same w sobie ujawniają więcej, niż chcesz wysyłać do zewnętrznego providera. Przykłady to imiona domowników, opis pomieszczenia medycznego, nazwa urządzenia związana z bezpieczeństwem albo zbyt szczegółowy opis rutyny.

Nie musisz paranoicznie zmieniać całego Home Assistant. Chodzi o świadomą decyzję. To, co jest całkowicie nieszkodliwe w lokalnej Ollamie, może mieć inny profil prywatności przy cloud Conversation Agent.

27. Script descriptions też są częścią powierzchni danych

Jeśli wystawiasz script tool, jego opis pomaga LLM zrozumieć funkcję. Nie umieszczaj tam PIN-u, hasła, tokenu, numeru alarmu ani innych sekretów.

To samo dotyczy field descriptions. Opis narzędzia ma tłumaczyć funkcję, a nie przechowywać poufne dane potrzebne skryptowi.

28. Cloud API i trenowanie modeli to nie to samo co ChatGPT dla użytkownika indywidualnego

W przypadku OpenAI API dane wejściowe i wyjściowe nie są domyślnie używane do trenowania modeli. Użytkownik może świadomie opt-in do udostępniania danych. To różni się od sposobu, w jaki wiele osób intuicyjnie myśli o zwykłej aplikacji konsumenckiej.

Nie oznacza to jednak `dane nigdy nie są przechowywane`. OpenAI opisuje domyślne logi monitoringu nadużyć z retencją do 30 dni, chyba że obowiązują inne warunki lub użytkownik kwalifikuje się do Zero Data Retention. Dlatego privacy plan musi obejmować zarówno trening, jak i retencję.

29. Opcja Store requests and responses w Home Assistant ma osobne znaczenie

Aktualna integracja OpenAI Home Assistant ma opcję `Store requests and responses in OpenAI`. Jest ona domyślnie wyłączona. Po włączeniu requesty i odpowiedzi mogą być widoczne w logach dashboardu OpenAI.

W naszym baseline pozostawimy tę opcję OFF. Do diagnozy użyjemy najpierw Home Assistant Debug oraz API usage dashboard, a dodatkowe logowanie u providera włączymy tylko wtedy, gdy faktycznie będzie potrzebne.

30. Web Search tworzy kolejną warstwę kosztu i danych

OpenAI integration może udostępnić modelowi web search. Wtedy pojawia się koszt narzędzia oraz dodatkowy kontekst wyszukiwarki. Home Assistant może także przekazać lokalizację instancji do wyszukiwarki, jeśli włączysz `Include home location`.

Dlatego Web Search będzie OFF w pierwszym OpenAI baseline. Włączymy je dopiero w osobnym kontrolowanym teście i policzymy różnicę czasu oraz kosztu.

31. Service tier też wpływa na koszt i opóźnienie

Aktualny Home Assistant pozwala dla OpenAI wybierać m.in. Auto, Standard, Flex i Priority. Flex może obniżyć koszt kosztem czasu odpowiedzi, więc pasuje bardziej do zadań wykonywanych w tle niż do głosu. Priority ma zapewniać niższe i stabilniejsze opóźnienia za wyższą cenę.

Na pierwsze testy Conversation nie będziemy optymalizować tieru. Użyjemy baseline i najpierw poznamy zwykłą latencję.

32. Pro mode nie jest przełącznikiem „lepiej za darmo”

Dla GPT-5.6 i nowszych Home Assistant może udostępnić Pro mode. Model wykonuje wtedy więcej pracy, co może poprawić niezawodność trudnych zadań, ale zwiększa token usage, koszt i opóźnienie.

Nie włączamy Pro mode do zwykłego Voice Assist. W późniejszym Provider Shootout sprawdzimy, czy w naszym zestawie testowym daje mierzalną poprawę, która uzasadnia cenę.

33. Rate limit i brak pieniędzy mogą wyglądać podobnie

Błąd HTTP 429 nie zawsze oznacza `wysyłasz za dużo requestów`. Może oznaczać rate limit, wyczerpane prepaid credits albo przekroczony limit użycia. Zawsze czytamy konkretny kod błędu.

To ważne dla przyszłego troubleshooting. Dokupowanie credits nie naprawi rate limitu, a retry loop nie naprawi wyczerpanego salda.

34. Ustalamy budżet MarkLabs LAB przed pierwszym requestem

Wpisz w Test Packu własny miesięczny budżet testowy. Nie podaję jednej obowiązkowej kwoty, bo ktoś może chcieć tylko wykonać kilka lekcji, a ktoś inny korzystać codziennie.

Dla początkującego ważniejsze od wysokości kwoty są zasady: osobny projekt, alerty, brak auto-recharge na start, codzienna kontrola Usage podczas pierwszych testów oraz mały zestaw exposed entities.

35. Ustalamy też limit eksperymentalny na jedną lekcję

Miesięczny budżet to za mało. Jeśli w skrypcie powstanie pętla, możesz spalić znaczną część limitu w godzinę. Dlatego każdy provider test będzie miał własny plan: ile prób wykonujemy, jaki model wybieramy i kiedy przerywamy eksperyment.

Przykład MarkLabs: `10 testów tekstowych + 10 testów głosowych + 5 tool calls`, potem sprawdzamy Usage. Dopiero po kontroli robimy kolejną serię.

36. Nigdy nie benchmarkujemy kosztu przy działającej automatycznej pętli

Pierwsze cloud testy wykonujemy ręcznie. Nie tworzymy jeszcze automatyzacji `co minutę zapytaj model o stan domu`. Cloud AI w automatyzacji wymaga osobnych zabezpieczeń: cooldown, limit wywołań, warunek zmiany danych i obsługa błędów.

Te wzorce będą częścią późniejszego modułu AI Task. W Voice Assist głównym triggerem pozostaje człowiek, co naturalnie ogranicza liczbę requestów.

37. Przygotowujemy stały zestaw testów, zanim pojawi się pierwszy provider

Żeby później uczciwie porównywać OpenAI, Gemini, Claude, OpenRouter i modele lokalne, potrzebujemy identycznego zestawu prób. Nie porównujemy jednego modelu na pięciu encjach, a drugiego na całym domu.

W Lekcji 21 ustalamy bazowy zestaw MarkLabs:

Jeśli Twoje nazwy są inne, to nie problem. Ważne, żeby przez cały provider block używać tego samego zestawu.

38. Tworzymy również stały zestaw pytań

Na razie nie wykonujemy ich w chmurze. Zapisujemy tylko benchmark, który będzie wracał w kolejnych lekcjach:

39. Koszt mierzymy razem z trafnością

Model, który jest dziesięć razy tańszy, ale trzy razy wybiera zły target, nie jest automatycznie lepszym wyborem do domu. Dlatego każda późniejsza lekcja providera będzie zapisywać równocześnie koszt i jakość.

Dla każdej serii zapisujemy: PASS/FAIL, latency, input tokens, cached input, output tokens, reasoning tokens jeśli występują, liczbę tool calls oraz koszt. W Voice Assist dopiszemy także STT i TTS latency.

40. Rozdzielamy koszt rozmowy od kosztu sterowania domem

Pytanie `czym jest Zigbee?` to inny workload niż `włącz lampę`. Pierwsze może wymagać dłuższej odpowiedzi, drugie tool call i krótkiego potwierdzenia.

W naszych arkuszach nie będziemy mieszać obu klas w jedną średnią. Powstaną osobne kolumny: conversation, home control i później web/research.

41. Ustalamy politykę prywatności dla trzech rodzajów danych

Na etapie Voice provider block pracujemy tylko na zielonym zestawie LAB. Żółte dane pojawią się dopiero później w osobnym module AI, z osobną oceną ryzyka. Czerwonych danych nie używamy jako prompt context.

42. Audio traktujemy jako osobną klasę prywatności

Surowe nagranie głosu może zawierać więcej niż sama transkrypcja: głos osoby, tło, inne rozmowy, telewizor czy dźwięki domu. Dlatego przejście z lokalnego Whispera na cloud STT jest osobną decyzją prywatności, a nie tylko zmianą modelu.

Podobnie cloud TTS dostaje tekst, który ma wypowiedzieć. Jeśli odpowiedź zawiera prywatne dane o domu, ten tekst również trafia do zewnętrznej usługi syntezy.

43. Nigdy nie zapisujemy API key w materiałach kursu

W screenshotach i notatkach używamy placeholdera typu `sk-proj-...REDACTED`. Nie pokazujemy nawet końcówki prawdziwego klucza, jeśli nie jest potrzebna.

Jeżeli podczas przygotowywania lekcji przypadkiem wkleisz klucz do publicznego miejsca, nie próbuj oceniać, czy ktoś zdążył go skopiować. Od razu go unieważnij i wygeneruj nowy.

44. Własny projekt API ułatwia również usunięcie dostępu

Kiedy zakończysz testy z providerem, możesz usunąć lub zablokować klucz przeznaczony wyłącznie dla Home Assistant bez naruszania innych aplikacji. To jeden z powodów, dla których nie używamy jednego klucza `do wszystkiego`.

45. Przygotowujemy punkt odniesienia z Ollamy

Zanim zaczniemy OpenAI, wykonaj przez obecną Ollamę trzy testy i zapisz czasy:

To nie jest jeszcze provider shootout. Chodzi o zapisanie lokalnego baseline: ile trwa system, który już działa i nie nalicza kosztu per request. Później będziemy wiedzieć, co realnie zyskaliśmy albo straciliśmy po przejściu do chmury.

46. Koszt lokalnego modelu też nie wynosi zero

Ollama nie ma rachunku per token od zewnętrznego providera, ale komputer zużywa energię, ma koszt zakupu, zajmuje RAM/VRAM i wymaga utrzymania. Nie będziemy jednak sztucznie przeliczać tego na jeden uniwersalny koszt tokena, bo sprzęt i taryfy energii różnią się bardzo mocno.

W finalnym Provider Shootout pokażemy cloud cost per request oraz osobno parametry local hardware. To uczciwsze niż udawanie, że jedna liczba opisze oba modele kosztowe.

47. PASS prywatności nie oznacza „nic nie wychodzi do chmury”

Jeśli świadomie wybierasz cloud LLM, część danych musi go opuścić. PASS oznacza, że wiesz które dane, dlaczego i które celowo zatrzymałeś lokalnie.

Wariant `Whisper -> cloud LLM -> Piper` może być świetnym kompromisem. Inny użytkownik wybierze pełny cloud Voice, bo bardziej zależy mu na jakości STT/TTS. Kurs ma pozwolić podjąć tę decyzję świadomie, a nie narzucić jedną architekturę.

48. Warunek PASS Lekcji 21

Rozumiesz, że abonament aplikacji AI i API są osobnymi produktami. Potrafisz rozróżnić STT, LLM, TTS i dodatkowe tools jako osobne potencjalne źródła kosztu. Znasz input, cached input, output i reasoning tokens oraz potrafisz policzyć koszt requestu z cennika providera.

Masz zapisane `EXPOSED ENTITIES` i `EXPOSED SCRIPT TOOLS`, własny miesięczny budżet LAB-u, limit liczby prób na jedną lekcję oraz politykę danych zielone/żółte/czerwone. API key będzie tworzony w osobnym projekcie, auto-recharge na pierwszy test ma być wyłączone, a Store requests and responses pozostanie w baseline OFF.

Masz również trzy czasy baseline Ollamy. Wiesz, że local-first może oszczędzać nie tylko czas, ale również cloud requesty, oraz że mała ekspozycja to jednocześnie wydajność, koszt i prywatność.

49. Co zrobimy w Lekcji 22

W Lekcji 22 przejdziemy przez OpenAI od absolutnego zera: Platforma API, projekt `Home Assistant LAB`, billing, prepaid/limity, API key, instalacja oficjalnej integracji OpenAI w Home Assistant i pierwszy Conversation Agent bez prawa do sterowania domem.

Na końcu wykonamy pierwsze płatne requesty, otworzymy Usage, odczytamy tokeny i porównamy rzeczywisty koszt z szacunkiem przygotowanym w tej lekcji. Dopiero gdy rachunek i przepływ danych będą zrozumiałe, zaczniemy budować OpenAI Voice pipeline.