Claude API অথেনটিকেশন: চার ধরনের সেটআপ গাইড

Claude API অথেনটিকেশনের চারটি রুট

Claude API অথেনটিকেশনের বিষয়টি একটি সিদ্ধান্তের ওপর নির্ভর করে: আপনার ক্লায়েন্ট কোন ক্রেডেনশিয়ালটি নেটওয়ার্কে পাঠাবে। এর চারটি উত্তর রয়েছে এবং এগুলো একই মেকানিজমের ভিন্ন রূপ নয়। সরাসরি Anthropic API একটি স্ট্যাটিক কি (key) একটি x-api-key হেডারে পাঠায়। Amazon Bedrock প্রতিটি রিকোয়েস্টকে AWS ক্রেডেনশিয়াল দিয়ে সাইন করে এবং এই সেটআপে কোনো Anthropic কি-এর অস্তিত্ব নেই। Google Cloud একটি স্বল্পমেয়াদী Google অ্যাক্সেস টোকেন পাঠায়। Microsoft Foundry একটি Azure-প্রদত্ত কি অথবা একটি Microsoft Entra টোকেন গ্রহণ করে।

এই গাইডটি একটি Linux সার্ভারে চলমান সার্ভিসে একটি SDK (software development kit) যুক্ত করার জন্য। আপনি যদি পরিবর্তে Claude Code কমান্ড লাইন টুল কনফিগার করেন, তবে ভেরিয়েবল এবং প্রবাহ ভিন্ন হবে: দেখুন Claude Code-কে Bedrock বা Vertex-এর দিকে নির্দেশ করা। যদি সার্ভিসটি এখনো তৈরি না হয়ে থাকে, তবে প্রথমে একটি VPS-এ প্রথম Claude API অ্যাপ তৈরি করুন এবং ক্রেডেনশিয়ালের জন্য এখানে ফিরে আসুন।

নিচের সবকিছু আগস্ট 2026 সালে Anthropic-এর প্ল্যাটফর্ম ডকুমেন্টেশনের সাথে যাচাই করা হয়েছে। মডেল আইডেন্টিফায়ার, মূল্য, SDK ভার্সন এবং এন্ডপয়েন্টের গঠন পরিবর্তনশীল, তাই এই গাইডটি সেই মানগুলো প্রিন্ট করার পরিবর্তে প্রোভাইডার পেজের লিঙ্ক প্রদান করে, যা পুরনো হয়ে যেতে পারে।

রুট 1: একটি Anthropic API key

এটি সরাসরি পথ এবং একমাত্র উপায় যেখানে Anthropic গোপন কী (secret) প্রদান করে। অনুরোধগুলো Anthropic-এর API host-এর Messages endpoint-এ যায় এবং প্রতিটি অনুরোধে তিনটি হেডার থাকে।

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"}]}'

MODEL_ID-কে Anthropic-এর models overview থেকে একটি বর্তমান আইডেন্টিফায়ার দিয়ে প্রতিস্থাপন করুন। একটি সঠিক রেসপন্স হলো JSON, যাতে একটি content অ্যারে এবং একটি usage অবজেক্ট থাকে। ভুল বা মেয়াদোত্তীর্ণ কী-এর ক্ষেত্রে HTTP 401 এবং authentication_error ত্রুটি দেখাবে। একটি অনুপস্থিত anthropic-version হেডার আলাদা ব্যর্থতার কারণ, কারণ প্রতিটি অনুরোধে এই হেডারটি থাকা বাধ্যতামূলক; SDK-গুলো আপনার জন্য এটি সেট করে দেয়।

চারটি পদ্ধতির মধ্যে ক্লায়েন্ট তৈরি করা এখানে সবচেয়ে সহজ, কারণ এখানে তৈরি করার মতো কিছু নেই। প্রতিটি অফিসিয়াল SDK স্বয়ংক্রিয়ভাবে এনভায়রনমেন্ট থেকে ANTHROPIC_API_KEY পড়ে নেয়।

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)

কী-এর পাশাপাশি মডেল আইডেন্টিফায়ারটিকেও এনভায়রনমেন্টে রাখা ভালো। মডেলের নামগুলো এমন একটি সময়সূচী অনুযায়ী পরিবর্তিত হয় যা আপনার নিয়ন্ত্রণে নেই, তাই শুধুমাত্র একটি স্ট্রিং পরিবর্তনের জন্য কোড পুনরায় ডেপ্লয় করা এড়ানো উচিত।

