Uwierzytelnianie Claude API: Anthropic, Bedrock, Vertex

Cztery ścieżki uwierzytelniania w Claude API

Uwierzytelnianie w Claude API sprowadza się do jednej decyzji: jakich danych uwierzytelniających użyje klient w przesyłanym żądaniu. Istnieją cztery rozwiązania i nie są one wariantami tego samego mechanizmu. Bezpośrednie API Anthropic przesyła statyczny klucz w nagłówku x-api-key. Amazon Bedrock podpisuje każde żądanie za pomocą danych uwierzytelniających AWS i w tej konfiguracji klucz Anthropic nie występuje. Google Cloud przesyła krótkotrwały token dostępu Google. Microsoft Foundry wymaga klucza wydanego przez Azure lub tokena Microsoft Entra.

Niniejszy przewodnik dotyczy integracji SDK (software development kit) z usługą działającą na serwerze Linux. Jeśli konfigurujesz narzędzie wiersza poleceń Claude Code, zmienne i przebieg procesu są inne: zobacz wskazywanie Claude Code na Bedrock lub Vertex. Jeśli usługa jeszcze nie istnieje, zbuduj ją najpierw zgodnie z pierwsza aplikacja Claude API na VPS i wróć tutaj po dane uwierzytelniające.

Wszystkie poniższe informacje zostały zweryfikowane z dokumentacją platformy Anthropic w sierpniu 2026 roku. Identyfikatory modeli, ceny, wersje SDK oraz struktura punktów końcowych ulegają zmianom, dlatego niniejszy przewodnik odsyła do stron dostawców zamiast podawać wartości, które mogą stać się nieaktualne.

Ścieżka 1: klucz API Anthropic

Jest to bezpośrednia metoda i jedyna, w której Anthropic wydaje sekret. Żądania trafiają do punktu końcowego Messages na hoście API Anthropic, a każde żądanie zawiera trzy nagłówki.

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "MODEL_ID", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

Zastąp MODEL_ID aktualnym identyfikatorem z przeglądu modeli Anthropic. Prawidłowa odpowiedź to JSON zawierający tablicę content oraz obiekt usage. Błędny lub wygasły klucz zwraca kod HTTP 401 wraz z authentication_error. Brak nagłówka anthropic-version stanowi odrębną przyczynę niepowodzenia, ponieważ nagłówek ten jest wymagany w każdym żądaniu; zestawy SDK ustawiają go automatycznie.

Konstrukcja klienta jest najkrótsza z czterech omawianych, ponieważ nie wymaga żadnej konfiguracji. Każdy oficjalny SDK samodzielnie odczytuje ANTHROPIC_API_KEY ze środowiska.

import os
from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

message = client.messages.create(
    model=os.environ["CLAUDE_MODEL"],
    max_tokens=64,
    messages=[{"role": "user", "content": "Hello"}],
)
print(message.usage)

Warto przechowywać identyfikator modelu w środowisku obok klucza. Nazwy modeli zmieniają się zgodnie z harmonogramem, na który użytkownik nie ma wpływu, a ponowne wdrażanie kodu w celu edycji jednego ciągu znaków jest zbędnym nakładem pracy.

Klucze tworzy się w konsoli, gdzie w momencie generowania wybiera się czas wygaśnięcia: ustawienia predefiniowane na 3 godziny, 1 dzień, 7 dni lub 30 dni, czas niestandardowy albo opcję Nigdy. Czas wygaśnięcia jest ustalany w momencie tworzenia i nie można go później zmienić. Anthropic wysyła powiadomienie e-mail do twórcy klucza przed wygaśnięciem klucza długoterminowego, jednak klucz o krótkim okresie ważności wygasa bez żadnego ostrzeżenia. Wygasły klucz zwraca błąd 401 i nie może zostać reaktywowany, dlatego jedynym rozwiązaniem jest wygenerowanie nowego klucza.

W przypadku bezpośredniego API nie wybiera się regionu, a rozliczenia trafiają bezpośrednio do organizacji Anthropic. Obszary robocze (Workspaces) ograniczają zakres klucza do jednego projektu, co stanowi najbardziej przejrzysty sposób monitorowania wydatków pojedynczej usługi. Informacje na temat obliczeń stojących za tymi kosztami znajdują się w sekcji porównanie cen API za token względem subskrypcji.

