हमारे AI रिव्यूअर के पहले संस्करण ने एक-लाइन के कॉन्फ़िग बदलाव पर 14 "गंभीर" समस्याएँ चिह्नित कीं। बारह काल्पनिक थीं। एक असली टाइपो थी। और एक सच्चा बग था जिसे और किसी ने नहीं पकड़ा था। यही अनुपात — बारह बनावटी बातों के नीचे दबा एक सिग्नल — ठीक वही कारण है जिससे अधिकांश टीमें एक हफ़्ते में बॉट बंद कर देती हैं और दोबारा कभी चालू नहीं करतीं।

हमें वह बॉट नहीं चाहिए था। हमें एक दूसरा रिव्यूअर चाहिए था जो कभी थके नहीं, पर हवा से कोई समस्या भी न गढ़े। एक रिव्यूअर जो हमारे असली टेस्ट सुइट को चलाए, अनुमान न लगाए, जो पाया उसे एक ही बार कमेंट करे, और जिसकी लागत पूर्वानुमेय हो। यह वह सेटअप है जो कुछ शर्मिंदा करने वाली इटरेशनों के बाद हमारे CI में सचमुच टिका रहा।

यहाँ सब कुछ ओपन सोर्स पर चलता है: Octomind, सेशन-आधारित एजेंट, और octomind-action, वह GitHub Action जो इसे लपेटता है। कोई SaaS रिव्यूअर नहीं, कोई प्रति-सीट कीमत नहीं, और आपके रनर से कोड कहीं नहीं जाता सिवाय उस मॉडल प्रोवाइडर के जिसे आप पहले से ही भुगतान करते हैं।

SaaS बॉट की जगह "सेल्फ-होस्टेड AI रिव्यूअर" क्यों

आज होस्टेड AI कोड-रिव्यू उत्पादों का एक स्वस्थ बाज़ार है। वे काम करते हैं। पर CI में AI कोड रिव्यू के लिए, तीन बातों ने हमें अपनी ही GitHub Actions के भीतर चलने वाले एक सेल्फ-होस्टेड AI रिव्यूअर की ओर धकेला:

  1. रिव्यूअर को हमारी कमांड्स चलानी चाहिए, हमारी कमांड्स का उसका अनुमान नहीं। एक होस्टेड बॉट डिफ़ पढ़ता है। वह हमारे सटीक lint कॉन्फ़िग के साथ cargo clippy --all-targets नहीं चलाता, न ही सही feature flags के पीछे हमारा इंटीग्रेशन सुइट। एक रिव्यूअर जो प्रोजेक्ट की असली जाँचें नहीं चला सकता, टेक्स्ट पर पैटर्न-मैचिंग तक सिमट जाता है — और ठीक यहीं से हैल्यूसिनेशन आते हैं।
  2. एजेंट उसी रनर पर चलता है जिस पर हम पहले से भरोसा करते हैं। वही checkout, वही सीक्रेट सीमा, वही नेटवर्क egress नियम। डिफ़ का कुछ भी वहाँ नहीं जाता जिसे हमने पहले से अधिकृत न किया हो।
  3. यह रेपो में एक कॉन्फ़िग फ़ाइल है, किसी भी अन्य की तरह रिव्यू की गई। रिव्यूअर का व्यवहार एक workflow YAML और वर्शन कंट्रोल में पड़े कुछ .agents/tools/ स्क्रिप्ट हैं। जब वह शोरगुल वाला हो जाए, आप इसे एक PR में ठीक करते हैं। जब कोई नया व्यक्ति पूछे "बॉट असल में जाँचता क्या है", तो जवाब है git log।

अगर आपने हमारा पहले का लेख पढ़ा हो कि क्यों कस्टम MCP आपके रेपो में रहते हैं, तो यह वही दर्शन है CI की ओर तानी हुई: जो टूलिंग आपके एजेंट को चलाती है वह उसी कोड के बगल में रहती है जिस पर वह काम करती है।