কীগুলো কনসোল থেকে তৈরি করা হয়, যেখানে তৈরির সময় আপনি এর মেয়াদ নির্ধারণ করেন: 3 ঘণ্টা, 1 দিন, 7 দিন বা 30 দিনের প্রিসেট, একটি কাস্টম সময়কাল অথবা Never। মেয়াদ তৈরির সময় নির্ধারিত হয় এবং পরবর্তীতে তা পরিবর্তন করা যায় না। দীর্ঘমেয়াদী কী-এর মেয়াদ শেষ হওয়ার আগে Anthropic কী-এর নির্মাতাকে ইমেইল পাঠায়, কিন্তু স্বল্পমেয়াদী কী-এর ক্ষেত্রে কোনো সতর্কবার্তা ছাড়াই মেয়াদ শেষ হয়ে যায়। মেয়াদোত্তীর্ণ কী 401 ত্রুটি দেয় এবং এটি পুনরায় সক্রিয় করা যায় না, তাই সমাধান হিসেবে সবসময় নতুন কী তৈরি করতে হয়।

সরাসরি API-এর ক্ষেত্রে কোনো অঞ্চল (region) নির্বাচন করতে হয় না এবং বিল সরাসরি আপনার Anthropic অর্গানাইজেশনে জমা হয়। ওয়ার্কস্পেসের মাধ্যমে একটি কী-কে নির্দিষ্ট প্রজেক্টের আওতায় আনা যায়, যা একটি একক সার্ভিসের খরচ দেখার সবচেয়ে পরিষ্কার উপায়। সেই বিলের হিসাবের জন্য দেখুন how per-token API pricing compares against a subscription।

এখানে আরও একটি বিকল্প উল্লেখ করা প্রয়োজন, কারণ এটি স্ট্যাটিক সিক্রেটকে পুরোপুরি সরিয়ে ফেলে। Workload Identity Federation-এর মাধ্যমে একটি ওয়ার্কলোড আপনার বিশ্বস্ত কোনো আইডেন্টিটি প্রোভাইডার থেকে প্রাপ্ত OpenID Connect (OIDC) টোকেনকে POST /v1/oauth/token-এ একটি স্বল্পমেয়াদী Anthropic টোকেনের বিনিময়ে ব্যবহার করতে পারে এবং SDK মেয়াদ শেষ হওয়ার আগেই সেই টোকেন রিফ্রেশ করে নেয়। এতে কোনো sk-ant-api... স্ট্রিং তৈরি বা কপি করার প্রয়োজন হয় না। এটি Kubernetes, GitHub Actions এবং ক্লাউড VM-এর জন্য উপযুক্ত, যেগুলোতে আগে থেকেই প্ল্যাটফর্ম আইডেন্টিটি থাকে। একটি সাধারণ VPS-এ সাধারণত এমন কোনো ইস্যুয়ার থাকে না, তাই সেই বক্সে ফাইলে রাখা API key-ই হলো বাস্তবসম্মত সমাধান এবং এই গাইডের বাকি অংশ সেভাবেই আলোচনা করা হয়েছে।

রুট 2: Amazon Bedrock-এ AWS ক্রেডেনশিয়াল

Bedrock-এ আপনার কোনো Anthropic কী রাখার প্রয়োজন নেই। SDK প্রতিটি HTTP অনুরোধকে সাধারণ AWS ক্রেডেনশিয়াল ব্যবহার করে AWS Signature Version 4 (SigV4) দিয়ে সাইন করে এবং AWS সিদ্ধান্ত নেয় যে সেই কলার মডেলটি ইনভোক করতে পারবে কি না।

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

aws sts get-caller-identity আপনার ক্রেডেনশিয়াল যে আইডেন্টিটিকে নির্দেশ করে তার অ্যাকাউন্ট নম্বর এবং ARN (Amazon Resource Name) প্রিন্ট করে। অন্য কিছু করার আগে এটি চালান। যদি এটি ব্যর্থ হয়, তবে Claude কলটিও ব্যর্থ হবে, কারণ SDK একই চেইন অনুসরণ করে: প্রথমে কনস্ট্রাক্টর আর্গুমেন্ট, তারপর AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN এবং AWS_REGION এনভায়রনমেন্ট ভেরিয়েবল, তারপর AWS কনফিগ ফাইল এবং স্ট্যান্ডার্ড চেইনের বাকি অংশ (SSO, অ্যাজিউমড রোল, ECS টাস্ক রোল, ইনস্ট্যান্স মেটাডেটা সার্ভিস)।

ক্লায়েন্ট তৈরির ক্ষেত্রে ক্লাস এবং একটি আর্গুমেন্টের পরিবর্তন হয়।

from anthropic import AnthropicBedrock

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