W tym miejscu należy wspomnieć o jeszcze jednej opcji, ponieważ całkowicie eliminuje ona statyczny sekret. Workload Identity Federation pozwala obciążeniu wymienić token OpenID Connect (OIDC) od zaufanego dostawcy tożsamości na krótkotrwały token Anthropic pod adresem POST /v1/oauth/token, a SDK odświeża ten token przed jego wygaśnięciem. Żaden ciąg znaków sk-ant-api... nie jest nigdzie tworzony ani kopiowany. Rozwiązanie to pasuje do Kubernetes, GitHub Actions oraz maszyn wirtualnych w chmurze, które posiadają już tożsamość platformową. Zwykły VPS zazwyczaj nie posiada takiego wystawcy, więc w takim przypadku klucz API w pliku jest najbardziej praktycznym rozwiązaniem, a dalsza część tego przewodnika zakłada właśnie taki scenariusz.

Metoda 2: Poświadczenia AWS w Amazon Bedrock

W usłudze Bedrock nie przechowuje się żadnego klucza Anthropic. Zestaw SDK podpisuje każde żądanie HTTP przy użyciu AWS Signature Version 4 (SigV4) za pomocą standardowych poświadczeń AWS, a AWS decyduje, czy dany podmiot może wywołać model.

pip install -U "anthropic[bedrock]"
aws sts get-caller-identity

aws sts get-caller-identity wyświetla numer konta oraz ARN (Amazon Resource Name) tożsamości, do której przypisane są poświadczenia. Uruchom to polecenie przed innymi czynnościami. Jeśli zakończy się niepowodzeniem, wywołanie Claude również się nie powiedzie, ponieważ SDK korzysta z tego samego łańcucha: najpierw argumenty konstruktora, następnie zmienne środowiskowe AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN i AWS_REGION, potem plik konfiguracyjny AWS oraz reszta standardowego łańcucha (SSO, role typu assumed, rola zadania ECS, usługa metadanych instancji).

W konstrukcji klienta zmienia się klasa oraz jeden argument.

from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="us-east-1")

Region przestaje być tutaj jedynie dekoracją. Punkty końcowe Bedrock są przypisane do regionów, dostęp do modeli przyznaje się w konsoli AWS dla każdego regionu z osobna, a region jest częścią podpisu SigV4, więc podpis obliczony dla jednego regionu zostanie odrzucony przez inny. Ustaw AWS_REGION jawnie w środowisku usługi. Anthropic dokumentuje, że klient AnthropicBedrock odczytuje AWS_REGION i korzysta z us-east-1, gdy zmienna nie jest ustawiona, oraz że nie odczytuje ~/.aws/config w celu określenia regionu. Dlatego AWS CLI może z powodzeniem wyświetlić listę modeli Claude na tej samej maszynie, na której proces Python kończy się błędem: CLI odczytało plik konfiguracyjny, a klient nie.

Na instancji EC2 przypisuje się rolę IAM (identity and access management) i żaden sekret nie trafia na dysk, ponieważ usługa metadanych instancji przekazuje do SDK tymczasowe poświadczenia. Serwer VPS poza AWS nie posiada ani roli instancji, ani usługi metadanych. Wybór sprowadza się wtedy do długoterminowej pary kluczy dostępu użytkownika IAM przechowywanej na maszynie, co stanowi tę samą klasę sekretu co klucz Anthropic, albo do federacji: uwierzytelnienia u dostawcy tożsamości, wywołania AWS STS (security token service) i użycia zwróconych tymczasowych poświadczeń. Bedrock akceptuje również token bearer poprzez AWS_BEARER_TOKEN_BEDROCK, udokumentowany z limitem 12 godzin i opisany przez AWS jako najmniej zalecana ścieżka.