octomind run non-interactive रूप से कैसे व्यवहार करता है

सब कुछ एजेंट के बारे में एक तथ्य से शुरू होता है: octomind run उसी क्षण non-interactive मोड में चला जाता है जब आप उसे --format देते हैं या उसे stdin पाइप करते हैं। CLI परिभाषा से:

--format <FORMAT>   Output format: plain or jsonl. When set, runs
                    non-interactively (reads input from stdin).

भीतर, रनटाइम फ़्लैग से और इस आधार पर कि stdin टर्मिनल है या नहीं, एक output मोड तय करता है:

कॉल मोड
टर्मिनल में octomind run Interactive (प्रॉम्प्ट, रंग, एनिमेशन)
echo "..." | octomind run (पाइप किया हुआ) NonInteractive
octomind run --format plain NonInteractive
octomind run --format jsonl Jsonl (प्रति लाइन एक JSON ऑब्जेक्ट)

CI पाइप वाला मामला है, और --format jsonl वही है जो आपको वहाँ चाहिए। यह इंटरैक्टिव सजावट दबा देता है और संरचित इवेंट्स की एक धारा उत्सर्जित करता है — असिस्टेंट संदेश, एक अंतिम लागत इवेंट — जिसे workflow गद्य खुरचे बिना पार्स कर सकता है। यही पूरी वजह है कि एजेंट ऑटोमेटेबल है: कोई छिपा प्रॉम्प्ट किसी इंसान के y दबाने का इंतज़ार नहीं करता।

आप इसे हाथ से चलाकर देख सकते हैं:

echo "Review the staged diff and report only real defects." \
  | octomind run developer:rust --format jsonl

अंतिम assistant इवेंट रिव्यू का टेक्स्ट लाता है; एक अनुगामी cost इवेंट टोकन और डॉलर का कुल योग लाता है। यह वही धारा है जिसे GitHub Action पार्स करता है।

Action, और उसके असली inputs

octomind-action दो प्रवेश-बिंदु देता है। हम अलग-अलग कामों के लिए दोनों इस्तेमाल करते हैं:

  • muvon/octomind-action@v1 (muvon/octomind-action/run@v1 का उपनाम) एक प्रॉम्प्ट से एकल octomind run सेशन चलाता है।
  • muvon/octomind-action/workflow@v1 एक TOML फ़ाइल से बहु-चरणीय octomind workflow चलाता है।

कोड रिव्यू के लिए, एकल-सेशन वाला run काफ़ी है। ये इसके असली inputs हैं — action.yml से कॉपी किए गए, गढ़े नहीं गए:

Input डिफ़ॉल्ट क्या करता है
prompt (अनिवार्य) octomind को भेजा गया कार्य/संदेश
role कॉन्फ़िग डिफ़ॉल्ट रोल/एजेंट टैग, जैसे developer:rust
model — मॉडल ओवरराइड, जैसे openrouter:anthropic/claude-sonnet-5
name — नामित सेशन (बनाएँ या फिर से शुरू करें)
resume — एक नामित सेशन फिर से शुरू करें
resume_recent false cwd के लिए सबसे हालिया सेशन फिर से शुरू करें
sandbox false फ़ाइल-सिस्टम लेखन को वर्किंग डायरेक्टरी तक सीमित करें
version latest इंस्टॉल करने के लिए Octomind संस्करण
tap — चलाने से पहले एक tap जोड़ें
config — octomind कॉन्फ़िग फ़ाइल का पथ
comment none PR कमेंट मोड: full, compact, या none
github_token ${{ github.token }} PR कमेंट पोस्ट करने के लिए टोकन

और outputs जिन्हें आप बाद के चरणों में पढ़ सकते हैं:

Output क्या लाता है
result अंतिम असिस्टेंट संदेश (रिव्यू स्वयं)
session_id सेशन ID, बाद के चरण में फिर से शुरू करने के लिए
cost {"tokens": N, "cost": N}
raw_output पूरी JSONL धारा
exit_code प्रक्रिया एग्ज़िट कोड

