Graft: coding agents साठी codebase map

कोडिंग एजंटसाठी codebase map म्हणजे काय

कोडिंग एजंटसाठी codebase map हा तुमच्या repository चा कायमस्वरूपी index असतो. प्रत्येक नवीन session मध्ये सुरुवातीपासून grep करण्याऐवजी एजंट या index मधून आवश्यक माहिती शोधतो. Graft हे या संकल्पनेचे एक implementation आहे. ते tree-sitter वापरून तुमचा code parse करते, परस्पर जोडलेल्या markdown nodes चे folder आणि प्रत्येक symbol साठी wiring graph तयार करते. तसेच MCP (model context protocol, coding agents बाहेरील tools कॉल करण्यासाठी वापरत असलेला standard interface) द्वारे retrieval tools उपलब्ध करून देते.

Graft हा proxy नाही आणि gateway देखील नाही. तुमचा agent आणि model API यांच्या मध्ये कोणताही घटक बसत नाही. Map हा disk वरील एक folder असतो, जो agent वाचतो. या फरकामुळे तुम्ही कोणती समस्या सोडवत आहात हे ठरते: self-hosted token gateway तुम्ही आधीच पाठवत असलेल्या requests चे मोजमाप आणि routing करते, तर map मुळे एकूण किती requests पाठवाव्या लागतात ते बदलते.

ही technique या tool पेक्षा जुनी आहे आणि या tool नंतरही वापरली जाईल. आधी technique समजून घ्या. त्यानंतर mechanics समजून घ्या.

कोडिंग agents रचना पुन्हा शोधण्यात context का खर्च करतात

एखादा agent आधीच पन्नास वेळा पाहिलेल्या repository वर काम सुरू करताना पाहा. तो directories ची यादी करतो. एखाद्या symbol साठी grep चालवतो. function कुठे define केले आहे हे शोधण्यासाठी तीन files उघडतो आणि ते कोण call करते हे समजण्यासाठी चौथी file उघडतो. यापैकी काहीही task नाही. ही फक्त orientation आहे आणि प्रत्येक session मध्ये तिची किंमत input tokens मध्ये मोजावी लागते.

याचे कारण सोपे आहे. Sessions दरम्यान model कडे memory नसते. तुमच्या layout विषयी agent ने शिकलेली प्रत्येक गोष्ट session संपल्यावर discard झालेल्या context window मध्येच असते. त्यामुळे तेच discovery पुन्हा zero पासून आणि पूर्ण खर्चाने सुरू होते. मोठ्या repository मध्ये orientation phase ची किंमत edit पेक्षा जास्त असते: code शोधण्यासाठी दहा tool calls आणि बदल करण्यासाठी एक. त्या खर्चाचा एक भाग orientation आणि दुसरा भाग edit असतो. म्हणून agent ला कार्य करणारा सर्वात लहान बदल करण्यास बांधून ठेवणारे skill आणि map यांपैकी एक निवडण्याऐवजी दोन्ही एकत्र वापरणे उपयुक्त ठरते.

Map discovery चे काम model कडून disk कडे हलवून हा पुनरावृत्तीचा चक्र थांबवतो. Parser repository मधून एकदा फिरतो, कोणता symbol कुठे define केला आहे आणि कोणता symbol कोणाला call करतो हे नोंदवतो, आणि code बदलत असताना ही नोंद अद्ययावत ठेवतो. Agent एक प्रश्न विचारतो आणि त्याला file आणि line क्रमांकासह उत्तर मिळते. वारंवार करावी लागणारी exploration स्वस्त lookup मध्ये बदलते.

तुम्ही याची कमकुवत आवृत्ती आधीच वापरत आहात. तुमच्या conventions सांगणारी AGENTS.md agent ला प्रत्येक वेळी त्या conventions पुन्हा शोधण्यापासून थांबवते. Generated map त्याला तुमची structure पुन्हा शोधण्यापासून थांबवतो. फरक एवढाच की ते कोण लिहिते. Instruction file तुम्ही स्वतः लिहिता, त्यामुळे ती लहान राहते. Parser map generate करतो, त्यामुळे ती दहा हजार files व्यापू शकते. Session मध्ये budget नेमका कुठे खर्च होतो यासाठी Claude Code त्याची context window कशी वापरतो हे accounting स्पष्ट करते.