Rachunek trafia na konto AWS, a nie do Anthropic, co zazwyczaj jest głównym powodem wyboru tego rozwiązania. Regionalne punkty końcowe wiążą się z 10% narzutem w stosunku do punktu końcowego globalnego, zgodnie z dokumentacją z sierpnia 2026. Jeden błąd Bedrock warto rozpoznać, ponieważ wygląda jak problem z uprawnieniami, a nim nie jest: Invocation of model ID ... with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model.. Jest to błąd routingu modelu i żadna zmiana poświadczeń go nie naprawi.

Ścieżka 3: Poświadczenia Google w Vertex AI

Google Cloud korzysta z mechanizmu Application Default Credentials (ADC), czyli ustalonej kolejności wyszukiwania, według której biblioteki uwierzytelniające Google odnajdują poświadczenia bez konieczności ich jawnego wskazywania. ADC sprawdza najpierw GOOGLE_APPLICATION_CREDENTIALS, następnie plik zapisany przez gcloud auth application-default login, a na końcu konto serwisowe przypisane przez serwer metadanych.

pip install -U "anthropic[vertex]"
gcloud auth application-default login

Na stacji roboczej logowanie zapisuje $HOME/.config/gcloud/application_default_credentials.json i proces jest zakończony. Na serwerze jest to niewłaściwe narzędzie, ponieważ przechowywane poświadczenia należą do konkretnej osoby i wygasają wraz z jej kontem. Poza Google Cloud nie ma również serwera metadanych, więc ADC przechodzi do GOOGLE_APPLICATION_CREDENTIALS wskazującego na plik klucza konta serwisowego. Ten plik JSON jest długoterminowym sekretem i wymaga obsługi dokładnie opisanej w dalszej części tego przewodnika. Wewnątrz Google Cloud należy przypisać konto serwisowe do maszyny wirtualnej, co eliminuje potrzebę ochrony jakiegokolwiek pliku.

from anthropic import AnthropicVertex

client = AnthropicVertex(project_id="my-project", region="global")

Dwie rzeczy zmieniają się, jeśli zrezygnujesz z SDK na rzecz bezpośrednich żądań HTTP. Identyfikator modelu przenosi się z treści żądania do ścieżki URL, a anthropic_version przenosi się z nagłówka do treści, gdzie musi przyjąć wartość vertex-2023-10-16. Poświadczeniem jest standardowy token dostępu Google.

curl https://aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/publishers/anthropic/models/${MODEL_ID}:rawPredict \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{"anthropic_version": "vertex-2023-10-16", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

Region jest argumentem pierwszorzędnym. global kieruje ruch dynamicznie w celu zapewnienia dostępności, us oraz eu to identyfikatory wieloregionalne, a nazwa taka jak us-east5 przypina usługę do pojedynczego regionu. Punkty końcowe wieloregionalne i regionalne kosztują o 10% więcej niż globalne, zgodnie z dokumentacją z sierpnia 2026. Rozliczenia odbywają się w ramach projektu Google Cloud, więc limity oraz faktury są zarządzane przez Google.

Ścieżka 4: Microsoft Foundry to ścieżka Azure

Jeśli poszukiwano Claude w środowisku Azure, to jest to właściwa sekcja, ponieważ obsługiwana ścieżka istnieje. Claude działa w Microsoft Foundry (wcześniej Azure AI Foundry), a rozliczenia odbywają się poprzez Azure Marketplace w jednostkach Claude Consumption Units. Należy utworzyć zasób Foundry, wdrożyć w nim model Claude i wywołać punkt końcowy hostowany w Azure pod adresem https://{resource}.services.ai.azure.com/anthropic/v1/*.

Działają dwa rodzaje poświadczeń. Pierwszym jest klucz wydany przez Azure, dostępny w zakładce Details wdrożenia w portalu Foundry, przesyłany w nagłówku api-key lub x-api-key. Drugim jest token Microsoft Entra, co stanowi lepszy wybór na serwerze, ponieważ kontrola dostępu oparta na rolach (RBAC) w Azure zarządza wówczas uprawnieniami do wywoływania punktu końcowego.

ACCESS_TOKEN=$(az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv)

curl https://${RESOURCE}.services.ai.azure.com/anthropic/v1/messages \
  -H "content-type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model": "DEPLOYMENT_NAME", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