इनमें से दो रिव्यूअर के लिए भार-वहन करते हैं। comment: compact रिव्यू को PR पर एक मोड़ने योग्य <details> ब्लॉक के रूप में पोस्ट करता है — एक कमेंट, मोड़ने योग्य, लागत एक <sub> फ़ुटर में — टेक्स्ट की दीवार के बजाय। और cost आपको हर रिव्यू की कीमत लॉग में डालने देता है, जो सुनने में जितना लगता है उससे ज़्यादा मायने रखता है।

टीम के असली lint और test को .agents/tools/ के ज़रिए जोड़ना

यही वह हिस्सा है जिसने "सचमुच टिका रहा" को "एक हफ़्ते में बंद" से अलग किया। एक रिव्यूअर जो केवल टेक्स्ट पढ़ता है, समस्याएँ गढ़ता है क्योंकि टेक्स्ट ही उसके पास सब कुछ है। उसे आपकी असली जाँचें चलाने की क्षमता दें और वह अनुमान लगाना बंद कर देता है।

Octomind प्रोजेक्ट-लोकल टूल्स को <workdir>/.agents/tools/<name> पर खोजता है — shebang स्क्रिप्ट जिनका कमेंट हेडर एक टूल स्कीमा बन जाता है। वे मॉडल को एक local MCP सर्वर के रूप में दिखते हैं, कोई अलग सर्वर प्रोसेस नहीं, कोई रजिस्ट्रेशन नहीं। हमने यांत्रिकी को कस्टम MCP आपके रेपो में रहते हैं में कवर किया था; यहाँ CI-संगत बात है: जो स्क्रिप्ट आपके डेवलपरों के एजेंट लोकल रूप से इस्तेमाल करते हैं, वही रिव्यू एजेंट CI में चलाता है, क्योंकि वे रेपो में कमिट हैं।

तो हमने टीम की सटीक कमांड्स को नामित टूल्स के पीछे रखा।

.agents/tools/lint:

#!/usr/bin/env bash
# @description Run the project linter exactly as CI does. Returns warnings and errors.
set -euo pipefail
cd "$OCTOMIND_WORKDIR"
cargo clippy --all-targets --all-features -- -D warnings

.agents/tools/test:

#!/usr/bin/env bash
# @description Run the test suite. Defaults to the fast unit set.
# @param scope string One of: unit, all (default: unit)
set -euo pipefail
cd "$OCTOMIND_WORKDIR"
scope="${OCTOMIND_PARAM_SCOPE:-unit}"
case "$scope" in
  unit) cargo test --lib ;;
  all)  cargo test --all-targets ;;
  *) echo "Unknown scope: $scope" >&2; exit 2 ;;
esac

अब रिव्यूअर का प्रॉम्प्ट कह सकता है "lint और test चलाओ, और केवल उन दोषों की रिपोर्ट करो जिन्हें तुम प्रमाणित कर सको"। एजेंट नामित टूल को कॉल करता है, एक असली एग्ज़िट कोड और असली आउटपुट पाता है, और अपने रिव्यू को इस पर आधारित करता है कि प्रोजेक्ट वास्तव में क्या करता है। "यह clippy में फ़ेल होगा" जैसा दावा अब अनुमान नहीं रहा — एजेंट ने clippy चलाया। अगर clippy पास हुआ, तो वह दावा कभी लिखा ही नहीं जाता।

हैल्यूसिनेटेड-समस्या वाली फ़ेल्योर मोड के ख़िलाफ़ यह सबसे बड़ा लीवर है। मॉडल यह भविष्यवाणी करने में बुरा है कि आपका कोड कंपाइल होता है या नहीं। वह उस कमांड के आउटपुट को पढ़ने में बिलकुल ठीक है जिसने इसे कंपाइल किया।

रिव्यूअर को क्या छूने की अनुमति है, इसे सीमित करना

