omp (Oh My Pi) + JoinGonka Gateway: মডেল রোল সহ এজেন্ট

ধাপ ১: omp ইনস্টল করুন। প্রজেক্টের README-তে অফিসিয়াল পদ্ধতি:

# macOS and Linux
curl -fsSL https://omp.sh/install | sh

# Homebrew
brew install can1357/tap/omp

# via Bun (requires Bun 1.3.14 or newer)
bun install -g @oh-my-pi/pi-coding-agent

# Windows (PowerShell)
irm https://omp.sh/install.ps1 | iex

ধাপ ২: কী পান। gate.joingonka.ai/register-এ নিবন্ধন করুন, ঠিকানা যাচাই করুন এবং "API-কী" বিভাগে jg- উপসর্গসহ একটি কী তৈরি করুন। নেটওয়ার্কের সমস্ত মডেলের জন্য একটি কী এবং একটি ব্যালেন্স কাজ করে।

ধাপ ৩: ইনস্টলার চালান।

npx @joingonka/setup --tool omp

ইনস্টলার কী জিজ্ঞাসা করবে — কমান্ড লাইনের আর্গুমেন্টে এটি পাঠানো হয় না যাতে শেলের ইতিহাসে না থেকে যায় — এবং চারটি কাজ করবে:

• ~/.omp/agent/models.yml-এ joingonka প্রোভাইডার লিখবে: গেটওয়ে ঠিকানা, openai-completions প্রোটোকল, লিটারেল কী এবং নেটওয়ার্কের তিনটি মডেল প্রকৃত কনটেক্সট উইন্ডো এবং উত্তর সীমাসহ; ফাইলটি 600 অনুমতি পাবে;
• ডিফল্ট মডেল — ~/.omp/agent/config.yml-এ modelRoles.default — DeepSeek V4 Flash-এ সেট করবে, কিন্তু শুধুমাত্র যদি ভূমিকা খালি থাকে বা নেটওয়ার্ক থেকে চলে যাওয়া একটি মডেলের দিকে ইঙ্গিত করে: অন্যের পছন্দ它会 বাধা দেয় না, বরং কীভাবে পরিবর্তন করতে হয় তা জানায়;
• লেখার আগে আগের ফাইলের ব্যাকআপ নেবে, এবং অন্যান্য প্রোভাইডার, ভূমিকা এবং মন্তব্য যেমন ছিল তেমনই থাকবে;
• শেষে গেটওয়েতে একটি লাইভ অনুরোধ পাঠাবে এবং সরাসরি বলবে কী, ঠিকানা এবং মডেল গৃহীত হয়েছে কি না।

অন্য ডিফল্ট মডেল --model ফ্ল্যাগ দিয়ে সেট করা যায় deepseek, glm বা minimax সংক্ষেপণসহ — স্পষ্টভাবে নির্দিষ্ট মডেল সর্বদা লেখা হয়। ডটফাইল এবং সার্ভারগুলির জন্য একটি নন-ইন্টার‌্যাকটিভ মোড রয়েছে, যেখানে কী এনভায়রনমেন্ট ভ্যারিয়েবল থেকে নেওয়া হয়:

JOINGONKA_API_KEY=jg-your-key npx @joingonka/setup --tool omp --model glm --non-interactive

কনফিগের অস্বাভাবিক অবস্থান ইনস্টলার নিজেই বিবেচনা করে: নামযুক্ত প্রোফাইল (OMP_PROFILE) এবং স্থানান্তরিত এজেন্ট ডিরেক্টরি (PI_CODING_AGENT_DIR)। উত্তরাধিকারসূত্রে প্রাপ্ত models.json তা models.yml-এ স্থানান্তর করে যেভাবে omp নিজেই করত — আগের প্রোভাইডাররা হারাবে না। আর যদি পাশে পুরনো settings.json থাকে config.yml ছাড়া, ইনস্টলার config.yml তৈরি করবে না যাতে omp নিজের সেটিংস স্থানান্তর মিস না করে: এটি একবার omp চালু করতে এবং কমান্ড পুনরাবৃত্তি করতে বলবে।