Pole model zawiera nazwę wdrożenia, a nie identyfikator modelu. Domyślnie obie wartości są zgodne, jednak przestają być takie w momencie nadania własnej nazwy wdrożeniu, co jest najczęstszą przyczyną błędu Deployment not found przy poprawnie sformułowanym żądaniu. Zestawy SDK dla języków Python i TypeScript odczytują zmienne ANTHROPIC_FOUNDRY_API_KEY oraz ANTHROPIC_FOUNDRY_RESOURCE ze środowiska. Obsługa Foundry nie jest dostępna w każdym SDK: według stanu na sierpień 2026 obejmuje ona C#, Java, PHP, Python oraz TypeScript, podczas gdy zestawy SDK dla Go i Ruby wymagają użycia ogólnego klienta skierowanego na bazowy adres URL Foundry.

To obejście posiada istotne ograniczenie. Jeśli zmienna ANTHROPIC_API_KEY jest nadal ustawiona w środowisku, ogólny klient pobierze ją i prześle klucz Anthropic do punktu końcowego Microsoft. Należy usunąć tę zmienną lub wyłączyć domyślne ustawienia środowiskowe w kliencie. Tokeny Entra wygasają po około godzinie, dlatego procesy działające długotrwale muszą je odświeżać, zamiast pobierać jeden raz przy starcie.

Jak długo ważne są poświadczenia na serwerze?

[
  {
    "label": "Anthropic key, 30-day preset",
    "max_lifetime_hours": 720
  },
  {
    "label": "Anthropic key, 7-day preset",
    "max_lifetime_hours": 168
  },
  {
    "label": "AWS STS assumed role",
    "max_lifetime_hours": 12
  },
  {
    "label": "Bedrock bearer token",
    "max_lifetime_hours": 12
  },
  {
    "label": "Entra ID access token",
    "max_lifetime_hours": 1
  },
  {
    "label": "Federated Anthropic token",
    "max_lifetime_hours": 1
  }
]

Są to limity i wartości domyślne opublikowane przez poszczególnych dostawców, odczytane w sierpniu 2026 roku; nie są to wartości zmierzone. Mają one znaczenie z jednego powodu: określają, jak długo wyciekłe poświadczenie pozostaje aktywne w czasie, gdy administrator wciąż ustala fakt wystąpienia wycieku. Tokeny krótkotrwałe znajdujące się na dole zestawienia są ważne przez 1 godzin każdy, a SDK odświeża je automatycznie, więc krótki czas życia nie generuje kosztów operacyjnych. Przyjęta rola (assumed role) jest ważna przez 12 godziny. Klucz utworzony z ustawieniem wstępnym na 30 dni pozostaje ważny przez 720 godzin i jest to poświadczenie, które pozostaje w pliku na serwerze przez miesiąc.

Where the credential lives on a VPS

Put the secret in a file only root can read, and let systemd hand it to the process. This part outlives every SDK version, so it is worth doing once and properly.

sudo useradd --system --home /opt/claude-app --shell /usr/sbin/nologin claudeapp
sudo install -d -m 700 -o root -g root /etc/claude-app
sudo install -m 600 -o root -g root /dev/null /etc/claude-app/env
sudoedit /etc/claude-app/env

The file holds plain KEY=value lines. No export, no quotes, no shell syntax, because systemd parses it itself rather than running it through a shell.

ANTHROPIC_API_KEY=sk-ant-api03-REPLACE-ME
CLAUDE_MODEL=REPLACE-ME

[Unit]
Description=Claude API service
After=network-online.target

[Service]
User=claudeapp
EnvironmentFile=/etc/claude-app/env
ExecStart=/opt/claude-app/venv/bin/python -m claude_app
Restart=on-failure

[Install]
WantedBy=multi-user.target

systemd reads EnvironmentFile= as root, before it drops to User=claudeapp, so the service account never needs read access to the file. Mode 600 owned by root is enough, which is why the install command above sets it that way. Start it with sudo systemctl enable --now claude-app, then confirm with systemctl status claude-app that the unit reached active (running) rather than restarting in a loop.

Four things to avoid, each for a reason you can check yourself:

• Do not write the key with Environment= inside the unit file. A unit under /etc/systemd/system is world readable, so systemctl cat claude-app prints the secret back to any local user.
• Do not commit it. .gitignore keeps a new file out of a commit and does nothing about a file already committed, because git history keeps whatever it was given.
• Do not bake it into a container image. ENV lines and --build-arg values are recorded in the image layers, and docker history --no-trunc prints them back. Deleting the file in a later layer does not remove it from the earlier one. Pass secrets at run time with --env-file or a mounted file instead.
• Do not treat the process environment as private from root. sudo tr '\\0' '\\n' < /proc/$(pgrep -u claudeapp -f claude_app | head -1)/environ prints the key back. The goal is to keep the secret away from every other account on the box, not from root, who can read it whatever you do.

That last point sets the boundary of what this design buys you. An environment variable is a fine container for a secret when the only things that can read it are the service and root. It is the wrong container when the process runs code you did not write, because anything the process can execute can read its own environment. Keeping secrets out of an AI agent's reach covers that case, which is a different problem with a different answer.

Jak przeprowadzić rotację klucza bez przestojów?

Wykonaj rotację w przód, a następnie unieważnij poprzedni klucz.

1. Utwórz nowy klucz w konsoli, w tym samym obszarze roboczym co stary.
2. Zapisz go w /etc/claude-app/env za pomocą sudoedit.
3. Uruchom sudo systemctl restart claude-app.
4. Potwierdź, że usługa odpowiada na żądania, a następnie unieważnij stary klucz w konsoli.

Plik EnvironmentFile jest odczytywany podczas uruchamiania jednostki, więc działający proces zachowuje wartość przypisaną w momencie startu. Polecenie systemctl daemon-reload ponownie wczytuje pliki jednostek, ale nie zmienia środowiska działającego procesu, dlatego dopiero restart wymusza użycie nowego klucza. Unieważnienie klucza w kroku 1 zamiast w kroku 4 spowoduje przerwę w działaniu usługi, która potrwa do momentu wykonania kroku 3.

Pozostałe trzy metody rotacji odbywają się po stronie dostawcy. Użytkownik IAM obsługuje dwa aktywne klucze dostępu jednocześnie, więc należy utworzyć drugi, wdrożyć go, a następnie usunąć pierwszy. Klucz konta serwisowego Google rotuje w ten sam sposób. Klucz Foundry jest generowany ponownie w portalu, co natychmiast unieważnia stary, dlatego nową wartość należy zapisać przed kliknięciem. Tokeny Entra oraz federacyjne tokeny Anthropic nie wymagają rotacji, co stanowi najsilniejszy argument za ich stosowaniem, gdzie tylko jest to możliwe.

Podczas pracy w konsoli ustaw limit wydatków dla obszaru roboczego. Wyciek klucza generuje koszty, zanim stanie się jakimkolwiek innym problemem, a ograniczanie wydatków agenta na VPS zawiera szczegółowy opis dostępnych mechanizmów kontroli.

Dlaczego klient zwraca błąd 401 lub 403?

Błąd 401 z authentication_error w bezpośrednim API. Klucz jest nieprawidłowy, unieważniony lub wygasł. Data wygaśnięcia jest często pomijana, ponieważ kod nie uległ zmianie, a żądanie działało poprzedniego dnia. Należy sprawdzić kolumnę daty wygaśnięcia klucza w konsoli lub odczytać expires_at z Admin API, gdzie wartość null oznacza klucze bez daty wygaśnięcia.

SDK ignoruje konfigurację federacji i używa klucza. ANTHROPIC_API_KEY oraz ANTHROPIC_AUTH_TOKEN znajdują się wyżej w hierarchii ważności poświadczeń niż federacja, więc każda z tych wartości ją przesłania. Częstym błędem jest sytuacja, w której zmienna wyeksportowana jako pusty ciąg znaków nadal zajmuje swoje miejsce, przez co ANTHROPIC_API_KEY="" powoduje, że SDK uwierzytelnia się za pomocą pustego klucza, zamiast przejść do kolejnej metody. Należy użyć unset ANTHROPIC_API_KEY.