एक रिव्यूअर को पढ़ना, जाँचें चलाना और रिपोर्ट करना चाहिए। उसे फ़ाइलें संपादित नहीं करनी चाहिए, push नहीं करना चाहिए, या PR नहीं खोलने चाहिए। Octomind रोल्स इसे server_refs (रोल कौन-से टूल सर्वर देखता है) और allowed_tools (उनके भीतर कौन-से टूल) से नियंत्रित करते हैं। आकार, साथ आने वाले रोल टेम्पलेट्स से:

[[roles]]
name = "reviewer:strict"
system = """
You are a code reviewer. Run the project's lint and test tools to ground
every claim. Report only defects you can substantiate with tool output or a
specific line. If you find nothing, say so in one sentence. Never edit files.
"""
temperature = 0.1

[roles.mcp]
server_refs = ["filesystem"]
allowed_tools = ["view", "lint", "test"]

इसमें कुछ जानबूझकर लिए गए निर्णय हैं। temperature = 0.1 क्योंकि एक रिव्यूअर को नीरस और दोहराने योग्य होना चाहिए, रचनात्मक नहीं। allowed_tools केवल पढ़ने और जाँच वाले टूल सूचीबद्ध करता है — कोई shell लेखन नहीं, कोई संपादन नहीं — ताकि भले ही मॉडल कुछ "ठीक" करने का निर्णय ले, उसके पास ऐसा करने का कोई टूल न हो। और system प्रॉम्प्ट के अंतिम दो वाक्य शोर नियंत्रण हैं: केवल वही रिपोर्ट करो जिसे प्रमाणित कर सको; अगर कुछ न मिले, तो एक वाक्य में कह दो। उस एक निर्देश ने हमारे औसत कमेंट को चौदह "समस्याओं" से, एक साफ़ PR पर, "कोई दोष नहीं मिला" तक ला दिया।

अतिरिक्त बेल्ट-और-सस्पेंडर के लिए, Action का sandbox: true input किसी भी फ़ाइल-सिस्टम लेखन को वर्किंग डायरेक्टरी तक सीमित करता है — तो जिस टूल को सचमुच एक temp फ़ाइल लिखनी हो, वह लिख सकता है, पर कुछ भी checkout से बाहर नहीं जाता।

non-interactive रन में अनुमतियाँ और सुरक्षा

CI में एजेंट को लेकर लोग जिस बात से चिंतित होते हैं वह है अप्रूवल। एक इंटरैक्टिव सेशन में टूल चलने से पहले आपसे पूछा जाता। CI में पूछने के लिए कोई नहीं है, और यही मुद्दा है: non-interactive मोड में कोई y/n गेट नहीं जो जॉब को लटका दे। सुरक्षा लूप में किसी इंसान से नहीं आती — वह लूप के संकीर्ण होने से आती है:

  • रोल का allowed_tools MCP-सर्वर टूल्स की अनुमति-सूची है। रिव्यूअर ऐसा सर्वर टूल कॉल नहीं कर सकता जो सूचीबद्ध न हो — यह एक स्थैतिक सीमा है, रनटाइम में लिया गया कोई निर्णय नहीं जिससे मॉडल को बहलाया जा सके। अपवाद हैं प्रोजेक्ट-लोकल .agents/tools/ स्क्रिप्ट, जो हमेशा उपलब्ध रहती हैं: उनकी सीमा वही है जो आप उस डायरेक्टरी में कमिट करते हैं, और PR रिव्यू उसका हर बदलाव देखता है।
  • sandbox: true लेखन को checkout के भीतर रखता है।
  • सीक्रेट रनर के एनवायरनमेंट में रहते हैं, रेपो में कभी नहीं। .agents/tools/ स्क्रिप्ट एनवायरनमेंट से ACME_TOKEN और साथी पढ़ती हैं; स्क्रिप्ट कमिट है, सीक्रेट एक GitHub Actions सीक्रेट है। अगर कोई सीक्रेट गायब है, तो टूल एक स्पष्ट संदेश के साथ ग़ैर-शून्य कोड पर बाहर निकल जाता है, बजाय कोई परिणाम गढ़ने के।
  • github_token केवल कमेंट करने तक सीमित है। डिफ़ॉल्ट ${{ github.token }} PR कमेंट पोस्ट करता है; इसे मॉडल को टूल के रूप में नहीं सौंपा जाता।