এখানে Region কেবল সাজসজ্জার বিষয় নয়। Bedrock এন্ডপয়েন্টগুলো অঞ্চলভিত্তিক, AWS কনসোলে মডেল অ্যাক্সেস অঞ্চল অনুযায়ী প্রদান করা হয় এবং অঞ্চলটি SigV4 সিগনেচারের অংশ, তাই এক অঞ্চলের জন্য তৈরি সিগনেচার অন্য অঞ্চলে প্রত্যাখ্যাত হয়। সার্ভিস এনভায়রনমেন্টে স্পষ্টভাবে AWS_REGION সেট করুন। Anthropic-এর ডকুমেন্টেশন অনুযায়ী, AnthropicBedrock ক্লায়েন্ট AWS_REGION পড়ে এবং এটি সেট করা না থাকলে us-east-1-এ ফিরে যায়, এবং এটি অঞ্চলের জন্য ~/.aws/config পড়ে না। এই কারণেই AWS CLI একই বক্সে Claude মডেলগুলো সফলভাবে তালিকাভুক্ত করতে পারে যেখানে আপনার Python প্রসেস ব্যর্থ হয়: CLI আপনার কনফিগ ফাইলটি পড়েছে কিন্তু ক্লায়েন্টটি পড়েনি।

একটি EC2 ইনস্ট্যান্সে আপনি একটি IAM (identity and access management) রোল যুক্ত করেন এবং কোনো সিক্রেট ডিস্কে জমা হয় না, কারণ ইনস্ট্যান্স মেটাডেটা সার্ভিস SDK-কে অস্থায়ী ক্রেডেনশিয়াল প্রদান করে। AWS-এর বাইরের একটি VPS-এ ইনস্ট্যান্স রোল বা মেটাডেটা সার্ভিস কোনটিই থাকে না। সেক্ষেত্রে আপনাকে একটি IAM ইউজারের দীর্ঘস্থায়ী অ্যাক্সেস কী পেয়ার যা বক্সে রাখা থাকে (যা Anthropic কী-এর মতোই এক ধরনের সিক্রেট) অথবা ফেডারেশনের মধ্যে বেছে নিতে হবে: আপনার আইডেন্টিটি প্রোভাইডারের মাধ্যমে অথেন্টিকেট করুন, AWS STS (security token service) কল করুন এবং এটি যে অস্থায়ী ক্রেডেনশিয়াল দেয় তা ব্যবহার করুন। Bedrock AWS_BEARER_TOKEN_BEDROCK-এর মাধ্যমে বিয়ারার টোকেনও গ্রহণ করে, যার সর্বোচ্চ মেয়াদ 12 ঘণ্টা এবং AWS-এর মতে এটি সবচেয়ে কম পছন্দের উপায়।

বিলটি Anthropic-এর পরিবর্তে আপনার AWS অ্যাকাউন্টে জমা হয়, যা সাধারণত এখানে আসার মূল কারণ। আগস্ট 2026-এর ডকুমেন্টেশন অনুযায়ী, গ্লোবাল এন্ডপয়েন্টের তুলনায় রিজিওনাল এন্ডপয়েন্টগুলোতে 10% বেশি খরচ হয়। Bedrock-এর একটি এরর চিনে রাখা জরুরি কারণ এটি দেখতে পারমিশন সমস্যার মতো মনে হলেও আসলে তা নয়: 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. এটি মডেল রাউটিং সংক্রান্ত সমস্যা এবং ক্রেডেনশিয়াল পরিবর্তন করে এটি ঠিক করা সম্ভব নয়।

রুট 3: Vertex AI-তে Google credentials

Google Cloud 'Application Default Credentials' (ADC) ব্যবহার করে। এটি একটি নির্দিষ্ট অনুসন্ধান ক্রম যা Google auth লাইব্রেরিগুলো কোনো নাম উল্লেখ না করেই credential খুঁজে পেতে অনুসরণ করে। ADC প্রথমে GOOGLE_APPLICATION_CREDENTIALS চেক করে, তারপর gcloud auth application-default login দ্বারা লেখা ফাইলটি, এবং সবশেষে metadata server-এর মাধ্যমে সংযুক্ত service account চেক করে।

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