Błąd 401 z komunikatem Authentication failed w federacji. Komunikat ten jest celowo identyczny dla każdej możliwej przyczyny, aby osoba wywołująca nie mogła badać konfiguracji reguł poprzez analizę treści błędu. Rzeczywista przyczyna jest zapisana na stronie historii uwierzytelniania w konsoli. Należy zacząć od tego miejsca, zamiast zgadywać zawartość JWT.

Błąd 403 w Foundry. Token został uwierzytelniony, ale konto Azure nie posiada roli zezwalającej na wykonanie wywołania. Należy przypisać rolę Azure RBAC, taką jak Foundry User (wcześniej Azure AI User) lub Cognitive Services User, do tożsamości wykonującej żądanie.

Problemy z Bedrock. Należy najpierw uruchomić aws sts get-caller-identity jako użytkownik usługi. Pozwala to ustalić, czy serwer posiada poprawne poświadczenia AWS, co pozwala odróżnić problem z poświadczeniami od problemu z dostępem do modelu lub niedopasowaniem regionu. Dostęp do modelu jest przyznawany dla każdego regionu z osobna w konsoli AWS i łatwo jest włączyć go w jednym regionie, próbując jednocześnie wywołać inny.

FAQ

Czy do korzystania z Claude w ramach Bedrock lub Vertex wymagany jest klucz API Anthropic?

Nie. W usłudze Amazon Bedrock zestaw SDK podpisuje każde żądanie przy użyciu poświadczeń AWS w standardzie SigV4, natomiast w Google Cloud wysyłany jest token dostępu Google pobierany za pośrednictwem Application Default Credentials. W żadnej z tych konfiguracji nie występuje klucz tajny wydany przez Anthropic, a opłaty za użycie są naliczane na konto chmurowe, a nie bezpośrednio w Anthropic. Z tego powodu pozostawienie klucza Anthropic w ANTHROPIC_API_KEY na tych hostach stanowi zagrożenie: ogólny klient skierowany na punkt końcowy chmury prześle go tam bez weryfikacji.

Czy Claude jest dostępny w Azure?

Tak, za pośrednictwem Microsoft Foundry, dawniej znanej jako Azure AI Foundry. Należy utworzyć zasób Foundry, wdrożyć w nim model Claude i wywołać https://{resource}.services.ai.azure.com/anthropic/v1/messages przy użyciu klucza wydanego przez Azure w nagłówku api-key lub tokena typu bearer z Microsoft Entra. Opłaty za użycie są naliczane przez Azure Marketplace w jednostkach Claude Consumption Units. Pole model w treści żądania musi zawierać nazwę wdrożenia, która jest identyczna z identyfikatorem modelu tylko do momentu zmiany nazwy wdrożenia.

Gdzie na serwerze z systemem Linux należy przechowywać klucz API Claude?

W pliku należącym do użytkownika root z uprawnieniami 600, wczytywanym przez EnvironmentFile= w jednostce systemd. Systemd odczytuje ten plik jako root przed przełączeniem na użytkownika User= zdefiniowanego w jednostce, dzięki czemu konto usługi nie potrzebuje do niego dostępu. Klucza nie należy umieszczać w repozytorium, w samym pliku jednostki (który jest dostępny do odczytu dla wszystkich i wyświetlany przez systemctl cat) ani w warstwach obrazu kontenera, ponieważ docker history --no-trunc wyświetla wszystkie zmienne ustawione za pomocą ENV lub --build-arg.

Dlaczego żądanie API Claude zaczęło zwracać błąd 401, mimo że konfiguracja nie uległa zmianie?

Najczęstszą przyczyną jest wygaśnięcie klucza, którego termin ważności został określony w momencie tworzenia. Termin ważności ustala się przy tworzeniu, nie można go później edytować, a klucze krótkoterminowe wygasają bez powiadomienia e-mail. Wygasłego klucza nie można reaktywować, dlatego należy utworzyć nowy, zapisać go w pliku środowiskowym, zrestartować usługę, a następnie unieważnić stary klucz. Jeśli klucz jest z pewnością aktualny, należy sprawdzić, czy nie jest przesłaniany przez przestarzałe poświadczenie: zmienna ANTHROPIC_API_KEY ustawiona na pusty ciąg znaków nadal ma pierwszeństwo przed każdym innym źródłem poświadczeń.