Graft प्रत्यक्षात काय तयार करते

संग्रहाच्या root मध्ये असलेल्या एका graft/ folder अंतर्गत दोन artefacts तयार होतात.

पहिला artefact linked markdown म्हणून लिहिलेला node graph आहे. प्रत्येक node साठी एक file असते. प्रत्येक node मध्ये साध्या इंग्रजीतील summary, source मधून घेतलेल्या महत्त्वाच्या logic lines चा "crux", content hash सह अचूक source files, इतर nodes कडे निर्देश करणाऱ्या typed wikilinks (depends_on, part_of, uses, implements) आणि regeneration नंतरही टिकून राहणारा notes section असतो. parser ला अनुमान करता न येणारा context या section मध्ये नोंदवता येतो.

दुसरा artefact म्हणजे graft/.graph/wiring.json. हा tree-sitter ने काढलेला प्रत्येक symbol चा structural graph आहे. त्यात definitions, references आणि symbols मधील call edges असतात.

हा विभाग महत्त्वाचा आहे, कारण या दोन भागांपैकी फक्त एका भागासाठी model आवश्यक आहे. graft build पूर्णपणे tree-sitter वर आधारित आहे आणि LLM (large language model) ला कधीही call करत नाही. त्यामुळे त्याचे परिणाम deterministic असतात आणि कोणताही खर्च होत नाही. graft build --deep मध्ये लिखित summaries आणि प्रत्येक symbol चे cruxes जोडले जातात. त्यासाठी model calls लागतात आणि त्यांचा खर्च होतो.

Language support चे tiers आहेत. त्यामुळे call graph वर कितपत विश्वास ठेवायचा हे tier वरून समजते. TypeScript, JavaScript, Python, Go आणि Java साठी scope-aware cross-file resolution मिळते. Rust, C, C++, C#, Ruby, PHP, Kotlin, Scala, Swift, Elixir, Solidity, OCaml, Zig आणि Dart साठी symbols तसेच generic call edges मिळतात. याचा अर्थ edge हा resolved reference ऐवजी name match असू शकतो. Compiler-grade edges मिळवण्यासाठी --lsp आणि rust-analyzer किंवा gopls सारखा language server opt-in पद्धतीने वापरावा लागतो.

Graft स्थापित करा आणि आवृत्ती निश्चित करा

Graft साठी Node.js 20 किंवा त्यानंतरची आवृत्ती आवश्यक आहे आणि त्याचा परवाना MIT आहे. August 2026 पर्यंतची सध्याची आवृत्ती 0.10.1 आहे आणि पहिली प्रकाशित आवृत्ती 0.1.0 July 2026 मधील आहे. हे नवीन सॉफ्टवेअर समजा.

npm install -g @nanonets/graft@0.10.1
npm ls -g @nanonets/graft

npm ls -g ने @nanonets/graft@0.10.1 दाखवले पाहिजे. ही आवृत्ती जाणीवपूर्वक निश्चित करा. साधे npm install -g @nanonets/graft तुम्ही ते चालवता त्या क्षणी latest tag सोडवते. महिन्याला अनेक minor releases प्रकाशित करणाऱ्या प्रकल्पात यामुळे तुमच्या सहकाऱ्याने Monday रोजी स्थापित केलेल्या साधनापेक्षा तुमच्याकडे Tuesday रोजी वेगळे साधन असू शकते. निश्चित केलेली आवृत्ती सर्वांसाठी CLI flags आणि graph format समान ठेवते. त्यामुळे upgrade कधी करायचे हे तुम्ही ठरवू शकता.

त्यानंतर ते तुमच्या मालकीच्या repository मध्ये जोडा:

cd /path/to/your/repo
graft init --dry-run
graft init