একটি ওয়ার্কস্টেশনে লগইন করলে তা $HOME/.config/gcloud/application_default_credentials.json লেখে এবং আপনার কাজ শেষ হয়। সার্ভারে এটি ভুল টুল, কারণ এটি যে credential সংরক্ষণ করে তা একজন মানুষের এবং সেই ব্যক্তির অ্যাকাউন্টের সাথেই তার মেয়াদ শেষ হয়ে যায়। Google Cloud-এর বাইরে কোনো metadata server নেই, তাই ADC তখন GOOGLE_APPLICATION_CREDENTIALS-এ ফিরে আসে, যা একটি service account key ফাইলের দিকে নির্দেশ করে। সেই JSON ফাইলটি একটি দীর্ঘস্থায়ী গোপন তথ্য এবং এই গাইডের পরবর্তী অংশে বর্ণিত নিয়ম অনুযায়ীই তা পরিচালনা করতে হবে। Google Cloud-এর ভেতরে, একটি VM-এর সাথে service account সংযুক্ত করুন, তাহলে আর কোনো ফাইল সুরক্ষিত রাখার প্রয়োজন হবে না।

from anthropic import AnthropicVertex

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

আপনি যদি SDK থেকে সরাসরি raw HTTP-তে নেমে আসেন, তবে দুটি বিষয় পরিবর্তিত হয়। মডেল আইডেন্টিফায়ারটি request body থেকে সরে URL path-এ চলে যায় এবং anthropic_version হেডার থেকে সরে body-তে চলে আসে, যেখানে এটিকে অবশ্যই vertex-2023-10-16 হিসেবে পড়তে হবে। এই credential-টি একটি সাধারণ Google access token।

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 একটি অত্যন্ত গুরুত্বপূর্ণ আর্গুমেন্ট। global প্রাপ্যতার ভিত্তিতে ডাইনামিকভাবে রুট করে, us এবং eu হলো মাল্টি-রিজিয়ন আইডেন্টিফায়ার, এবং us-east5-এর মতো নাম একটি নির্দিষ্ট রিজিয়নকে নির্ধারণ করে দেয়। আগস্ট 2026-এর নথি অনুযায়ী, মাল্টি-রিজিয়ন এবং রিজিওনাল এন্ডপয়েন্টগুলোর খরচ গ্লোবাল এন্ডপয়েন্টের চেয়ে 10% বেশি। বিলিং Google Cloud প্রজেক্টের মাধ্যমে হয়, তাই কোটা এবং ইনভয়েস Google-এর নিয়মেই চলে।

রুট 4: Microsoft Foundry হলো Azure রুট

আপনি যদি Azure-এ Claude খুঁজে থাকেন, তবে এই অংশটি আপনার জন্য, এবং এখানে একটি সমর্থিত রুট বিদ্যমান। Claude চলে Microsoft Foundry-তে (যা আগে Azure AI Foundry নামে পরিচিত ছিল), যার বিলিং Azure Marketplace-এর মাধ্যমে Claude Consumption Units হিসেবে করা হয়। আপনাকে একটি Foundry রিসোর্স তৈরি করতে হবে, তার ভেতরে একটি Claude মডেল ডেপ্লয় করতে হবে এবং https://{resource}.services.ai.azure.com/anthropic/v1/*-এ থাকা Azure-হোস্টেড এন্ডপয়েন্ট কল করতে হবে।

দুটি ক্রেডেনশিয়াল কাজ করে। প্রথমটি হলো Foundry পোর্টালের ডেপ্লয়মেন্টের Details ট্যাব থেকে পাওয়া Azure-ইস্যুকৃত কি (key), যা api-key বা x-api-key হেডারে পাঠাতে হয়। দ্বিতীয়টি হলো Microsoft Entra টোকেন, যা সার্ভারের জন্য ভালো বিকল্প, কারণ সেক্ষেত্রে Azure role-based access control নির্ধারণ করে কারা এন্ডপয়েন্টটি কল করতে পারবে।

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"}]}'

model ফিল্ডে আপনার ডেপ্লয়মেন্টের নাম থাকে, মডেলের শনাক্তকারী (identifier) নয়। ডিফল্টভাবে এই দুটি একই থাকে, কিন্তু আপনি যখনই নিজের মতো করে কোনো ডেপ্লয়মেন্টের নাম দেন, তখন থেকেই এদের মিল থাকে না। এটিই সাধারণত একটি সঠিক অনুরোধের ক্ষেত্রে Deployment not found এরর হওয়ার মূল কারণ। Python এবং TypeScript SDK পরিবেশ থেকে ANTHROPIC_FOUNDRY_API_KEY এবং ANTHROPIC_FOUNDRY_RESOURCE পড়ে নেয়। Foundry সাপোর্ট সব SDK-তে নেই: আগস্ট 2026-এর ডকুমেন্টেশন অনুযায়ী এটি C#, Java, PHP, Python এবং TypeScript কভার করে, যেখানে Go এবং Ruby SDK-এর ক্ষেত্রে জেনেরিক ক্লায়েন্টকে Foundry বেস URL-এর দিকে নির্দেশ করতে হয়।