रिव्यूअर का प्रभाव-क्षेत्र है: फ़ाइलें पढ़ना, दो अनुमति-सूची वाली कमांड्स चलाना, एक PR कमेंट लिखना। यह एक ऐसी सीमा है जिस पर आप तर्क कर सकते हैं — जो "मॉडल ने वादा किया कि वह कुछ नहीं छुएगा" से कहीं अधिक है।

वह workflow जो टिका रहा

यह असली रिव्यू जॉब है, पूरी तरह ऊपर के inputs पर आधारित:

name: AI Code Review
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write # needed to post the review comment

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0 # so the agent can diff against the base

      - uses: muvon/octomind-action@v1
        with:
          role: reviewer:strict
          model: openrouter:anthropic/claude-sonnet-5
          sandbox: true
          comment: compact
          prompt: |
            Review the changes on this branch against the base.
            Run the `lint` and `test` tools to ground your findings.
            Report ONLY defects you can substantiate with tool output or a
            specific changed line. Group by severity. If nothing is wrong,
            reply in one sentence. Do not restate the diff.
        env:
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}

निर्णयों पर टिप्पणियाँ:

  • role: reviewer:strict कम तापमान, टूल अनुमति-सूची, और "प्रमाणित करो या चुप रहो" वाला system प्रॉम्प्ट लाता है। प्रॉम्प्ट input कार्य है; रोल व्यक्तित्व और रेलिंग है। इन्हें अलग रखें ताकि अलग-अलग ट्यून कर सकें।
  • model: पिन किया हुआ है, बहकने के लिए नहीं छोड़ा गया। मॉडल पिन करना आपके लागत-नियंत्रण का आधा और आपकी पुनरुत्पादनीयता का अधिकांश है। हम एक Sonnet-श्रेणी मॉडल पर पिन करते हैं और उसे केवल जानबूझकर बदलते हैं।
  • comment: compact प्रति रन एक मोड़ने योग्य कमेंट देता है। synchronize पर (PR में हर push) आपको एक ताज़ा रिव्यू मिलता है बिना थ्रेड के एक स्क्रॉल में बदले।
  • OPENROUTER_API_KEY जॉब को चाहिए एकमात्र सीक्रेट है। Octomind OpenRouter, Anthropic, OpenAI, DeepSeek, Google Vertex, AWS Bedrock और Cloudflare से बात करता है; आपके द्वारा सेट किया गया env वेरिएबल प्रोवाइडर चुनता है।

यही पूरा रिव्यूअर है। एक जॉब, एक Action, दो कमिट किए गए टूल स्क्रिप्ट, एक रोल परिभाषा।

लागत को सीमित रखना

एक एजेंट जो टूल चला सकता है, सिद्धांत रूप में हमेशा के लिए लूप कर सकता है और हमेशा के लिए बिल कर सकता है। व्यवहार में हम इसे कुछ नीरस, प्रभावी लीवरों से सीमित करते हैं:

  • मॉडल पिन करें। एक पिन किया हुआ Sonnet-श्रेणी मॉडल प्रति-टोकन पूर्वानुमेय लागत रखता है। "नवीनतम और बेहतरीन" वही है जिससे आपको एक चौंका देने वाला बिल मिलता है।
  • सही इवेंट्स पर ट्रिगर करें। केवल opened और synchronize। हर कमेंट पर नहीं, ड्राफ़्ट PR पर नहीं (जब चाहें तब if: github.event.pull_request.draft == false से छानें)।
  • cost output पढ़ें और लॉग करें। हर रन cost को {"tokens": N, "cost": N} के रूप में उत्सर्जित करता है। इसे जॉब summary में डालें। एक बार हर रिव्यू की कीमत आपके Actions लॉग में बैठ जाए, तो लागत एक एहसास से एक संख्या बन जाती है जिस पर आप एक सीमा रख सकते हैं।
      - run: echo "Review cost: ${{ steps.review.outputs.cost }}" >> "$GITHUB_STEP_SUMMARY"

