Zobacz, co naprawdę robi Claude Code: tracing w LangSmith i Langfuse

Claude Code pokazuje w terminalu całkiem sporo. Kolejne wywołania narzędzi przewijają się na ekranie, na końcu jest diff i podsumowanie. To jednak widok chwilowy. Po godzinie pracy scrollback jest już nie do przejrzenia, długie wyniki są zwinięte, a to, co działo się w środku subagenta, przepada razem z jego podsumowaniem.

Przez to część pytań zostaje bez odpowiedzi. Ile razy agent przeczytał ten sam plik? Który tool call zjadł najwięcej kontekstu? W którym momencie zaczął krążyć wokół tego samego problemu? Zostaje końcowy efekt i wrażenie, że trwało to dłużej, niż powinno.

Da się to zmienić w kilka minut, bez żadnego proxy i bez ruszania klucza do API Anthropica. Zarówno LangSmith, jak i Langfuse mają gotowe pluginy, które wpinają się w system hooków Claude Code i wysyłają każdą turę do twojego dashboardu observability ^[1][4].

Skąd biorą się te dane

To nie jest podsłuchiwanie ruchu do API ani proxy przed modelem. Oba narzędzia korzystają z systemu hooków Claude Code, czyli skryptów odpalanych w konkretnych punktach cyklu życia sesji ^[9]. Różnią się tym, jak głęboko się w nie wpinają.

Langfuse idzie drogą minimalną. Rejestruje Stop, który odpala się na koniec tury, oraz SessionEnd na domknięcie sesji ^[5]. Skrypt czyta plik transkryptu, czyli JSONL z wiadomościami usera, odpowiedziami modelu, wywołaniami narzędzi i ich wynikami, przerabia go na drzewo trace'a i wysyła ^[4].

Plugin LangSmith wpina się w dziewięć punktów naraz: UserPromptSubmit, PreToolUse, PostToolUse, Stop, StopFailure, SubagentStop, PreCompact, PostCompact i SessionEnd ^[2]. Wywołania narzędzi są dzięki temu zbierane wtedy, kiedy się dzieją, a osobne hooki łapią zakończenie subagenta i kompakcję kontekstu. To dwa zdarzenia, które w samym transkrypcie widać najsłabiej.

W obu przypadkach tury z jednej sesji spina wspólne ID sesji ^[6]. Ten design ma trzy konsekwencje:

• Kompletny trace jest po turze, a nie w jej trakcie. Dokumentacja LangSmith mówi wprost, że trace jest pełny dopiero po tym, jak Claude Code odpowie ^[1]. To nie jest podgląd na żywo na wzór debuggera.
• Timestampy są odtwarzane wstecz. Hook Langfuse sięga po wewnętrzne API tracera OTel, żeby ustawić historyczny start_time i end_time z transkryptu ^[4]. Dzięki temu czasy trwania w dashboardzie są prawdziwe, a nie zlepione w jedną milisekundę w momencie wysyłki.
• Hook nie blokuje sesji. Langfuse deklaruje to wprost: brak SDK, brak zmiennej środowiskowej, padnięta sieć i skrypt po cichu kończy pracę, nie zatrzymując Claude Code ^[4][5]. Dlatego debugowanie zaczyna się od pytania, czy hook w ogóle się odpalił.

LangSmith: trzy komendy i jeden blok JSON

Potrzebujesz CLI Claude Code, Node.js i klucza API do LangSmith ^[1]. Pythona nie potrzebujesz wcale, plugin jest napisany w TypeScripcie.

Instalacja ma dwie równoważne formy ^[11]. W trakcie sesji używasz komend ze slashem, spoza sesji tych samych operacji przez claude plugin w shellu. Ta druga forma przydaje się w skrypcie startowym albo na nowej maszynie.

Najpierw rejestrujesz marketplace, czyli katalog, z którego pochodzi plugin:

/plugin marketplace add langchain-ai/langsmith-claude-code-plugins

lub

claude plugin marketplace add langchain-ai/langsmith-claude-code-plugins

Potem instalujesz sam plugin, podając go w formacie nazwa@marketplace:

/plugin install langsmith-tracing@langsmith-claude-code-plugins

lub

claude plugin install langsmith-tracing@langsmith-claude-code-plugins

Na koniec przeładowanie, żeby plugin wstał w bieżącej sesji zamiast dopiero po restarcie:

/reload-plugins

Potem mówisz pluginowi, dokąd ma wysyłać. Najczyściej przez plik ustawień projektu, .claude/settings.local.json:

{
  "env": {
    "TRACE_TO_LANGSMITH": "true",
    "CC_LANGSMITH_API_KEY": "lsv2_pt_...",
    "CC_LANGSMITH_PROJECT": "moj-projekt"
  }
}

Ten sam blok env działa też w ~/.claude/settings.json, czyli na poziomie użytkownika. Ustawienia rozstrzygają się per zmienna, a projekt ma wyższy priorytet niż użytkownik ^[10], więc najwygodniejszy jest podział na dwa pliki. Globalnie trzymasz klucz i włącznik, raz na całą maszynę, w ~/.claude/settings.json:

{
  "env": {
    "TRACE_TO_LANGSMITH": "true",
    "CC_LANGSMITH_API_KEY": "lsv2_pt_..."
  }
}

A w repozytorium, w .claude/settings.json, samą nazwę projektu:

{
  "env": {
    "CC_LANGSMITH_PROJECT": "moj-projekt"
  }
}

Sesja w tym katalogu dostaje wszystkie trzy zmienne, a każdy inny katalog trafia do projektu claude-code, bo taka jest wartość domyślna ^[2]. Po stronie repo wybierz settings.json, nie settings.local.json. Ten pierwszy jest commitowany, a nazwa projektu nie jest sekretem, więc cały zespół dostaje ten sam podział trace'ów. Klucz zostaje wyłącznie u ciebie. W drugą stronę działa to tak samo: TRACE_TO_LANGSMITH ustawione na "false" w ustawieniach projektu wyłącza wysyłkę akurat tam. Zanim włączysz tracing globalnie, sprawdź tylko, czy chcesz obejmować nim każde repozytorium, w którym odpalasz Claude Code, łącznie z cudzymi.

I to tyle. Używasz Claude Code normalnie, a po jego odpowiedzi przełączasz się do LangSmith. Każda twoja wiadomość jest osobnym trace'em, a w środku masz komplet: prompt użytkownika, każde wywołanie narzędzia, zużycie tokenów, runy subagentów i finalną odpowiedź ^[3]. Zakładka Threads grupuje wszystkie tury jednej sesji w jeden wątek, więc śledzisz całą rozmowę, a nie pojedyncze strzały.

Dokumentacja pokazuje tylko część zmiennych. README repozytorium wymienia jeszcze CC_LANGSMITH_METADATA (dowolny JSON doklejany do wszystkich runów), CC_LANGSMITH_REDACT i CC_LANGSMITH_REDACT_EXTRA (o nich w sekcji o prywatności) oraz LANGSMITH_ENDPOINT, czyli adres API ^[2].

Ta ostatnia jest obowiązkowa dla każdego, kto nie siedzi na domyślnej instancji. LangSmith działa w czterech regionach i każdy ma własny adres API ^[12]:

Prefiksy są tu niekonsekwentne i sam się na tym przejechałem. Wpisałem do ~/.claude/settings.json zmienną CC_LANGSMITH_ENDPOINT z adresem EU, bo wszystkie pozostałe zmienne pluginu zaczynają się od CC_. Taka zmienna nie istnieje. Plugin czyta adres wyłącznie jako LANGSMITH_ENDPOINT, pod nazwą z SDK, co widać w src/config.ts ^[2]. Mój klucz z workspace'u EU leciał więc na domyślny host w US, autoryzacja nie przechodziła, hook milczał. Objaw: pusty projekt w LangSmith.

Klucz API jest łaskawszy i przyjmuje obie formy, CC_LANGSMITH_API_KEY z fallbackiem na LANGSMITH_API_KEY.

Langfuse: plugin albo hook w Pythonie

Są dwie drogi, a wybór nie jest oczywisty, bo dokumentacja i repozytorium pluginu opisują różne stany tego samego projektu.

Droga pierwsza, plugin ^[5]. Marketplace:

/plugin marketplace add langfuse/Claude-Observability-Plugin

lub

claude plugin marketplace add langfuse/Claude-Observability-Plugin

Plugin:

/plugin install langfuse-observability@langfuse-observability

lub

claude plugin install langfuse-observability@langfuse-observability

Po restarcie konfigurujesz go komendą:

/plugin configure langfuse-observability@langfuse-observability

Sekretny klucz ląduje wtedy w keychainie systemowym, a nie w pliku w katalogu projektu. To istotna różnica, do której zaraz wrócę. Runtime: albo uv na PATH (wtedy SDK dociąga się samo), albo Python z zainstalowanym langfuse>=4.0,<5. Plugin rejestruje dwa hooki: Stop po każdej turze i SessionEnd na domknięcie sesji.

Droga druga, ręczna ^[4]: instalujesz SDK, wrzucasz skrypt ~/.claude/hooks/langfuse_hook.py, rejestrujesz go globalnie w ~/.claude/settings.json i włączasz per projekt przez .claude/settings.json:

{
  "env": {
    "TRACE_TO_LANGFUSE": "true",
    "LANGFUSE_PUBLIC_KEY": "pk-lf-...",
    "LANGFUSE_SECRET_KEY": "sk-lf-...",
    "LANGFUSE_BASE_URL": "https://cloud.langfuse.com"
  }
}

Jeśli idziesz tą drogą, dopisz .claude/settings.json do .gitignore, zanim wkleisz tam sekret. Dokumentacja mówi o tym wprost i ma rację ^[4].

Podział na plik użytkownika i plik projektu działa tu identycznie, bo to mechanizm Claude Code, nie pluginu ^[10]. Różni się to, co w którym pliku ma sens. W LangSmith nazwa projektu jest zwykłym stringiem, więc nadpisujesz ją per repo. W Langfuse projekt wynika z pary kluczy, bo klucze wydaje się wewnątrz konkretnego projektu ^[4]. Rozbicie trace'ów na kilka projektów oznaczałoby więc osobną parę kluczy w każdym repozytorium, czyli sekret w pliku projektu. Tego bym nie robił.

Sensowniejszy układ to klucze i region raz w ~/.claude/settings.json, a w repozytorium wyłącznie przełącznik:

{
  "env": {
    "TRACE_TO_LANGFUSE": "false"
  }
}

Tak wyłączysz tracing tam, gdzie go nie chcesz, nie ruszając reszty konfiguracji. Przy instalacji pluginem sekret siedzi w keychainie i nie ma go w żadnym settings.json, więc plik użytkownika trzyma wtedy tylko włącznik i ewentualnie region. Rozdzielenie sesji na repozytoria robisz już po stronie Langfuse, filtrując po metadanych trace'a, które niosą między innymi ścieżkę transkryptu ^[4].

Ręczny wariant ma jeszcze jeden koszt, który autorzy uczciwie nazywają krytycznym: skrypt opiera się na wewnętrznych elementach SDK w wersji 4.x, konkretnie na _otel_tracer i _create_observation_from_otel_span. Stąd pin >=4.0,<5, bo zmiana nazwy prywatnej metody w kolejnej wersji minor po prostu wyłączy tracing bez jednego słowa w logach ^[4]. Jeżeli szukasz rozwiązania, które ma przeżyć rok bez zaglądania, plugin jest bezpieczniejszym wyborem niż własna kopia skryptu.

Zostają regiony i tu wdepnąłem drugi raz, tym razem przez pominięcie. Nie ustawiłem LANGFUSE_BASE_URL w ogóle, bo dokumentacja Langfuse podaje jako domyślny endpoint EU, a moje konto stoi właśnie w EU ^[4]. Wyglądało to na zmienną, której nie muszę dotykać. Hook ma jednak zaszyty inny default:

host = _opt("LANGFUSE_BASE_URL") or _opt("CC_LANGFUSE_BASE_URL") or "https://us.cloud.langfuse.com"

To linia 121 z hooks/langfuse_hook.py ^[5]. Bez tej zmiennej ruch idzie do US, klucze z konta EU nie przechodzą autoryzacji i kończy się identycznie jak przy LangSmith: cisza w logu, pusty projekt w dashboardzie.

Wpisz swój host jawnie, zamiast liczyć na wartość domyślną, bo dokumentacja i kod mówią tu co innego ^[4][5]. Drobna pociecha: prefiks CC_, który wywrócił mi konfigurację LangSmith, akurat tutaj działa, bo hook przyjmuje również CC_LANGFUSE_BASE_URL.

Co z tego realnie widać

