Claude-এ 1M tokens-এর দাম কত?

Claude-এ 1M tokens-এর মূল্য কত?

1M tokens মানে এক মিলিয়ন tokens। প্রতিটি Claude API (application programming interface)-এর মূল্য এই এককে উল্লেখ করা হয়। এর কোনো একক মূল্য নেই। কারণ input এবং output-এর জন্য আলাদা হারে বিল করা হয়, এবং প্রতিটি model-এর জন্য এই দুই হারের নিজস্ব জোড়া থাকে। August 2026 অনুযায়ী, Claude Haiku 4.5-এ এক মিলিয়ন input tokens-এর মূল্য $1, Claude Sonnet 5-এ $2, এবং Claude Opus 5-এ $5।

Output বেশি ব্যয়বহুল অংশ। বর্তমানে প্রতিটি model-এ output rate input rate-এর পাঁচ গুণ। তাই headline figure-এর চেয়ে input ও output-এর অনুপাত আপনার বিলের ওপর বেশি প্রভাব ফেলে। যে app দীর্ঘ documents পাঠিয়ে সংক্ষিপ্ত উত্তর ফেরত দেয়, সেটির খরচ এমন app-এর থেকে সম্পূর্ণ আলাদা হতে পারে, যা সংক্ষিপ্ত prompt থেকে দীর্ঘ উত্তর তৈরি করে।

এই পৃষ্ঠায় unit economics ব্যাখ্যা করা হয়েছে: একটি token-এর মূল্য কত এবং build করার আগে বিল কীভাবে অনুমান করবেন। কাজের সময় tokens কোথায় ব্যবহৃত হয় তা জানতে Claude Code session-এর ভেতরে tokens কোথায় যায় পড়ুন।

1M টোকেন দেখতে কেমন

টোকেন হলো মডেল যে পাঠ্য পড়ে বা লেখে তার একটি অংশ। Anthropic-এর আনুমানিক নির্দেশনা অনুযায়ী, প্রতি 4 অক্ষরে 1টি টোকেন, অথবা ইংরেজিতে প্রায় 0.75টি শব্দ। তাই 1M টোকেন প্রায় 750,000টি শব্দ, অথবা সাধারণ পাঠ্যের প্রায় 4 MB।

সাধারণ ইনপুটের প্রকাশিত হিসাব এই পরিমাণটি বুঝতে আরও সহায়তা করে।

[
  {
    "label": "Average web page (10 kB)",
    "tokens": "2,500"
  },
  {
    "label": "Documentation page (100 kB)",
    "tokens": "25,000"
  },
  {
    "label": "Research paper PDF (500 kB)",
    "tokens": "125,000"
  }
]

এই হারে, 1M টোকেন একবার পড়া প্রায় 400টি গড় ওয়েব পৃষ্ঠা, অথবা ওই আকারের 8টি গবেষণাপত্রের সমান। এটি মাঝারি আকারের একটি codebase একবার পড়ার সমান, অথবা একজন ব্যক্তির এক মাসের হালকা chat ব্যবহারের সমান।

এগুলোকে আনুমানিক হিসাব হিসেবে বিবেচনা করুন। Code, JSON এবং ইংরেজি ছাড়া অন্য ভাষার পাঠ্যে একটি টোকেনের মধ্যে কম শব্দ থাকে। তাই 0.75 অনুপাতটি আশাবাদী প্রান্তের হিসাব। আরেকটি বিষয়ও হিসাব বদলে দেয়: Claude Opus 4.7 এবং পরবর্তী সংস্করণগুলো, যার মধ্যে Opus 5 এবং Sonnet 5 অন্তর্ভুক্ত, নতুন tokenizer ব্যবহার করে। একই পাঠ্যের জন্য এই tokenizer Sonnet 4.6 এবং আগের সংস্করণগুলোর তুলনায় প্রায় 30 শতাংশ বেশি টোকেন তৈরি করে। Claude Haiku 4.5 পুরোনো tokenizer ব্যবহার করে। তাই Haiku 4.5-এ মাপা হিসাব একই input-এর ক্ষেত্রে Sonnet 5-এর হিসাবকে কম দেখায়। এর অর্থ, এই সীমার দুই পাশে সরাসরি প্রতি-মিলিয়ন মূল্য তুলনা ন্যায্য নয়। সিদ্ধান্ত নেওয়ার আগে একই prompt উভয় মডেলের ক্ষেত্রে গণনা করুন।