এই ওয়ার্কঅ্যারাউন্ডটির একটি ঝুঁকি আছে। যদি ANTHROPIC_API_KEY এনভায়রনমেন্টে সেট করা থাকে, তবে জেনেরিক ক্লায়েন্ট সেটি গ্রহণ করে এবং আপনার Anthropic কি Microsoft এন্ডপয়েন্টে পাঠিয়ে দেয়। ভেরিয়েবলটি আনসেট (unset) করুন অথবা ক্লায়েন্টে এনভায়রনমেন্ট ডিফল্ট নিষ্ক্রিয় করুন। Entra টোকেন প্রায় এক ঘণ্টা পর মেয়াদোত্তীর্ণ হয়ে যায়, তাই দীর্ঘ সময় ধরে চলা প্রসেসের ক্ষেত্রে শুরুতে একবার টোকেন ক্যাপচার না করে বরং তা রিফ্রেশ করতে হয়।

আপনার সার্ভারে ক্রেডেনশিয়াল কতক্ষণ সক্রিয় থাকে?

[
  {
    "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
  }
]

এগুলো প্রতিটি প্রোভাইডার কর্তৃক প্রকাশিত সর্বোচ্চ সীমা এবং ডিফল্ট মান, যা 2026 সালের আগস্ট মাসে সংগ্রহ করা হয়েছে; এগুলো সরাসরি পরিমাপ করা মান নয়। এগুলো একটি কারণে গুরুত্বপূর্ণ: এগুলো আপনাকে জানায় যে, কোনো ক্রেডেনশিয়াল ফাঁস হওয়ার পর আপনি তা শনাক্ত করার আগ পর্যন্ত সেটি কতক্ষণ কার্যকর থাকবে। তালিকার নিচের দিকে থাকা স্বল্পস্থায়ী টোকেনগুলো প্রতিটির মেয়াদ 1 ঘণ্টা এবং SDK স্বয়ংক্রিয়ভাবে সেগুলো রিফ্রেশ করে, তাই এই স্বল্পস্থায়ী মেয়াদ পরিচালনার ক্ষেত্রে আপনার কোনো বাড়তি কাজ করতে হয় না। একটি অ্যাজিউমড রোল (assumed role) 12 ঘণ্টা পর্যন্ত সক্রিয় থাকে। 30 দিনের প্রিসেট ব্যবহার করে তৈরি করা একটি কি (key) 720 ঘণ্টা পর্যন্ত কার্যকর থাকে এবং এটিই সেই ক্রেডেনশিয়াল যা এক মাস ধরে আপনার সার্ভারের একটি ফাইলে জমা থাকে।

VPS-এ ক্রেডেনশিয়াল যেখানে থাকে

সিক্রেটটিকে এমন একটি ফাইলে রাখুন যা শুধুমাত্র root পড়তে পারে এবং systemd-কে সেটি প্রসেসের কাছে পৌঁছে দিতে দিন। এই পদ্ধতিটি যেকোনো SDK ভার্সনের চেয়ে দীর্ঘস্থায়ী, তাই এটি একবার সঠিকভাবে করে রাখা ভালো।

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

ফাইলটিতে সাধারণ KEY=value লাইন থাকে। কোনো export, উদ্ধৃতি চিহ্ন বা শেল সিনট্যাক্স ব্যবহার করবেন না, কারণ systemd এটিকে শেলের মাধ্যমে না চালিয়ে নিজেই পার্স করে।

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 EnvironmentFile= ফাইলটিকে root হিসেবে পড়ে, এরপর এটি User=claudeapp-এ নেমে আসে, তাই সার্ভিস অ্যাকাউন্টের ফাইলটিতে রিড অ্যাক্সেসের প্রয়োজন হয় না। root-এর মালিকানাধীন Mode 600 যথেষ্ট, আর এজন্যই উপরের install কমান্ডটি এভাবে সেট করা হয়েছে। sudo systemctl enable --now claude-app দিয়ে এটি শুরু করুন, তারপর systemctl status claude-app দিয়ে নিশ্চিত করুন যে ইউনিটটি লুপে রিস্টার্ট না হয়ে active (running) অবস্থায় পৌঁছেছে।

চারটি বিষয় এড়িয়ে চলুন, যার প্রতিটির কারণ আপনি নিজেই যাচাই করতে পারবেন:

• ইউনিট ফাইলের ভেতরে Environment= দিয়ে কি (key) লিখবেন না। /etc/systemd/system-এর অধীনে থাকা ইউনিট ফাইল সবাই পড়তে পারে, তাই systemctl cat claude-app যেকোনো লোকাল ইউজারের কাছে সিক্রেটটি প্রকাশ করে দেবে।
• এটিকে কমিট করবেন না। .gitignore একটি নতুন ফাইলকে কমিট থেকে দূরে রাখে, কিন্তু ইতিমধ্যে কমিট করা ফাইলের ক্ষেত্রে এটি কাজ করে না, কারণ git হিস্ট্রি যা পেয়েছে তা ধরে রাখে।
• এটিকে কন্টেইনার ইমেজের ভেতরে ঢুকিয়ে দেবেন না। ENV লাইন এবং --build-arg ভ্যালু ইমেজের লেয়ারে রেকর্ড হয়ে থাকে এবং docker history --no-trunc সেগুলো প্রকাশ করে দেয়। পরবর্তী কোনো লেয়ারে ফাইলটি ডিলিট করলেও তা আগের লেয়ার থেকে মুছে যায় না। রানটাইমে --env-file বা মাউন্ট করা ফাইলের মাধ্যমে সিক্রেট পাস করুন।
• প্রসেস এনভায়রনমেন্টকে root-এর কাছ থেকে ব্যক্তিগত মনে করবেন না। sudo tr '\\0' '\\n' < /proc/$(pgrep -u claudeapp -f claude_app | head -1)/environ কি-টি প্রকাশ করে দেয়। লক্ষ্য হলো সিক্রেটটিকে বক্সের অন্য সব অ্যাকাউন্ট থেকে দূরে রাখা, root-এর কাছ থেকে নয়, কারণ আপনি যা-ই করুন না কেন root তা পড়তে পারবে।

শেষের পয়েন্টটি এই ডিজাইনের সীমাবদ্ধতা নির্ধারণ করে। যখন শুধুমাত্র সার্ভিস এবং root সিক্রেট পড়তে পারে, তখন এনভায়রনমেন্ট ভেরিয়েবল সিক্রেট রাখার জন্য একটি ভালো মাধ্যম। কিন্তু যখন প্রসেসটি এমন কোড চালায় যা আপনি লেখেননি, তখন এটি ভুল মাধ্যম, কারণ প্রসেস যা কিছু এক্সিকিউট করতে পারে তা তার নিজের এনভায়রনমেন্টও পড়তে পারে। AI এজেন্টের নাগাল থেকে সিক্রেট দূরে রাখা এই বিষয়টি নিয়ে আলোচনা করে, যা একটি ভিন্ন সমস্যা এবং এর সমাধানও ভিন্ন।

ডাউনটাইম ছাড়াই আমি কীভাবে কী (key) রোটেশন করব?

প্রথমে নতুন কী যুক্ত করুন, তারপর পুরনোটি বাতিল করুন।

1. কনসোলে পুরনো কী-এর একই ওয়ার্কস্পেসে নতুন কী তৈরি করুন।
2. /etc/claude-app/env-এ sudoedit ব্যবহার করে এটি লিখুন।
3. sudo systemctl restart claude-app চালান।
4. সার্ভিসটি অনুরোধ গ্রহণ করছে কি না তা নিশ্চিত করুন, তারপর কনসোল থেকে পুরনো কী-টি বাতিল (revoke) করুন।

ইউনিট শুরু হওয়ার সময় EnvironmentFile পড়া হয়, তাই চলমান প্রসেসটি লঞ্চের সময় প্রাপ্ত মানই ধরে রাখে। systemctl daemon-reload ইউনিট ফাইলগুলো পুনরায় পড়ে কিন্তু চলমান প্রসেসের এনভায়রনমেন্টে কোনো পরিবর্তন আনে না, তাই রিস্টার্ট না দেওয়া পর্যন্ত নতুন কী কার্যকর হয় না। ধাপ 4-এর পরিবর্তে ধাপ 1-এ বাতিল করলে ধাপ 3 পর্যন্ত আপনার সার্ভিস বন্ধ থাকবে।

অন্য তিনটি পদ্ধতি প্রোভাইডার লেভেলে রোটেশন সম্পন্ন করে। একটি IAM ইউজার একই সময়ে দুটি সক্রিয় অ্যাক্সেস কী সমর্থন করে, তাই দ্বিতীয়টি তৈরি করুন, সেটি ডেপ্লয় করুন এবং তারপর প্রথমটি মুছে ফেলুন। একটি Google সার্ভিস অ্যাকাউন্ট কী একইভাবে রোটেট করা যায়। একটি Foundry কী পোর্টালে পুনরায় তৈরি (regenerate) করতে হয়, যা পুরনোটিকে তাৎক্ষণিকভাবে অকার্যকর করে দেয়, তাই ক্লিক করার আগেই নতুন মানটি লিখে রাখুন। Entra টোকেন এবং ফেডারেল Anthropic টোকেনের ক্ষেত্রে কোনো রোটেশনের প্রয়োজন হয় না, এবং যেখানে সম্ভব এগুলো ব্যবহার করাই সবচেয়ে নিরাপদ।