graft init तुमच्या coding agents पैकी कोणाशी wiring करायची हे विचारते आणि त्यानंतर graph तयार करते. आधी --dry-run चालवा आणि ते बदलणार असलेल्या files ची यादी वाचा, कारण त्यांपैकी काही repository च्या बाहेर असू शकतात. graft init idempotent आहे आणि विद्यमान configs overwrite करत नाही. त्यामुळे ते दुसऱ्यांदा चालवणे सुरक्षित आहे.

August 2026 पर्यंत ही wiring Claude Code, Cursor, Codex, GitHub Copilot, Google Gemini, Kiro, Windsurf आणि AdaL यांना समर्थन देते. Claude Code साठीचे integration सर्वाधिक सखोल आहे: MCP server entry, graph चा आकार आणि staleness दाखवणारी statusline, graph पुन्हा तयार करणारे post-edit hooks आणि .claude/ अंतर्गत skill file. इतर agents साठी tools उपलब्ध असल्याचे सांगणारी instruction किंवा rule file तयार केली जाते. त्यामुळे "Supported" याचा अर्थ Graft wiring लिहिते असा आहे. एखादा agent स्वतःची rules file वाचत नसेल, तर तो map देखील वापरणार नाही. तुम्ही त्यांच्यासाठी लिहिलेल्या सूचनांकडे agents दुर्लक्ष करतात, याचे हे नेहमीचे कारण आहे आणि येथेही तेच लागू होते.

तुमच्या repository मध्ये काय येते आणि git मध्ये काय येत नाही

graft init नंतर पुढील बदल अपेक्षित आहेत:

• graft/: markdown node graph आणि graft/.graph/wiring.json. हे तुमच्यासाठी .gitignore मध्ये जोडले जाते.
• .mcp.json: graft MCP server नोंदवतो, त्यामुळे Claude Code ते सुरू करतो.
• .claude/settings.json: योग्य ठिकाणी merge केला जातो आणि statusline तसेच post-edit hooks जोडतो.
• AGENTS.md, GEMINI.md, .github/copilot-instructions.md, .cursor/rules/graft.mdc, .kiro/steering/graft.md, .windsurf/rules/graft.md आणि .adal/skills/graft/SKILL.md: तुम्ही निवडलेल्या agents शी जुळणाऱ्या फाइल्समध्ये marker-fenced sections म्हणून जोडले जातात.
• ~/.codex/config.toml, ~/.codex/hooks.json आणि ~/.codex/hooks/graft/graft-hooks.cjs: machine-wide असतात आणि तुम्ही Codex निवडल्यावरच लिहिले जातात. graft init --no-global ते वगळतो आणि graft init --no-hooks स्वतंत्रपणे hook shim वगळतो.

Graph हा node_modules प्रमाणे cache आहे. तो commit करू नका. तो code मधून काही सेकंदांत पुन्हा तयार होतो, जवळजवळ प्रत्येक edit नंतर बदलतो आणि त्याला commit केल्यास एका ओळीतील fix चे रूपांतर शेकडो फाइल्समधील diff मध्ये होते, जे कोणताही reviewer वाचणार नाही. त्याऐवजी wiring commit करा; त्यात AGENTS.md आणि .mcp.json यांचाही समावेश आहे. Teammate repository clone करतो, graft build चालवतो आणि त्याला स्वतःचा local graph मिळतो.

तुमच्या पहिल्या commit पूर्वी ignore rule लागू झाली आहे का ते तपासा:

grep -n graft .gitignore
git status --short

grep ने graft/ असलेली ओळ दाखवली पाहिजे आणि git status --short ने graft/ अंतर्गत काहीही सूचीबद्ध करू नये. त्या output मध्ये graft/ अंतर्गत फाइल्स दिसत असल्यास ignore entry गहाळ आहे किंवा इतरत्र override झाली आहे. Commit करण्यापूर्वी ते दुरुस्त करा, कारण एखादी फाइल एकदा add केल्यानंतर git तिचे tracking सुरू ठेवतो आणि नंतरचा .gitignore edit केल्याने तिचे tracking बंद होत नाही.

तुम्हाला MCP server स्वतः नोंदवायचा असल्यास किंवा तो install केलेल्या त्याच version वर pin करायचा असल्यास, entry लहान आहे:

{
  "mcpServers": {
    "graft": {
      "command": "npx",
      "args": ["-y", "@nanonets/graft@0.10.1", "mcp"]
    }
  }
}

grep ऐवजी तुमचा agent वापरत असलेली retrieval tools

Graft MCP द्वारे सहा tools उपलब्ध करून देते. graft_find_code कार्याच्या वर्णनासाठी ranked nodes परत करते आणि त्यात file व line असतात. graft_file_api एखाद्या file मधील सर्व signatures, bodies शिवाय, परत करते. graft_trace_calls callers किंवा callees यांचा अनेक स्तरांपर्यंत मागोवा घेते. graft_find_all regex hits चे symbol नुसार गट करते. graft_repo_map अपरिचित repository चा प्राथमिक आढावा देते. graft_check_freshness graph अजून code शी जुळतो का ते कळवते.

प्रत्येक tool ची CLI twin देखील आहे. तुमच्या agent ला प्रत्यक्षात काय दिले जात आहे हे तपासण्याचा हाच मार्ग आहे:

graft map .
graft ask "where do we validate the refresh token"
graft skeleton src/auth/session.ts
graft callers validateRefreshToken
graft callers validateRefreshToken --direction out
graft grep "refresh_token" --json

graft ask ने file contents ऐवजी file:line references असलेले ranked nodes दाखवायला हवेत. हीच संपूर्ण यंत्रणा आहे: योग्य file शोधण्यासाठी दहा files वाचण्याऐवजी agent ला एक pointer मिळतो आणि तो एकच file उघडतो. स्वतः graph पाहायचा असल्यास graft viz localhost वर interactive viewer उघडते. तीस सेकंदांत उत्तर देता आले असते अशा प्रश्नासाठी graft ask काहीही उपयुक्त परत करत नसेल, तर graph stale आहे किंवा तुमची language broad tier मध्ये येते. अशा वेळी हा map तुमच्या agent ला देखील मदत करणार नाही.

एक खर्च सहज लक्षात येत नाही. संपूर्ण session मधील प्रत्येक request च्या system prompt मध्ये सहा tool definitions inject केल्या जातात. Agent map वापरो अथवा न वापरो, हा खर्च करावा लागतो. Context मध्ये मावेल इतकी repository लहान असल्यास, ही fixed charge वाचवलेल्या exploration पेक्षा मोठी असू शकते.

कोड बदलल्यावर ग्राफवर काय परिणाम होतो

स्ट्रक्चरल refresh स्वस्त आणि स्वयंचलित असतो. Graft git ऐवजी तुमचा working tree वाचतो. त्यामुळे commit न केलेला edit आणि staged केलेला edit, दोन्ही Graft ला सारखेच दिसतात. Query फक्त stat बदललेल्या फाइल्सचे parsing पुन्हा करते. Project documentation नुसार यासाठी साधारण 3 ms overhead लागतो. Turn-end rebuild फक्त code हलवलेल्या फाइल्सवर प्रक्रिया करते. Disk वरील graph मधून उत्तर देण्यासाठी, पुन्हा parsing न करता, GRAFT_NO_REFRESH=1 सेट करा किंवा --no-refresh पास करा. सर्वकाही पुन्हा सुरुवातीपासून parse करण्यासाठी --no-reuse पास करा. Graft स्वतः upgrade केल्यानंतर हे वापरणे योग्य आहे.

Model ने लिहिलेल्या भागाचे वर्तन वेगळे असते. याच भागात चुका शांतपणे राहतात. Summaries आणि cruxes cache केलेले असतात. प्रत्येक node मध्ये त्याच्या sources चा content hash नोंदवलेला असतो. त्यामुळे source file बदलल्यावर node वर्तमान म्हणून दाखवण्याऐवजी stale म्हणून चिन्हांकित केला जातो. काहीतरी प्रक्रिया त्या चिन्हावर कार्य करत असेल तरच त्याचा उपयोग होतो. graft build --deep वापरून refresh करा. यासाठी model tokens पुन्हा खर्च होतात.

Staleness दृश्यमान करा:

graft check .
echo $?