প্রতি মিলিয়ন টোকেনে Claude-এর চার্জ

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug 2026)",
    "input_usd": 2,
    "output_usd": 10
  },
  {
    "label": "Sonnet 5 (from 1 Sep 2026)",
    "input_usd": 3,
    "output_usd": 15
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25
  }
]

Claude Sonnet 5-এর জন্য 31 August 2026 পর্যন্ত প্রারম্ভিক মূল্য প্রযোজ্য: input-এর জন্য $2 এবং output-এর জন্য $10। 1 September 2026 থেকে standard rate প্রযোজ্য হবে: input-এর জন্য $3 এবং output-এর জন্য $15। Claude Opus 5-এর মূল্য $5 এবং $25।

Rate পরিবর্তিত হতে পারে। এই পৃষ্ঠার প্রতিটি সংখ্যাকে August 2026 তারিখের একটি হিসাবের উদাহরণ হিসেবে বিবেচনা করুন। বাজেট অনুমোদনের আগে official pricing page-এ বর্তমান সংখ্যা নিশ্চিত করুন।

Context length rate পরিবর্তন করে না। Claude 4.6 এবং পরবর্তী সংস্করণে সম্পূর্ণ 1M token context window-এর জন্য standard pricing প্রযোজ্য। তাই 900,000 token-এর একটি request-এর প্রতি token-এর খরচ 9,000 token-এর request-এর সমান। দীর্ঘ prompt-এর খরচ বেশি হয়, কারণ এতে বেশি token থাকে। এর জন্য আলাদা long-context rate প্রযোজ্য নয়।

মূল্য পরিবর্তনের পরও যে হিসাব সঠিক থাকে

প্রতিটি বিলের ক্ষেত্রে দুটি গুণ এবং একটি যোগ করতে হয়।

cost = (input_tokens  / 1,000,000) * input_rate
     + (output_tokens / 1,000,000) * output_rate

চালানো যায় এমন কোডে এটি লিখলে:

INPUT_RATE = 2.00    # USD per million input tokens, Sonnet 5, August 2026
OUTPUT_RATE = 10.00  # USD per million output tokens

def cost(input_tokens, output_tokens):
    return (input_tokens * INPUT_RATE + output_tokens * OUTPUT_RATE) / 1_000_000

print(f"{cost(4300, 400):.4f}")

এটি 0.0126 প্রিন্ট করে। একটি অনুরোধে 4,300টি ইনপুট টোকেন পাঠিয়ে 400টি আউটপুট টোকেন ফেরত পেলে Sonnet 5-এ খরচ প্রায় 1.3 সেন্ট হয়। দুটি হার আপনার কোডের একই জায়গায় রাখুন। কোনো মূল্য পরিবর্তন হলে দুটি লাইন সম্পাদনা করলেই আপনার সিস্টেমের প্রতিটি আনুমানিক হিসাবও সেই অনুযায়ী পরিবর্তিত হবে।

একটি বাস্তব অ্যাপের জন্য উদাহরণভিত্তিক হিসাব

একটি support assistant বিবেচনা করুন। এর system prompt এবং product documentation মিলিয়ে 4,000 tokens হয়। Messages API stateless হওয়ায় এবং call-এর মধ্যে model কিছু মনে না রাখায় এগুলো প্রতিটি request-এর সঙ্গে পাঠানো হয়। একজন ব্যবহারকারীর প্রশ্নে আরও প্রায় 300 tokens যোগ হয়। একটি উত্তর সাধারণত প্রায় 400 tokens হয়। তাই প্রতিটি request-এ 4,300 input এবং 400 output tokens লাগে।

এক মিলিয়ন input tokens এই ধরনের প্রায় 232টি request-এর জন্য যথেষ্ট। প্রতিদিন 1,000টি request হলে অ্যাপটি দৈনিক 4.3 million input tokens ব্যবহার করে। তাই "1M tokens" ছয় ঘণ্টারও কম সময়ের traffic-এর জন্য যথেষ্ট।