ইনস্টলার যা করে, তার সবটাই হাতে লিখে ফেলা যায়। ফাইল মাত্র দুটি, আর প্রতিটির নিজস্ব কাজ আছে: models.yml প্রোভাইডার আর মডেল বর্ণনা করে, config.yml সেটিংস সংরক্ষণ করে — যার মধ্যে কোন মডেল কোন রোলে বসবে সেটাও আছে।

# ~/.omp/agent/models.yml
providers:
  joingonka:
    baseUrl: https://gate.joingonka.ai/v1
    api: openai-completions
    apiKey: jg-your-key
    models:
      - id: deepseek-ai/DeepSeek-V4-Flash-0731
        name: DeepSeek V4 Flash (Gonka)
        input: [text]
        contextWindow: 380000
        maxTokens: 32768
        reasoning: true
      - id: zai-org/GLM-5.3-Flash
        name: GLM-5.3 Flash (Gonka)
        input: [text]
        contextWindow: 390000
        maxTokens: 8192
        reasoning: true
      - id: MiniMaxAI/MiniMax-M2.7
        name: MiniMax M2.7 (Gonka)
        input: [text]
        contextWindow: 200000
        maxTokens: 8192

# ~/.omp/agent/config.yml
modelRoles:
  default: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731

কী সরাসরি লেখা সবচেয়ে ঝামেলাহীন পথ: omp যেকোনো পরিবেশ থেকে চালু হয়, আর ফাইলটি chmod 600 ~/.omp/agent/models.yml কমান্ড দিয়ে বন্ধ করে দিলেই যথেষ্ট। কী ফাইলের বাইরে রাখতে চান? তাহলে apiKey-তে ভেরিয়েবলের নাম লিখুন, যেমন JOINGONKA_API_KEY, আর যে শেল থেকে omp চালান সেখানে সেটি এক্সপোর্ট করুন: কী রিজলভ করার এই ক্রমটিই প্রকল্পের ডকুমেন্টেশনে বর্ণিত আছে।

ঐচ্ছিক cost ফিল্ড (প্রতি মিলিয়ন টোকেনের দাম) শুধু omp ইন্টারফেসে সেশনের খরচ অনুমান করতে দরকার। ইনস্টলার সেখানে ইনস্টলের সময়কার গেটওয়ের জীবন্ত দাম লিখে দেয়; হাতে লেখা কনফিগে ফিল্ডটি বাদ দেওয়া যায় — এই অনুমানের সাথে আপনার বিলের কোনো সম্পর্ক নেই, প্রকৃত খরচ দেখায় ড্যাশবোর্ড।

মডেল সিলেক্টর লেখা হয় provider/model-id আকারে। প্রোভাইডারের নাম প্রথম স্ল্যাশেই আলাদা হয়, তাই নিজস্ব স্ল্যাশযুক্ত নেটওয়ার্ক আইডি যেমন আছে তেমনই লেখা হয়: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731। config.yml না বদলে ইন্টারফেস থেকেই রোল বসানো যায় — সেশনের ভেতরে /model কমান্ড দিয়ে বা omp setup উইজার্ডে।

omp-এ সবকিছুর জন্য একটি মাত্র মডেল নয়, বরং বিভিন্ন ভূমিকার (roles) জন্য আলাদা মডেল নির্বাচন করা যায় — এটিই কাস্টমাইজেশনের প্রধান হাতিয়ার। ডায়ালগের জন্য বিল্ট-ইন ভূমিকাগুলো হলো: default, smol, slow, plan, commit, task, tiny, memory, advisor এবং vision। সবগুলোতে মডেল অ্যাসাইন করার প্রয়োজন নেই: অঘোষিত smol এবং slow প্রথমে default ভূমিকার মডেল গ্রহণ করে, task ভূমিকা ছাড়া সাব-এজেন্টরা বর্তমান সেশনের মডেলে কাজ করে, এবং commit ও tiny মডেলগুলো smol-কে অনুসরণ করে। শুধুমাত্র একটি default লাইন দিয়ে কনফিগারেশন করা পুরোপুরি সম্ভব।