Trace pokazuje rytm pracy agenta: tool call, generacja, tool call, generacja. W Langfuse dostajesz to jako trzy poziomy zagnieżdżenia, czyli tura, generacje w turze i spany narzędzi pod generacją, która je wywołała ^[4]. W LangSmith każda wiadomość jest osobnym trace'em, a spany narzędzi i subagentów siedzą w środku ^[1].

To zrzut z mojej sesji i widać na nim więcej, niż zapowiada sam opis. Kolumna spanów ma stały rytm: Claude, Bash, Bash, Claude. Przy każdym wywołaniu modelu stoi licznik tokenów, który w obrębie jednej tury rośnie z 66,5K do 75,4K. Kontekst puchnie o dziewięć tysięcy tokenów, zanim tura w ogóle się skończy.

Langfuse dokłada kolumnę, której w tym widoku LangSmith nie pokazał: koszt. Wywołanie modelu ze zrzutu to 28,41 s, 66 958 tokenów i 0,44588 USD na claude-opus-5. W LangSmith ta sama pozycja miała $0.00. Nie sprawdzałem, czy to kwestia cennika skonfigurowanego po stronie projektu, czy tego, że plugin nie wysyła danych o koszcie. Różnica jest realna i przy szacowaniu rachunku ma znaczenie.

To samo dotyczy agentów, które budujesz

Claude Code jest tu wygodnym poligonem, bo trace stawiasz w kilka minut i na cudzym kodzie. Mechanika jest jednak ta sama, co u ciebie w LangGraph albo w gołej pętli na SDK. Agent nie wywala się stack trace'em. On po prostu robi coś innego, niż powinien, i kończy odpowiedzią, która wygląda poprawnie.

Na etapie budowania trace jest jedynym miejscem, w którym widać, skąd wzięła się zła odpowiedź: które narzędzie zwróciło śmieć, w którym kroku wypadł kontekst, ile razy model próbował tego samego. Bez tego debugujesz przez zgadywanie i ponowne uruchamianie, a przy niedeterministycznym modelu ten sam błąd nie musi się powtórzyć.

Na produkcji dochodzą liczby: koszt sesji, latencja pojedynczego kroku, odsetek tur kończących się błędem narzędzia. I materiał na ewaluację, bo nieudany przebieg z produkcji to gotowy przypadek testowy, a zmianę promptu albo narzędzia da się porównać przed i po, zamiast oceniać ją na wyczucie. Agent na produkcji bez tracingu to usługa bez logów. Da się, tylko trudno to obronić.

Które wybrać

Ceny, stan na lipiec 2026. LangSmith: plan Developer za 0 USD daje do 5 tys. trace'ów miesięcznie i jedno miejsce, Plus kosztuje 39 USD za miejsce i podnosi próg do 10 tys., retencja bazowa to 14 dni ^[7]. Langfuse: Hobby za darmo z 50 tys. jednostek i retencją 30 dni, Core za 29 USD ze 100 tys. jednostek, retencja 90 dni, plus wariant self-hosted za zero ^[8].

Zanim uznasz, że darmowy próg wystarczy, policz, ile realnie generuje jedna sesja. Trace'y z Claude Code są grube. Każdy odczyt pliku, każdy Bash, każdy Grep to osobny span z pełnym wejściem i wyjściem, a jedna intensywna sesja to kilkadziesiąt tur. Dla jednej osoby darmowy próg spokojnie wystarczy. Dla pięcioosobowego zespołu pracującego tak codziennie rachunek wygląda już inaczej, zwłaszcza po stronie retencji. Dla skali: tura ze zrzutu wyżej to 795,6 tys. tokenów, a lista z jednego dnia pracy ma u mnie ponad dwadzieścia wątków.

Praktycznie: LangSmith, jeśli i tak stoisz na LangChain albo LangGraph i chcesz mieć agenty produkcyjne oraz Claude Code w jednym miejscu, a do tego zależy ci na tracingu w CI. Langfuse, jeśli dane nie mogą opuścić twojej infrastruktury, albo potrzebujesz konkretnego regionu, albo po prostu nie chcesz kolejnego SaaS-a w budżecie. Podłączenie obu naraz jest technicznie możliwe, ale to podwójny narzut na każdą turę i podwójna kopia transkryptu na zewnątrz. Nie polecam tego jako domyślnego układu.

O czym trzeba pomyśleć, zanim włączysz