[
  {
    "label": "Opus 5, list rates",
    "cost_per_1k_usd": "31.50"
  },
  {
    "label": "Sonnet 5, list rates",
    "cost_per_1k_usd": "12.60"
  },
  {
    "label": "Sonnet 5, Batch API",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Haiku 4.5, list rates",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Sonnet 5, warm prompt cache",
    "cost_per_1k_usd": "5.40"
  }
]

Claude Opus 5-এ এই traffic-এর জন্য প্রতি 1,000টি request-এ খরচ হয় $31.50। Sonnet 5-এ খরচ $12.60। Claude Haiku 4.5-এ নামলে খরচ হয় $6.30, আর Sonnet 5-এ warm prompt cache ব্যবহার করলে খরচ আরও কমে $5.40 হয়।

এক মাসের এই traffic-এর হিসাব পেতে সংখ্যাটি 30 দিয়ে গুণ করুন। তালিকাভুক্ত দরে Sonnet 5 ব্যবহার করলে মাসে খরচ প্রায় $378। একই অ্যাপ warm cache ব্যবহার করলে খরচ প্রায় $162। এই volume-এ আপনি যে rate নিয়ে আলোচনা করে কমাতে পারবেন, তার চেয়ে আপনার model নির্বাচন এবং caching-এর সিদ্ধান্ত—দুটির প্রতিটির প্রভাব বেশি। কোন model চালাবেন, সেটি আলাদা প্রশ্ন। আপনার evaluation-এ উত্তীর্ণ সবচেয়ে সস্তা model-টিই নির্বাচন করুন: Opus, Sonnet এবং Haiku-এর মধ্যে নির্বাচন-এ এটি সঠিকভাবে পরীক্ষা করার পদ্ধতি ব্যাখ্যা করা হয়েছে।

প্রম্পট ক্যাশিং পুনরাবৃত্ত অংশের খরচ কমায়

প্রতিটি অনুরোধে 4,000 টোকেনের ওই প্রিফিক্সটি একই থাকে, এবং প্রতিবার এর সম্পূর্ণ ইনপুট মূল্য দিতে হয়। প্রম্পট ক্যাশিং প্রক্রিয়াকৃত প্রিফিক্স সংরক্ষণ করে এবং সেটি পুনরায় ব্যবহার করার সময় কম হারে মূল্য নির্ধারণ করে।

ক্যাশ পড়ার খরচ বেস ইনপুট হারের 0.1 গুণ। 5 মিনিটের জীবনকালের জন্য ক্যাশ লেখার খরচ বেস হারের 1.25 গুণ, আর 1 ঘণ্টার জীবনকালের জন্য 2 গুণ। তাই 5 মিনিটের ক্যাশ একবার পড়ার পরই খরচ পুষিয়ে দেয়। কারণ লেখার অতিরিক্ত খরচ 0.25, আর প্রতিটি পড়ায় সাশ্রয় হয় 0.9। 1 ঘণ্টার ক্যাশের ক্ষেত্রে খরচ পুষিয়ে নিতে 2 বার পড়তে হয়।

এটি চালু করার সবচেয়ে সহজ উপায় হলো একটি একক top-level field ব্যবহার করা:

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "You are a helpful assistant.",
    "messages": [
      {"role": "user", "content": "What are the key themes in Pride and Prejudice?"}
    ]
  }'

এরপর ফিরে আসা usage block-টি পড়ুন:

{
  "usage": {
    "cache_creation_input_tokens": 5120,
    "cache_read_input_tokens": 1800,
    "input_tokens": 50,
    "output_tokens": 503
  }
}

এই 3টি input counter-এর জন্য 3টি ভিন্ন হারে বিল করা হয়, এবং এগুলোর যোগফলই আপনার প্রকৃত ইনপুট ভলিউম: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens। কেবল input_tokens পড়ে করা খরচের হিসাব ক্যাশিং চালু হলে গুরুতরভাবে ভুল হবে।