Exit status 0 म्हणजे graph आणि code जुळतात. Exit status 1 म्हणजे drift आहे. हे pre-push hook मधून किंवा CI मधील branch वर चालवा. त्यामुळे सहा महिन्यांपूर्वीच्या map ला March मध्ये पुन्हा लिहिलेल्या code बद्दल आत्मविश्वासाने उत्तर देता येणार नाही.

प्रकाशित benchmark आकडेवारी काळजीपूर्वक वाचा

Graft चा मुख्य दावा असा आहे: "4x पर्यंत स्वस्त आणि 3x जलद, तसेच correctness मध्ये सुधारणा किंवा कोणतीही घट नाही." हे आकडे प्रकल्पाच्या स्वतःच्या benchmarks मधून आले आहेत. ते त्याच्या README मध्ये प्रकाशित केले आहेत. खाली त्यात नोंदवलेल्या दोन्ही runs ची संपूर्ण माहिती दिली आहे.

[
  {
    "label": "Controlled sweep",
    "run_count": 162,
    "token_saving_pct": 42,
    "tool_call_saving_pct": 46,
    "correctness_pct": 93,
    "baseline_correctness_pct": 93
  },
  {
    "label": "SWE-bench Verified",
    "run_count": 50,
    "token_saving_pct": 23,
    "tool_call_saving_pct": 25,
    "correctness_pct": 66,
    "baseline_correctness_pct": 54
  }
]

नियंत्रित sweep मध्ये दोन repositories वर 162 runs आहेत. त्यापैकी एक repository स्वतः Graft ची आहे. प्रत्येक task साठी तीन trials घेतले आहेत. त्यानुसार tokens मध्ये 42% आणि tool calls मध्ये 46% घट नोंदवली आहे. SWE-bench Verified run मध्ये 50 instances आहेत. दोन्ही बाजूंना तोच model वापरला आहे. त्यात कमी बचत नोंदवली आहे: tokens मध्ये 23% आणि tool calls मध्ये 25%. तिसऱ्या run मध्ये merge केलेल्या पाच PocketBase pull requests पुन्हा चालवण्यात आल्या. त्यांचा खर्च 11.02 US dollars होता, तर baseline चा खर्च 13.91 होता.

या सर्व आकडेवारीकडे vendor benchmark म्हणून पाहा. ती काय सांगू शकते यावर दोन मर्यादा आहेत. नियंत्रित sweep मध्ये Graft चे स्वतःचे repository समाविष्ट आहे. हेच ते codebase आहे ज्यावर त्याच्या लेखकांनी tuning केले आहे. SWE-bench Verified हा सुप्रसिद्ध open-source Python projects मधील issues चा public dataset आहे. कोणाचा तसा हेतू असो वा नसो, tools सामान्यतः public datasets साठी optimise केली जातात. यापैकी कोणतीही आकडेवारी तुमच्या private monorepo बद्दल निष्कर्ष देत नाही. तुमच्या monorepo मध्ये naming conventions वेगळ्या असू शकतात आणि त्यात स्वतःचा dead code असू शकतो.

Correctness कडे पुन्हा लक्ष द्या. नियंत्रित sweep मध्ये त्यात बदल झाला नाही: map सह 93%, तर map शिवाय 93%. 66% वर झालेली वाढ 54% वरून फक्त SWE-bench Verified मध्ये दिसते. एखादे tool तुमचा token खर्च कमी करते आणि quality तशीच ठेवते, तरी तो चांगला trade-off आहे. मात्र SWE-bench मधील correctness result नियंत्रित sweep मधील token result शी जोडू नका आणि दोन्हींचा एकच दावा म्हणून उल्लेख करू नका.

तुमच्या स्वतःच्या token delta चे मोजमाप केल्याशिवाय यावर विश्वास ठेवू नका

महत्त्वाचा एकच आकडा आहे: तुमच्या repository मधून मिळणारा आकडा. ही पद्धत पूर्ण करण्यासाठी एका दुपारचा वेळ लागतो.