Transkrypt sesji Claude Code to nie są metadane. To twój kod, ścieżki plików, fragmenty konfiguracji, wyniki poleceń shellowych i wszystko, co przypadkiem wylądowało w outputcie narzędzia. Włączenie tracingu oznacza wysyłanie tego do zewnętrznego systemu.

LangSmith robi z tym jedną rzecz, której Langfuse nie robi wcale: redaguje sekrety po stronie klienta, zanim cokolwiek wyjdzie. Domyślnie strippuje klucze API, JWT, bloki PEM i typowe wzorce credentiali, a własne reguły dokładasz przez CC_LANGSMITH_REDACT_EXTRA ^[2]. To dobra obrona, ale nie magia. Regex nie rozpozna sekretu, który nie wygląda jak sekret, i nie zredaguje danych osobowych, które agent wyciągnął z bazy podczas debugowania.

Po stronie Langfuse nie ma odpowiednika. Przeszukałem hooka pod kątem redakcji, maskowania i anonimizacji i nie ma tam niczego takiego ^[5]. Transkrypt idzie na serwer w całości, przycięty jedynie na progu CC_LANGFUSE_MAX_CHARS. Przy danych, które nie mogą wyjść na zewnątrz, zostaje self-hosting.

Druga rzecz: plugin LangSmith dokleja do trace'ów anthropic_user_id czytany z ~/.claude.json oraz local_username, czyli twój login systemowy ^[2]. W kontekście zespołowym to dane osobowe pracownika w systemie zewnętrznego dostawcy. Nie jest to problem sam w sobie, ale jest to coś, co powinno się znaleźć w rejestrze czynności przetwarzania, a nie wyjść na jaw przy audycie.

Poziom wyżej: CI i zagnieżdżanie

Najciekawszy wątek w dokumentacji LangSmith jest schowany najgłębiej. Ten sam plugin da się włączyć w GitHub Actions razem z anthropics/claude-code-action, a metadane wypełnić danymi pull requesta ^[1]:

- uses: anthropics/claude-code-action@v1
  env:
    TRACE_TO_LANGSMITH: "true"
    CC_LANGSMITH_API_KEY: ${{ secrets.LANGSMITH_API_KEY }}
    CC_LANGSMITH_PROJECT: "moj-projekt"
    CC_LANGSMITH_METADATA: |
      {
        "pr_url": "${{ github.event.pull_request.html_url || '' }}",
        "pr_number": "${{ github.event.pull_request.number || '' }}",
        "repository": "${{ github.repository }}",
        "commit_sha": "${{ github.sha }}"
      }
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    github_token: ${{ secrets.GITHUB_TOKEN }}
    plugin_marketplaces: |
      https://github.com/langchain-ai/langsmith-claude-code-plugins.git
    plugins: |
      langsmith-tracing@langsmith-claude-code-plugins
    prompt: |
      Twój prompt

Każda decyzja agenta recenzującego pull requesty ma wtedy trace podpięty pod konkretny PR i commit. Przy pytaniu, dlaczego bot zablokował zmianę, odpowiedź jest w linku do trace'a.

Drugi mechanizm to zagnieżdżanie. Jeśli odpalasz Claude Code jako podproces w swoim własnym, otraceowanym pipelinie, możesz przekazać dotted_order rodzica przez CC_LANGSMITH_PARENT_DOTTED_ORDER i zobaczyć całość jako jedno drzewo ^[1]:

@traceable
def run_claude(prompt: str):
    run_tree = get_current_run_tree()
    subprocess.run(
        ["claude", "-p", prompt],
        env={
            **os.environ,
            "TRACE_TO_LANGSMITH": "true",
            "CC_LANGSMITH_API_KEY": "lsv2_pt_...",
            "CC_LANGSMITH_PROJECT": "claude-code",
            "CC_LANGSMITH_PARENT_DOTTED_ORDER": run_tree.dotted_order,
        },
    )

To jest wzorzec dla harnessów, które odpalają dziesiątki sesji w pętli: migracja kodu, batchowy refactor, ewaluacja wariantów promptu. Langfuse ma odpowiednik w postaci CC_LANGFUSE_TRACEPARENT w standardzie W3C ^[5].

Kiedy to nie działa

Cztery rzeczy odpowiadają za większość problemów ^[6]:

1. Pusty log hooka. ~/.claude/state/hook.log dla LangSmith, ~/.claude/state/langfuse_hook.log dla Langfuse. Pusto oznacza, że hook w ogóle się nie odpala, więc problem jest w rejestracji, a nie w kluczach.
2. Włącznik jako string. "true" małymi literami, w cudzysłowie. Nie boolean, nie "True". To brzmi jak drobiazg i kosztuje ludzi po pół godziny.
3. Tryb debug. CC_LANGSMITH_DEBUG albo CC_LANGFUSE_DEBUG ustawione na "true" zwykle mówi wprost, co poszło nie tak.
4. Właściwy runtime i właściwy katalog. Claude Code musi być uruchomiony z katalogu projektu, w którym leżą ustawienia z włącznikiem.

Do tego dwa udokumentowane ograniczenia. W LangSmith subagenci są trace'owani dopiero po zakończeniu, więc przerwanie tury w środku pracy subagenta oznacza utratę całego jego poddrzewa ^[1]. Przy stylu pracy, w którym Esc jest normalnym narzędziem, zdarza się to częściej, niż by się chciało. W Langfuse z kolei aplikacje desktopowe nie czytają profili shella, więc konfiguracja musi iść przez /plugin configure, a zwykły czat w Claude Desktop nie jest łapany w ogóle, bo nie stoi na hookach ^[5].

Co z tym zrobić dzisiaj

Wybierz jedno narzędzie, wpnij je w jeden projekt i przepracuj z nim normalny dzień. Potem otwórz dashboard i poszukaj pliku czytanego wielokrotnie, narzędzia wołanego dwa razy z tym samym argumentem, kroku, który zjadł nieproporcjonalnie dużo czasu. Każde takie miejsce to linijka do dopisania w CLAUDE.md albo doprecyzowanie promptu.

Setup zajmuje kilka minut. Reszta to czytanie własnych trace'ów.

Źródła

Treść zweryfikowana względem oficjalnej dokumentacji i repozytoriów obu projektów. Stan na 28 lipca 2026.

1. LangSmith, Trace Claude Code (instalacja pluginu, zmienne, GitHub Actions, repliki, zagnieżdżanie, ograniczenie dotyczące subagentów) - https://docs.langchain.com/langsmith/trace-claude-code
2. Repozytorium langchain-ai/langsmith-claude-code-plugins (pełna lista zmiennych, redakcja sekretów, metadane tożsamości, licencja MIT) - https://github.com/langchain-ai/langsmith-claude-code-plugins
3. LangChain, „Trace Claude Code applications in LangSmith” (materiał wideo, widok trace i zakładka Threads) - https://www.youtube.com/watch?v=jLOM_ahG78c
4. Langfuse, Claude Code integration (setup ręczny i pluginowy, struktura trace, regiony, zarządzanie stanem, troubleshooting) - https://langfuse.com/integrations/developer-tools/claude-code
5. Repozytorium langfuse/Claude-Observability-Plugin (instalacja, konfiguracja przez keychain, hooki Stop i SessionEnd, ograniczenia GUI, licencja MIT) - https://github.com/langfuse/Claude-Observability-Plugin
6. Langfuse, „Trace Claude Code” (materiał wideo, model mentalny hooka, typowe patologie w trace, cztery punkty troubleshootingu) - https://www.youtube.com/watch?v=fsoBHf_WNmQ
7. LangSmith, plany i cennik (Developer, Plus, Enterprise, retencja trace'ów) - https://www.langchain.com/pricing-langsmith
8. Langfuse, cennik (Hobby, Core, Pro, Enterprise, self-hosting) - https://langfuse.com/pricing
9. Claude Code, dokumentacja hooków (punkty cyklu życia sesji, w tym Stop) - https://code.claude.com/docs/en/hooks-guide
10. Claude Code, dokumentacja ustawień (zakresy plików ustawień, kolejność precedencji, klucz env) - https://code.claude.com/docs/en/settings
11. Claude Code, Discover and install plugins (komendy /plugin marketplace add, /plugin install nazwa@marketplace, /reload-plugins oraz ich odpowiedniki claude plugin ... w shellu) - https://code.claude.com/docs/en/discover-plugins
12. LangSmith, Create an account and API key (adresy API dla regionów GCP US, GCP EU, GCP APAC i AWS US, domyślna wartość LANGSMITH_ENDPOINT) - https://docs.langchain.com/langsmith/create-account-api-key