দুটি কারণে ক্যাশ ব্যবহার করে খরচ পোষানো যায় না, এবং উভয় ক্ষেত্রেই কোনো ত্রুটি নীরবে ঘটে।

প্রিফিক্সটি byte-identical হতে হবে। ক্যাশ lookup একটি prefix match ব্যবহার করে। তাই system prompt-এর শুরুতে timestamp বা ব্যবহারকারীর নাম রাখলে প্রতিটি অনুরোধে প্রিফিক্সটি বদলে যায়। তখন প্রতিবার বেস ইনপুট হারের 1.25 গুণ খরচ হয় এবং কখনো ক্যাশ পড়া হয় না। এর লক্ষণ হলো cache_creation_input_tokens-এর মান বেশি থাকা, আর cache_read_input_tokens-এর মান 0 থাকা। অনুরোধগুলোর মধ্যে একই থাকা শেষ block-এ cache_control রাখুন এবং পরিবর্তনশীল সবকিছু এর পরে রাখুন। আপনার tools definitions পরিবর্তন করলে সেগুলোর নিচের পুরো ক্যাশ invalid হয়ে যায়, কারণ invalidation এই ক্রমে নিচের দিকে চলে: tools, তারপর system, তারপর messages।

প্রিফিক্সটি যথেষ্ট দীর্ঘ হতে হবে। Opus 5-এ ক্যাশ করার সর্বনিম্ন দৈর্ঘ্য 512 টোকেন, Sonnet 5-এ 1,024 টোকেন এবং Haiku 4.5-এ 4,096 টোকেন। এর চেয়ে ছোট prompt ক্যাশ করা হয় না এবং কোনো error ফেরত দেওয়া হয় না। উপরের উদাহরণের 4,000 টোকেনের প্রিফিক্স Sonnet 5-এ ক্যাশ হয়, কিন্তু Haiku 4.5-এ ক্যাশ হয় না, কারণ 4,000 ওই model-এর নির্ধারিত সর্বনিম্ন সীমার চেয়ে কম। উভয় counter-এর মান 0 হলে কোনো কিছু ক্যাশ করা হয়নি।

ব্যাচ প্রসেসিং হার অর্ধেক করে

Batch API ইনপুট এবং আউটপুট—উভয়ের জন্যই 50 percent কম মূল্যে asynchronousভাবে request প্রসেস করে। উপরের উদাহরণে, প্রতি 1,000 request-এর খরচ $12.60 থেকে $6.30-এ নেমে আসে। এই discount prompt caching-এর সঙ্গেও প্রযোজ্য হয়। তাই bulk কাজ চালানোর সবচেয়ে কম খরচের উপায় হলো cached batch job।

এর বিনিময়ে latency বেড়ে যায়। তাই কোনো ব্যক্তি যে কাজের ফলের জন্য বসে অপেক্ষা করছেন, সেখানে batch উপযুক্ত নয়। এটি overnight classification এবং document backfill-এর জন্য উপযোগী।

একটি কথোপকথনের মধ্যে চ্যাটের খরচ কেন বাড়ে

API কোনো অবস্থা সংরক্ষণ করে না। তাই প্রতিটি ধাপে আপনার client পুরো কথোপকথনটি আবার পাঠায়। ফলে একটি চ্যাটে token ব্যবহার এর দৈর্ঘ্যের বর্গের সঙ্গে বাড়ে, সরলরেখায় নয়।

ধরা যাক, প্রতিটি ধাপে গড়ে 500 token থাকে। ধাপ 1-এ 500 input token পাঠানো হয়। ধাপ 2-এ 1,000। ধাপ 20-এ 10,000। n(n+1)/2 সূত্রে এগুলো যোগ করলে, 20 ধাপের একটি কথোপকথনে প্রায় 105,000 input token পাঠানো হয়, যদিও transcript-টির দৈর্ঘ্য মাত্র 10,000 token।