কনসোলে থাকা অবস্থায় ওয়ার্কস্পেসের জন্য একটি খরচ সীমা (spend limit) নির্ধারণ করুন। একটি ফাঁস হওয়া কী বড় কোনো ক্ষতির আগেই অনেক ব্যয়বহুল হয়ে উঠতে পারে, এবং VPS-এ থাকা এজেন্টের খরচ সীমিত করা অংশে এই নিয়ন্ত্রণগুলো কীভাবে ব্যবহার করতে হয় তা বিস্তারিত আলোচনা করা হয়েছে।

আমার ক্লায়েন্ট কেন 401 বা 403 ত্রুটি দেখাচ্ছে?

সরাসরি API-তে authentication_error সহ 401 ত্রুটি। আপনার কী (key) ভুল, বাতিল করা হয়েছে অথবা এর মেয়াদ শেষ হয়ে গেছে। মেয়াদ শেষ হওয়ার বিষয়টি অনেকেই খেয়াল করেন না, কারণ কোড একই থাকে এবং আগের দিন পর্যন্ত অনুরোধটি সফলভাবে কাজ করছিল। কনসোলে কী-এর মেয়াদ শেষ হওয়ার কলামটি পরীক্ষা করুন অথবা Admin API থেকে expires_at পড়ুন, যেখানে মেয়াদহীন কী-এর ক্ষেত্রে এটি null হিসেবে থাকে।

SDK আপনার ফেডারেশন সেটআপ উপেক্ষা করে কী (key) ব্যবহার করছে। ক্রেডেনশিয়াল অগ্রাধিকারের তালিকায় ANTHROPIC_API_KEY এবং ANTHROPIC_AUTH_TOKEN ফেডারেশনের উপরে থাকে, তাই এদের যেকোনো একটি ফেডারেশনকে আড়াল করে ফেলে। এর একটি সূক্ষ্ম দিক হলো: একটি ভেরিয়েবল খালি স্ট্রিং হিসেবে এক্সপোর্ট করা হলেও সেটি তার জায়গা দখল করে রাখে, তাই ANTHROPIC_API_KEY="" ব্যবহার করলে SDK ফেডারেশনের দিকে না গিয়ে একটি খালি কী দিয়ে প্রমাণীকরণের চেষ্টা করবে। এর পরিবর্তে unset ANTHROPIC_API_KEY ব্যবহার করুন।

ফেডারেশনে Authentication failed বার্তা সহ 401 ত্রুটি। এই বার্তাটি প্রতিটি সম্ভাব্য কারণের জন্য ইচ্ছাকৃতভাবে একই রাখা হয়েছে, যাতে কোনো ব্যবহারকারী ত্রুটির টেক্সট পড়ে আপনার রুল কনফিগারেশন সম্পর্কে ধারণা নিতে না পারে। আসল কারণটি কনসোলের প্রমাণীকরণ ইতিহাস (authentication history) পৃষ্ঠায় রেকর্ড করা থাকে। তাই JWT নিয়ে অনুমান না করে সেখান থেকে দেখা শুরু করুন।

Foundry-তে 403 ত্রুটি। টোকেনটি প্রমাণীকৃত হয়েছে, কিন্তু আপনার Azure অ্যাকাউন্টে এমন কোনো রোল নেই যা এই কলটি করার অনুমতি দেয়। অনুরোধকারী আইডেন্টিটির জন্য Foundry User (পূর্বে Azure AI User) বা Cognitive Services User-এর মতো একটি Azure RBAC রোল বরাদ্দ করুন।

Bedrock সংক্রান্ত যেকোনো সমস্যা। প্রথমে সার্ভিস ইউজার হিসেবে aws sts get-caller-identity কমান্ডটি চালান। এটি নিশ্চিত করবে যে সার্ভারে কার্যকর AWS ক্রেডেনশিয়াল আছে কি না, যা ক্রেডেনশিয়াল সংক্রান্ত সমস্যাকে মডেল অ্যাক্সেস বা রিজিয়ন অমিল থেকে আলাদা করতে সাহায্য করবে। AWS কনসোলে প্রতিটি রিজিয়নের জন্য আলাদাভাবে মডেল অ্যাক্সেস প্রদান করতে হয়, তাই একটি রিজিয়নে অ্যাক্সেস চালু থাকলেও অন্য রিজিয়নে কল করার সময় সমস্যা হতে পারে।