सबसे बड़ा लागत-चालक टूल हैं, प्रॉम्प्ट नहीं। एक रिव्यूअर जो हर push पर आपका पूरा इंटीग्रेशन सुइट चलाता है, महँगा है क्योंकि सुइट महँगा है, इसलिए नहीं कि एजेंट है। हमारा test टूल ठीक इसी कारण डिफ़ॉल्ट रूप से तेज़ unit सेट का उपयोग करता है; एजेंट scope: all की ओर केवल तब बढ़ता है जब डिफ़ किसी ऐसी चीज़ को छूता है जो इसकी माँग करती है, और तब भी हम इसे रोल स्तर पर सीमित कर सकते हैं।

ईमानदारी से, अड़चनें

अनिश्चितता (Non-determinism)। एक ही डिफ़ पर दो रन रिव्यू को अलग-अलग शब्दों में लिख सकते हैं, और कभी-कभी एक वह ढूँढ लेता है जो दूसरा नहीं। temperature = 0.1 इसे बहुत घटाता है पर ख़त्म नहीं करता। हल अनिश्चितता का पीछा करना नहीं है — यह AI रिव्यू को कई में से एक सलाहकारी जाँच मानना है। यह अपने आप कभी merge नहीं रोकता। वह एक इंसान और असली CI जाँचें करती हैं।

शोर एक प्रॉम्प्ट समस्या है, मॉडल समस्या नहीं। हमारा पहला रिव्यूअर शोरगुल वाला था क्योंकि हमने उससे "कोड रिव्यू करो" कहा, जिसे एक उत्साही मॉडल "चौदह चीज़ें ढूँढो" के रूप में पढ़ता है। इलाज system प्रॉम्प्ट के दो वाक्य थे: हर दावे को प्रमाणित करो; अगर कुछ न मिले, तो एक वाक्य में कह दो। साथ में टूल — आधा शोर मॉडल का उन परिणामों का अनुमान लगाना था जिन्हें वह बस चला सकता था। अगर आपका रिव्यूअर शोरगुल वाला है, तो मॉडल को दोष देने से पहले प्रॉम्प्ट ठीक करें और उसे जाँचने की क्षमता दें।

टूल आउटपुट में सीक्रेट। एक टूल जो एनवायरनमेंट या विस्तृत लॉग उगलता है, एक सीक्रेट सीधे PR कमेंट में लीक कर सकता है। टूल आउटपुट कसा रखें: lint/test परिणाम लौटाएँ, पूरी दुनिया नहीं। हमने यह तब सीखा जब एक verbose टेस्ट रनर ने रिव्यू बॉडी में एक कनेक्शन स्ट्रिंग echo कर दी। अब टूल परिणाम छापते हैं, एनवायरनमेंट नहीं।

base-ref डिफ़। checkout पर fetch-depth: 0 का उपयोग करें वरना एजेंट बेस ब्रांच से तुलना नहीं कर पाता और पूरी फ़ाइल "रिव्यू" कर बैठता है। सस्ती ग़लती, चिढ़ाने वाला लक्षण।

यह एक दूसरा रिव्यूअर है, वह रिव्यूअर नहीं। जिस दिन आप इस पर भरोसा करने लगें कि यह सब कुछ पकड़ लेगा, वही दिन है जब यह उस एक को चूकता है जो मायने रखता है। यह एक अथक पहला पास है। थके हुए इंसान अभी भी merge के मालिक हैं।

अक्सर पूछे जाने वाले प्रश्न

क्या एजेंट को मेरे रेपो में लेखन-पहुँच चाहिए?