এই কারণেই একটি chat feature-এর খরচ transcript-এর ইঙ্গিতের চেয়ে বেশি হয়। দীর্ঘ thread-এ স্থিতিশীল prefix cache করা বা পুরোনো ধাপগুলোর সারাংশ তৈরি করাও তাই খরচ সাশ্রয় করে। Tool call-এর ওপর loop করা একটি agent-এর ক্ষেত্রেও একই ধরণ দেখা যায়, তবে পরিস্থিতি আরও খারাপ: প্রতিটি tool result history-তে থেকে যায় এবং পরবর্তী প্রতিটি ধাপে আবার পাঠানো হয়। নিজে চালানো agent-এর জন্য একটি কঠোর ব্যয়ের সীমা নির্ধারণ করা এখানে সবচেয়ে গুরুত্বপূর্ণ, কারণ এই বৃদ্ধি স্বয়ংক্রিয়ভাবে ঘটে এবং এটি পর্যবেক্ষণ করার কেউ থাকে না।

অনুমান করার আগে টোকেন গণনা করুন

শব্দের সংখ্যা থেকে টোকেনের সংখ্যা নির্ণয় করা বন্ধ করুন। API নিজেই টোকেন গণনা করে, কোনো অতিরিক্ত খরচ ছাড়াই। এই গণনার জন্য বার্তা তৈরির হারের সীমা থেকে পৃথক rate limit প্রযোজ্য।

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "system": "You are a scientist",
    "messages": [{
      "role": "user",
      "content": "Hello, Claude"
    }]
  }'

উত্তরে একটি field থাকে:

{ "input_tokens": 14 }

আপনার প্রকৃত system prompt এবং tool definitions, একটি প্রতিনিধিত্বমূলক user message-সহ এতে পাঠান। তারপর সংখ্যাটি উপরের cost function-এ ব্যবহার করুন। এই endpoint একটি message request-এর মতো একই body গ্রহণ করে। তাই images এবং PDFs-ও সঠিকভাবে গণনা হয়। দুটি বিষয় গুরুত্বপূর্ণ। এই সংখ্যা একটি আনুমানিক হিসাব এবং billed figure থেকে সামান্য ভিন্ন হতে পারে। এছাড়া, আপনি যে model পাঠান তার tokenizer দিয়ে এটি মাপা হয়। তাই বাস্তবে যে model চালাবেন, সেটিই পাঠান।

Output tokens আগে থেকে গণনা করা যায় না, কারণ সেগুলো তখনও তৈরি হয়নি। max_tokens ব্যবহার করে এগুলোর সর্বোচ্চ সীমা নির্ধারণ করুন। এরপর live traffic-এ usage.output_tokens থেকে প্রকৃত distribution মাপুন।

বিলের সঙ্গে আর কী যোগ হয়

বিলের সবচেয়ে বড় অংশ টোকেনের জন্য। কিছু খরচ টোকেন নয় এবং এগুলো অনেককে অবাক করে।

• প্রতিটি অনুরোধে tool definitions input tokens হিসেবে গণনা হয়। আপনার নিজস্ব schema যোগ করার আগেই, শুধু tool use system prompt Opus 5-এ 286 থেকে 406 tokens যোগ করে। বিস্তারিত 10টি tool description একটি ছোট prompt-এর আকার দ্বিগুণ করতে পারে।
• Web search-এর জন্য প্রতি 1,000টি search-এ $10 নেওয়া হয়। এর সঙ্গে ফলাফল context-এ প্রবেশ করার সময় ব্যবহৃত tokens-এর খরচও যোগ হয়।
• Web fetch-এর নিজস্ব কোনো ফি নেই। তবে fetch করা page input tokens-এ পরিণত হয়। 100 kB-এর documentation page-এ আনুমানিক 25,000 input tokens থাকে।
• Claude 4.6 এবং পরবর্তী সংস্করণে inference_geo ব্যবহার করে শুধু US-এ inference করার অনুরোধ করলে প্রতিটি token category-তে 1.1 গুণ multiplier প্রযোজ্য হয়। এতে cache read এবং cache write-ও অন্তর্ভুক্ত।

API কেনার সিদ্ধান্ত আপনার ব্যবহারের পরিমাণের ওপর নির্ভর করে। নির্দিষ্ট সীমার নিচে ব্যবহার হলে flat monthly plan সরাসরি বেশি সাশ্রয়ী। Claude subscription-এর সঙ্গে API-এর পরিমাপভিত্তিক তুলনা বাস্তব সংখ্যা দিয়ে এই তুলনা করে।