तुम्ही अगदी त्याच पद्धतीने पुन्हा करू शकता असे काम निवडा. edit पेक्षा प्रश्न चांगला असतो, कारण edit मुळे repository बदलते आणि दुसऱ्यांदा चालवलेला प्रयोग तसाच राहत नाही. "login route वर rate limit कोणता module लागू करतो" हा योग्य प्रकारचा प्रश्न आहे.

telemetry सुरू करा आणि ती तुमच्या स्वतःच्या terminal कडे पाठवा:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
claude

console exporter metric records गोळा होताच ते दाखवतो. तुम्हाला claude_code.token.usage हवे आहे. त्यामध्ये type, input, output किंवा cacheRead पैकी एकाचे cacheCreation attribute असते. Orientation input आणि cacheRead मध्ये दिसते, कारण file contents तिथे साठवले जातात. या दोन्हींची बेरीज करा.

map जोडलेले असताना, प्रत्येक वेळी नवीन session वापरून task तीन वेळा चालवा. त्यानंतर .mcp.json मधील graft entry काढून task आणखी तीन वेळा चालवा. एकेका run ऐवजी median ची तुलना करा, कारण agent runs मध्ये मोठा फरक असतो आणि एका अपयशी run मुळे निष्कर्ष सत्याच्या उलट येऊ शकतो. tool-call count देखील नोंदवा. tool calls ही कार्यपद्धती आहे आणि tokens हा परिणाम आहे. त्यामुळे tool calls कमी न होता tokens वाचत असतील, तर दुसऱ्या घटकात बदल झाला आहे.

यानंतर benchmark मध्ये न दिसणारे खर्च वजा करा. graft build --deep प्रत्येक full refresh वर model tokens वापरते. सहा tool schemas प्रत्येक request सोबत पाठवले जातात. तुमचे agents तुम्ही भाड्याने घेतलेल्या server वर चालत असतील, तर agent खर्चावर कमाल मर्यादा घालणे यामुळे हा अनपेक्षित खर्च न राहता budget मध्ये बदलतो. तसेच coding agent ची telemetry प्रत्यक्षात काय नोंदवते हा exporter सुरू केल्यानंतर machine बाहेर काय पाठवले जाते ते स्पष्ट करते.

कोडबेस नकाशा कुठे उपयोगी ठरत नाही?

• रिपॉझिटरी आधीच context मध्ये मावते. एका लहान सेवेसाठी नकाशाची गरज नसते. प्रत्येक request वेळी सहा tool schemas चा अतिरिक्त खर्च तरीही करावा लागतो. आज agent ला कोणतीही file एक किंवा दोन tool calls मध्ये सापडत असेल, तर नकाशा वापरू नका.
• तुमची भाषा broad tier मध्ये आहे. Generic call edges मुळे graft callers एखादा caller शोधण्यात चुकू शकते किंवा name collision मुळे चुकीचा caller देऊ शकते. Blast radius वर विश्वास ठेवण्यापूर्वी graft grep ने पुष्टी करा.
• Graph stale झाला आहे आणि कोणाच्याही लक्षात आलेले नाही. Drift आढळल्यास graft check exit status 1 देते. मात्र ते चालवणारी यंत्रणा असेल तरच त्याचा उपयोग होतो. यासाठी hook किंवा CI step वापरा; मानवी सवयीवर अवलंबून राहू नका.
• Monorepo साठी scope ठरवणे आवश्यक आहे. Single-git monorepo चे workspace file, go.mod, pyproject.toml किंवा Cargo.toml नुसार आपोआप विभाजन होते. graft ask "..." --in services/billing/ query एका sub-project पुरती मर्यादित करते. प्रत्येक package साठी nested AGENTS.md files ठेवण्यामागील हाच विचार नकाशालाही लागू होतो.
• Agent wiring कडे दुर्लक्ष करते. नकाशा वापरला जात आहे असे निष्कर्ष काढण्यापूर्वी प्रत्यक्ष session मधील tool calls पहा. Agent अजूनही grep चालवत असेल, तर त्याने rules file वाचलेली नाही हे स्पष्ट आहे.

FAQ

graft/ folder git मध्ये commit करावी का?