FAQ

Bedrock বা Vertex-এ Claude ব্যবহার করার জন্য কি আমার Anthropic API key প্রয়োজন?

না। Amazon Bedrock-এ SDK প্রতিটি অনুরোধে SigV4 ব্যবহার করে AWS credentials দিয়ে স্বাক্ষর করে এবং Google Cloud-এ এটি Application Default Credentials-এর মাধ্যমে পাওয়া Google access token পাঠায়। এই সেটআপের কোনোটিতেই Anthropic-এর দেওয়া কোনো secret-এর প্রয়োজন হয় না এবং ব্যবহারের খরচ Anthropic-এর পরিবর্তে সরাসরি ক্লাউড অ্যাকাউন্টে বিল করা হয়। এই কারণেই ANTHROPIC_API_KEY-এ ফেলে রাখা Anthropic key ঐ হোস্টগুলোতে একটি ঝুঁকি তৈরি করে: ক্লাউড এন্ডপয়েন্টের দিকে নির্দেশিত একটি সাধারণ ক্লায়েন্ট অনায়াসেই সেটি সেখানে পাঠিয়ে দেবে।

Claude কি Azure-এ পাওয়া যায়?

হ্যাঁ, Microsoft Foundry-এর মাধ্যমে, যা আগে Azure AI Foundry নামে পরিচিত ছিল। আপনি একটি Foundry রিসোর্স তৈরি করে তাতে একটি Claude মডেল deploy করবেন এবং Azure-এর দেওয়া key-সহ একটি api-key হেডার অথবা Microsoft Entra bearer token ব্যবহার করে https://{resource}.services.ai.azure.com/anthropic/v1/messages কল করবেন। ব্যবহারের খরচ Azure Marketplace-এর মাধ্যমে Claude Consumption Units হিসেবে বিল করা হয়। অনুরোধের বডিতে থাকা model ফিল্ডে অবশ্যই আপনার deployment-এর নাম থাকতে হবে, যা শুধুমাত্র তখনই মডেল আইডেন্টিফায়ারের সমান হয় যদি না আপনি deployment-এর নাম পরিবর্তন করেন।

Linux সার্ভারে Claude API key কোথায় সংরক্ষণ করা উচিত?

root-এর মালিকানাধীন এবং 600 মোডের একটি ফাইলে, যা systemd ইউনিটের EnvironmentFile=-এর মাধ্যমে লোড করা হয়। systemd ইউনিটের User=-এ সুইচ করার আগেই root হিসেবে ফাইলটি পড়ে ফেলে, তাই service account-এর এতে কোনো অ্যাক্সেসের প্রয়োজন হয় না। এটিকে রিপোজিটরির বাইরে রাখুন, ইউনিট ফাইলের ভেতরে রাখবেন না (যা যে কেউ পড়তে পারে এবং systemctl cat দ্বারা প্রিন্ট করা যায়), এবং কন্টেইনার ইমেজ লেয়ার থেকেও দূরে রাখুন, কারণ docker history --no-trunc যেকোনো কিছু যা ENV বা --build-arg দিয়ে সেট করা হয়েছে তা প্রিন্ট করে দেয়।

কোনো কিছু পরিবর্তন না করা সত্ত্বেও আমার Claude API অনুরোধ কেন 401 ত্রুটি দেখাচ্ছে?

সবচেয়ে সাধারণ কারণ হলো key-টির মেয়াদ শেষ হয়ে যাওয়া, যা তৈরির সময় নির্ধারণ করা হয়েছিল। মেয়াদ তৈরির সময় সেট করা হয়, পরে তা আর পরিবর্তন করা যায় না এবং স্বল্পমেয়াদী key-গুলোর মেয়াদ শেষ হওয়ার আগে কোনো সতর্কতামূলক ইমেইল পাঠানো হয় না। মেয়াদোত্তীর্ণ key পুনরায় সক্রিয় করা সম্ভব নয়, তাই একটি নতুন key তৈরি করুন, সেটিকে এনভায়রনমেন্ট ফাইলে লিখুন, সার্ভিসটি রিস্টার্ট করুন এবং সবশেষে পুরনো key-টি বাতিল করুন। যদি key-টি নিশ্চিতভাবে সচল থাকে, তবে পরীক্ষা করে দেখুন কোনো পুরনো credential সেটিকে বাধা দিচ্ছে কি না: ANTHROPIC_API_KEY যদি একটি খালি স্ট্রিং হিসেবে সেট করা থাকে, তবে সেটি অন্য সব credential সোর্সের চেয়ে বেশি প্রাধান্য পায়।