FAQ

Claude-এ 1M tokens-এর খরচ কত?

এটি model এবং tokens input না output—তার ওপর নির্ভর করে। August 2026 অনুযায়ী, Claude Haiku 4.5-এ এক মিলিয়ন input tokens-এর খরচ $1, introductory pricing-এর অধীনে Claude Sonnet 5-এ $2, এবং Claude Opus 5-এ $5। এই প্রতিটি model-এ output-এর খরচ input rate-এর পাঁচ গুণ। 1 September 2026 থেকে Sonnet 5-এ input-এর খরচ হবে $3 এবং output-এর খরচ হবে $15। Rate পরিবর্তিত হয়। তাই budget-এ কোনো অঙ্ক নির্ধারণের আগে official pricing page-এ তা নিশ্চিত করুন।

1M tokens কি 1M words-এর সমান?

না। একটি token-এ English ভাষায় প্রায় 4টি character, বা প্রায় 0.75টি word থাকে। তাই এক মিলিয়ন tokens-এ প্রায় 750,000টি word থাকে। এই অনুপাতটি কেবল একটি নির্দেশিকা। Code, JSON এবং English ছাড়া অন্যান্য ভাষায় প্রতি word-এ বেশি tokens ব্যবহৃত হয়। Claude Opus 4.7 এবং পরবর্তী version-এ আরও নতুন tokenizer ব্যবহৃত হয়। একই text-এর জন্য এটি Claude Sonnet 4.6 এবং আগের version-এর তুলনায় প্রায় 30 percent বেশি tokens তৈরি করে। তাই ভিন্ন model generation-এর মধ্যে count সরাসরি তুলনাযোগ্য নয়। আপনি যে model চালানোর পরিকল্পনা করছেন, সেটি দিয়ে বিনামূল্যের /v1/messages/count_tokens endpoint ব্যবহার করে পরিমাপ করুন।

Prompt caching কি সবসময় খরচ কমায়?

না। 5 minute-এর cache write-এর খরচ base input rate-এর 1.25 গুণ। তাই কোনো prefix একবার write করার পর আর কখনো read না হলে, সেটি সরাসরি পাঠানোর চেয়ে 25 percent বেশি খরচ হয়। প্রথম read থেকেই এটি খরচ পুষিয়ে দেয়। এটি দুটি কারণে কাজ নাও করতে পারে, এবং উভয় ক্ষেত্রেই কোনো সতর্কতা দেখা যায় না। Request-গুলোর মধ্যে cached prefix পরিবর্তিত হলে lookup কখনো মেলে না, কারণ এটি exact prefix match ব্যবহার করে। Prefix-টি model-এর minimum cacheable length-এর চেয়ে ছোট হলেও কিছু cache হয় না এবং কোনো error ফেরত দেওয়া হয় না। Sonnet 5-এ এই সীমা 1,024 tokens এবং Haiku 4.5-এ 4,096 tokens। cache_creation_input_tokens এবং cache_read_input_tokens উভয়ই 0 দেখালে cache কোনো কাজ করছে না।

আমার message count-এর তুলনায় bill দ্রুত বাড়ল কেন?

কারণ প্রতিটি turn-এ পুরো conversation আবার পাঠানো হয়। Messages API কোনো state সংরক্ষণ করে না। তাই chat-এর turn 20-এ আগের 19টি turn-এর সব input হিসেবে আবার পাঠানো হয়। প্রতিটি turn-এ গড়ে 500 tokens থাকলে, 20 turn-এর একটি conversation প্রায় 105,000 input tokens পাঠায়, যদিও transcript-এর দৈর্ঘ্য মাত্র 10,000 tokens। Agent loop-ও একইভাবে কাজ করে, কারণ প্রতিটি tool result history-তে থেকে যায়। Stable prefix cache করুন, অথবা পুরোনো turn-গুলোর summary তৈরি করে request থেকে সেগুলো বাদ দিন।