नाही. graft build तुमच्या .gitignore मध्ये graft/ आपोआप जोडते, कारण हा graph node_modules प्रमाणे पुन्हा निर्माण करता येणारा cache आहे. प्रत्येक edit नंतर तो जवळजवळ बदलतो, त्यामुळे commit केल्यास शेकडो generated files मुळे वास्तविक diffs दिसेनासे होतात. Agents ना map उपलब्ध आहे हे सांगणारी wiring commit करा. त्यात AGENTS.md आणि .mcp.json यांचा समावेश आहे. प्रत्येक teammate ने graft build स्थानिक पातळीवर चालवावे. पहिल्या commit पूर्वी grep -n graft .gitignore आणि git status --short वापरून पडताळणी करा. एखादी file एकदा add केल्यानंतर git तिचा मागोवा ठेवते. त्यानंतर .gitignore edit केल्याने तिचा मागोवा बंद होत नाही.

Graft चालवण्यासाठी पैसे लागतात का?

Structural भागासाठी पैसे लागत नाहीत. graft build, graft ask, graft check आणि सहा MCP retrieval tools ही tree-sitter operations आहेत. ती कधीही model ला call करत नाहीत. graft build --deep हा paid भाग आहे. तो LLM च्या माध्यमातून plain-English summaries आणि per-symbol cruxes लिहितो. त्यासाठी GRAFT_PROVIDER, GRAFT_API_KEY आणि GRAFT_MODEL configure केलेले असतात. OpenAI-compatible endpoint साठी GRAFT_BASE_URL देखील वापरले जाते. तुम्ही Graft केवळ structure सह चालवू शकता. Graph साठी एकही token खर्च करण्याची गरज नाही.

माझ्या repository वर codebase map प्रत्यक्षात किती बचत करेल?

मोजमाप केल्याशिवाय कोणीही सांगू शकत नाही. स्वतःच्या 162-run sweep मध्ये project ने 42% कमी tokens नोंदवले. SWE-bench Verified वर ही बचत 23% होती. दोन्ही निकाल map नसलेल्या baseline शी तुलना करून मिळवले आहेत. हे vendor benchmarks आहेत. त्यापैकी एक benchmark अंशतः Graft च्याच repository वर चालवला गेला. कोणताही benchmark तुमच्या private code चे वर्णन करत नाही. एकच repeatable question map सह तीन वेळा आणि map शिवाय तीन वेळा चालवा. त्यावेळी CLAUDE_CODE_ENABLE_TELEMETRY=1 आणि OTEL_METRICS_EXPORTER=console set असावेत. नंतर input आणि cacheRead प्रकारांसाठी claude_code.token.usage च्या median ची तुलना करा.

मी refactor केल्यावर graph चे काय होते?

Structure स्वतः पुन्हा parse होते. Graft working tree चे stats घेते आणि बदललेल्या files पुन्हा parse करते. त्यामुळे rename पुढील query वेळी सुमारे 3 ms overhead सह आढळते. ते uncommitted work देखील पाहते, कारण ते git history ऐवजी files वाचते. Model ने लिहिलेली summaries मात्र stale होतात. प्रत्येक node मध्ये त्याच्या sources चा content hash साठवलेला असतो. Source बदलल्यास node पुन्हा लिहिला जात नाही; त्याऐवजी तो stale म्हणून चिन्हांकित केला जातो. Drift पाहण्यासाठी graft check . चालवा. Written भाग refresh करण्यासाठी graft build --deep चालवा.

आज कोणते coding agents Graft वापरू शकतात?

August 2026 पर्यंत graft init Claude Code, Cursor, Codex, GitHub Copilot, Google Gemini, Kiro, Windsurf आणि AdaL यांच्यासाठी wiring करते. Claude Code ला सर्वाधिक integration मिळते: .mcp.json मधील MCP server entry, statusline, post-edit hooks आणि .claude/ अंतर्गत skill file. Codex ला AGENTS.md section तसेच ~/.codex/ अंतर्गत machine-wide entries मिळतात. graft init --no-global या entries वगळते. इतर agents ना rules किंवा steering file मिळते. इतर कोणताही MCP client npx -y @nanonets/graft@0.10.1 mcp command register करून server थेट वापरू शकतो.