नहीं। रिव्यूअर रोल allowed_tools में केवल पढ़ने और जाँच वाले टूल सूचीबद्ध करता है, sandbox: true किसी भी लेखन को checkout तक सीमित करता है, और github_token केवल कमेंट पोस्ट करने के लिए उपयोग होता है। मॉडल को कभी push या edit टूल नहीं सौंपा जाता।

क्या मैं एक सामान्य के बजाय टीम के असली lint/test चला सकता हूँ?

यही तो पूरी बात है। अपनी सटीक कमांड्स .agents/tools/lint और .agents/tools/test में डालें, उन्हें कमिट करें, और एजेंट उन्हें CI में चलाता है। वही स्क्रिप्ट जो आपके डेवलपरों के लोकल एजेंट उपयोग करते हैं। देखें कस्टम MCP आपके रेपो में रहते हैं।

मैं एक रिव्यू की लागत कैसे पढ़ूँ?

Action एक cost output ({"tokens": N, "cost": N}) और raw_output के ज़रिए पूरी JSONL देता है। cost को $GITHUB_STEP_SUMMARY में echo करें और यह हर रन के लॉग में रहेगा।

अगर मुझे एक बहु-चरणीय पाइपलाइन चाहिए, एक अकेला रिव्यू नहीं?

एक TOML फ़ाइल के साथ muvon/octomind-action/workflow@v1 का उपयोग करें — एक चरण में संदर्भ जुटाएँ, अगले में रिव्यू करें, तीसरे में सारांश। वही प्रोवाइडर env, वही PR-कमेंट प्लंबिंग, साथ में टोकन ख़र्च किए बिना पाइपलाइन को मान्य करने के लिए एक dry_run input।

कौन-से मॉडल प्रोवाइडर काम करते हैं?

जिसे आप पहले से भुगतान करते हैं: OpenRouter, Anthropic, OpenAI, DeepSeek, Google Vertex, AWS Bedrock, Cloudflare। संगत API key को env में सेट करें और model input से मॉडल पिन करें।

बदलाव

एक AI रिव्यूअर के साथ सहज प्रवृत्ति है उसे और होशियार बनाना — बेहतर मॉडल, लंबा प्रॉम्प्ट, और चतुर। जो हमारे लिए सचमुच टिका रहा वह था उसे संकीर्ण और अधिक आधारित बनाना। कम टूल, सभी हमारे। एक कम तापमान। एक system प्रॉम्प्ट जिसका पूरा काम मॉडल को तब तक चुप रखना है जब तक वह बात साबित न कर सके। और असली जाँचें चलाने की क्षमता, ताकि वह cargo clippy के आउटपुट से तर्क करे, न कि इस हुनक से कि cargo clippy क्या कह सकता है।

परिणाम कोई प्रतिभाशाली रिव्यूअर नहीं है। यह एक भरोसेमंद रिव्यूअर है: यह कभी नहीं थकता, हर बार वही जाँचें चलाता है, और — वह हिस्सा जो कमाने में सबसे लंबा लगा — उसने हवा से समस्याएँ गढ़ना बंद कर दिया। इसके इर्द-गिर्द जो व्यापक चीज़ें आईं, उनके बारे में बाक़ी जून 2026 की समीक्षा में है।

इसे पहले एक कम-जोखिम वाले रेपो पर जोड़ें। कुछ रिव्यू देखें। प्रॉम्प्ट दो बार ट्यून करें। फिर इसे आपके PR पर चुपचाप बैठने दें — वह दूसरी जोड़ी आँखें जो कभी नहीं झपकतीं।

— Don

Octomind और octomind-action Apache-2.0 के तहत ओपन सोर्स हैं। अगर आपका रिव्यूअर शोरगुल वाला है, तो इलाज लगभग हमेशा प्रॉम्प्ट और टूल हैं — और अगर नहीं, तो JSONL के साथ एक issue खोलें और हम देखेंगे।