নেটওয়ার্কের মডেলগুলোর মধ্যে ভূমিকা ভাগ করার উদ্দেশ্য খরচ কমানো নয় — কারণ DeepSeek V4 Flash, GLM-5.3 Flash এবং MiniMax M2.7-এর দাম একই — বরং আচরণ এবং ক্ষমতার ভারসাম্য বজায় রাখা: লজিক্যাল মডেল ভালো পরিকল্পনা করতে পারে, দীর্ঘ উত্তরের মডেল ভালো লিখতে পারে, এবং ব্যাকগ্রাউন্ডের ছোটখাটো কাজগুলোকে মূল কাজের লাইনে রাখার প্রয়োজন নেই।

# ~/.omp/agent/config.yml
modelRoles:
  default: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731
  slow: joingonka/zai-org/GLM-5.3-Flash
  plan: joingonka/zai-org/GLM-5.3-Flash
  tiny: joingonka/MiniMaxAI/MiniMax-M2.7

retry:
  fallbackChains:
    default:
      - joingonka/zai-org/GLM-5.3-Flash

retry.fallbackChains ব্লকটি পিক আওয়ারের জন্য একটি বীমা: যখন মূল মডেল ক্রমাগত ৪২৯ এরর দেয়, তখন omp বাকি কাজ চেইনের পরবর্তী এন্ট্রিতে পাঠিয়ে দেয় এবং বিরতির পর মূল মডেলে ফিরে আসে। চেইনের কি হতে পারে একটি ভূমিকা, নির্দিষ্ট মডেল অথবা পুরো প্রোভাইডার (joingonka/*)।

একটি রান-এর জন্য ভূমিকা ফ্ল্যাগ দিয়ে ওভাররাইড করা যায়: omp --model slow সেশনটিকে slow ভূমিকা মডেলে চালায়, আর --smol, --slow, এবং --plan মূল ভূমিকাকে প্রতিস্থাপন করে। সেশনের ভেতরে Ctrl+P দিয়ে ভূমিকা মডেলগুলো পরিবর্তন করা যায়, এবং /model দিয়ে নির্বাচন করা যায়; Roles ট্যাবে ভূমিকা এবং সেগুলোর বিকল্প নির্ধারণ করা যায়।

ভূমিকার মানের সাথে চিন্তার স্তর যোগ করা যায় — :low, :medium, :high। এটি omp সিনট্যাক্স, আর নির্দিষ্ট মডেল কীভাবে এই স্তর বোঝে তা সেই মডেলের ওপর নির্ভর করে: উদাহরণস্বরূপ, GLM-5.3 Flash এর জন্য এটি একটি বাইনারি সুইচ — বিস্তারিত মডেল রিভিউতে দেখুন। আরেকটি দরকারী তথ্য: <repo>/.omp/config.yml ফাইলের মাধ্যমে একটি রিপোজিটরির জন্য ভূমিকাগুলো নতুন করে নির্ধারণ করা যায়, যাতে একই modelRoles ব্লক থাকে। এক্ষেত্রে প্রোভাইডার এবং কি (key) গুলো হোম ডিরেক্টরিতেই থাকে, যাতে কি রিপোজিটরিতে চলে না যায়।

প্রথমে নিশ্চিত করুন যে omp প্রোভাইডারটি দেখতে পাচ্ছে:

omp models joingonka

উত্তরে তিনটি সারির একটি টেবিল আসে, যেখানে কনটেক্সট উইন্ডো ও উত্তরসীমা models.yml থেকে নেওয়া এবং হাজারে রাউন্ড করা (আউটপুট সংক্ষিপ্ত: omp-তে thinking ও images কলামও আছে):

joingonka (3)
model                                context  max-out
deepseek-ai/DeepSeek-V4-Flash-0731      380K      33K
MiniMaxAI/MiniMax-M2.7                  200K     8.2K
zai-org/GLM-5.3-Flash                   390K     8.2K

এরপর — ইন্টারফেস ছাড়া একবার চালিয়ে দেখুন। একটি খালি ডিরেক্টরিতে স্পষ্ট একটি বাগসহ ফাইল রাখুন এবং সেটি খুঁজে বের করতে বলুন:

omp -p "Read calc.py and tell me in one sentence whether it has a bug."

এজেন্টের নিজে থেকেই পড়ার টুল কল করতে হবে এবং সারমর্ম অনুযায়ী উত্তর দিতে হবে — যে এক্সপ্রেশনে বাগ আছে তা উল্লেখ করে। ২১ সেপ্টেম্বর ২০২৬-এ আমাদের রানে এই চক্র — অনুরোধ, টুল কল, ফলাফল, উত্তর — DeepSeek V4 Flash এবং GLM-5.3 Flash পরিষ্কারভাবে পেরেছে; MiniMax M2.7 সম্পর্কে — নিচের টেবিলের শেষ সারিতে।

তৃতীয় যাচাই — গেটওয়ে থেকে: ড্যাশবোর্ডের "Usage" সেকশনে অনুরোধটি "By models" ভাগে দেখা যাবে, আর "By keys" ব্লকে শেষ অনুরোধের সময় আপডেট হবে। সেখানে খালি থাকলে omp অন্য প্রোভাইডারে যাচ্ছে: দেখে নিন রোলে কী সেট আছে, omp config get modelRoles কমান্ড দিয়ে।

কোথাও কিছু ভুল হলে, রোগনির্ণয় সাধারণত সরাসরি বার্তা থেকেই পড়া যায়:

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

JoinGonka Gateway-এর মাধ্যমে টোকেনের দাম প্রতি মিলিয়নে ইনপুট $0.0069 এবং আউটপুট $0.021 — এই দাম নেটওয়ার্কের সমস্ত মডেলের জন্য একই এবং এই পৃষ্ঠায় সরাসরি উৎস থেকে আপডেট হয়।

ডানদিকের কলামের অনুমানগুলো ২০২৬ সালের সেপ্টেম্বর মাসের দামের ওপর ভিত্তি করে। তুলনা করার জন্য — omp-এ মডেলের জন্য যেভাবে পেমেন্ট করা যায়:

omp স্ট্যাটাস বার সেশনের খরচ দেখায়। এটি models.yml-এর cost ফিল্ড অনুযায়ী হিসাব করা হয়: ইনস্টলার সেখানে ইনস্টলেশনের সময় গেটওয়ের দাম লিখে দেয়, এবং নেটওয়ার্কে ডলারের দাম GNK রেটের সাথে পরিবর্তিত হয়, তাই এই হিসাবটি একটি নির্দেশক মাত্র। সঠিক খরচ এবং ব্যালেন্স ড্যাশবোর্ডের «ব্যবহার» (Usage) এবং «বিলিং» (Billing) বিভাগে দেখুন। কেন ডিফল্ট হিসেবে DeepSeek V4 Flash বেছে নেওয়া হয়েছে, তা মডেলের পর্যালোচনায় বিস্তারিত ব্যাখ্যা করা হয়েছে।

অনুমোদনের মোড। ডিফল্টভাবে omp yolo মোডে চলে: পড়া, লেখা এবং কমান্ড চালানো নিজেই অনুমোদন করে। নিজের প্রজেক্টে এটি সুবিধাজনক, কিন্তু অন্যের কোডে এটি মোড কঠোর করার বা কন্টেইনারে যাওয়ার কারণ:

omp config set tools.approvalMode write

write মোডে এজেন্ট শুধু কমান্ড চালানোর অনুমতি চায়, always-ask-এ লেখার জন্যও চায়। একটি রানের জন্য একই কাজ করে --approval-mode ফ্ল্যাগ। এটি omp-এর নিজস্ব বৈশিষ্ট্য, মডেল প্রোভাইডারের উপর নির্ভর করে না।

Pi এবং omp — ভিন্ন কনফিগের আত্মীয়। এক টুলের সেটিংস অন্যটিতে যায় না: তাদের ডিরেক্টরি, ফরম্যাট ও ফিল্ডের নাম আলাদা।

একাধিক এনভায়রনমেন্ট। নামযুক্ত প্রোফাইল (omp --profile work বা OMP_PROFILE ভেরিয়েবল) সব সেটিংস ~/.omp/profiles/<name>/agent-এ নিয়ে যায় — কাজের ও ব্যক্তিগত কী আলাদা রাখার জন্য সুবিধাজনক। বর্তমান এজেন্ট ডিরেক্টরি প্রিন্ট করে omp config path।

এডিটরে এজেন্ট দরকার হলে। omp ACP প্রোটোকলের মাধ্যমে Zed-এর ভিতরে কাজ করতে পারে — এটি একই এজেন্ট, একই সেটিংস, দ্বিতীয়বার প্রোভাইডার ও রোল সেট করার দরকার নেই।