Graft: coding agents కోసం codebase map

కోడింగ్ ఏజెంట్ల కోసం codebase map అంటే ఏమిటి

కోడింగ్ ఏజెంట్ల కోసం codebase map అనేది మీ repository యొక్క స్థిరమైన index. ప్రతి కొత్త session లో మొదటి నుంచి grep చేయడానికి బదులుగా, agent ఈ 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 మధ్య ఏ component కూడా ఉండదు. Map అనేది disk లో ఉన్న ఒక folder; agent దాన్ని చదువుతుంది. ఈ తేడా మీరు పరిష్కరిస్తున్న సమస్యను నిర్ణయిస్తుంది: self-hosted token gateway మీరు ఇప్పటికే పంపుతున్న requests ను కొలిచి route చేస్తుంది, అయితే map ద్వారా అసలు ఎన్ని requests పంపాల్సి ఉంటుందో మారుతుంది.

ఈ technique ఈ tool కంటే పాతది; ఈ tool తర్వాత కూడా కొనసాగుతుంది. ముందుగా technique ను నేర్చుకోండి. తరువాత mechanics ను తెలుసుకోండి.

కోడింగ్ agents నిర్మాణాన్ని మళ్లీ కనుగొనడంలో context ను ఎందుకు ఖర్చు చేస్తాయి

ఒక agent ఇప్పటికే యాభై సార్లు చూసిన repository పై పని ప్రారంభించడాన్ని గమనించండి. అది directories జాబితాను చూపిస్తుంది. ఒక symbol కోసం grep చేస్తుంది. ఆ function ను ఏ file నిర్వచిస్తుందో తెలుసుకోవడానికి మూడు files తెరుస్తుంది. తరువాత దాన్ని ఎవరు call చేస్తున్నారో తెలుసుకోవడానికి నాలుగో file తెరుస్తుంది. ఇవేవీ అసలు task లో భాగం కావు. ఇవి orientation దశలు. ప్రతి session లో వీటి కోసం input tokens ఖర్చవుతాయి.

కారణం సరళమే. Sessions మధ్య model కు memory ఉండదు. మీ layout గురించి agent నేర్చుకున్నదంతా session ముగిసినప్పుడు తొలగించబడే context window లోనే ఉంటుంది. అందువల్ల అదే discovery ప్రక్రియ ప్రతి సారి zero నుంచి, పూర్తి ఖర్చుతో మళ్లీ ప్రారంభమవుతుంది. పెద్ద repository లో orientation దశ edit కంటే ఎక్కువ ఖర్చవుతుంది: code ను గుర్తించడానికి పది tool calls, దాన్ని మార్చడానికి ఒకటి. ఈ ఖర్చులో orientation ఒక భాగం, edit మరో భాగం. అందుకే agent ను పనిచేసే అత్యల్ప మార్పుకే పరిమితం చేసే skill ను map తో జత చేయడం, వాటిలో ఒకదానిని మాత్రమే ఎంచుకోవడం కంటే మెరుగైనది.

Discovery ను model నుంచి disk కు తరలించడం ద్వారా map ఈ పునరావృతాన్ని ఆపుతుంది. ఒక parser repository ను ఒక్కసారి పరిశీలిస్తుంది. ఏ symbol ఎక్కడ నిర్వచించబడిందో, ఏ symbol ను ఏది call చేస్తుందో నమోదు చేస్తుంది. Code మారుతున్నప్పుడు ఆ record ను తాజాగా ఉంచుతుంది. Agent ఒక ప్రశ్న అడిగితే file మరియు line వివరాలతో కూడిన సమాధానం పొందుతుంది. పదేపదే చేసే exploration ఒక తక్కువ ఖర్చు lookup గా మారుతుంది.

మీరు ఇప్పటికే దీనికి బలహీనమైన రూపాన్ని ఉపయోగిస్తున్నారు. మీ conventions ను పేర్కొనే AGENTS.md ప్రతి సారి agent వాటిని మళ్లీ నిర్ధారించకుండా ఆపుతుంది. Generated map మీ structure ను మళ్లీ నిర్ధారించకుండా ఆపుతుంది. తేడా దాన్ని ఎవరు రాస్తారన్నదే. Instruction file ను మీరు స్వయంగా రాస్తారు కాబట్టి అది చిన్నదిగా ఉంటుంది. Map ను parser generate చేస్తుంది కాబట్టి అది పది వేల files ను కూడా కవర్ చేయగలదు. Session లో budget వాస్తవంగా ఎక్కడ ఖర్చవుతుందో తెలుసుకోవడానికి Claude Code తన context window ను ఎలా ఖర్చు చేస్తుంది అనే వివరణ accounting ను అందిస్తుంది.

Graft వాస్తవంగా ఏమి నిర్మిస్తుంది

Repository root లోని ఒకే graft/ folder కింద రెండు artefacts ఉంటాయి.

మొదటిది linked markdown గా రాసిన node graph. ప్రతి node కు ఒక ఫైల్ ఉంటుంది. ప్రతి node లో సాదా ఆంగ్ల సారాంశం, source నుంచి తీసుకున్న ముఖ్యమైన logic lines యొక్క "crux", content hash తో కూడిన ఖచ్చితమైన source files, ఇతర nodes కు typed wikilinks (depends_on, part_of, uses, implements), అలాగే regeneration తర్వాత కూడా నిలిచే notes section ఉంటాయి. Parser గుర్తించలేని సందర్భాన్ని ఇందులో నమోదు చేయవచ్చు.

రెండవది graft/.graph/wiring.json. ఇది tree-sitter extract చేసే per-symbol structural graph. ఇందులో definitions, references, వాటి మధ్య call edges ఉంటాయి.

ఈ విభజన ముఖ్యమైనది, ఎందుకంటే రెండు భాగాల్లో ఒక్కదానికే model అవసరం. graft build పూర్తిగా tree-sitter పై ఆధారపడి ఉంటుంది మరియు ఎప్పుడూ LLM (large language model) ను పిలవదు. అందువల్ల ఇది deterministic గా ఉంటుంది, ఖర్చు ఉండదు. graft build --deep రాసిన summaries మరియు per-symbol cruxes ను జోడిస్తుంది. వీటి కోసం మీరు model calls కు చెల్లించాలి.

Language support tiered గా ఉంటుంది. 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 ను opt-in చేయాలి. దీనికి rust-analyzer లేదా gopls వంటి language server అవసరం.

Graft ను ఇన్‌స్టాల్ చేసి version ను pin చేయండి

Graft కు Node.js 20 లేదా అంతకంటే కొత్త version అవసరం. ఇది MIT license కింద విడుదలవుతుంది. August 2026 నాటికి ప్రస్తుత release 0.10.1. మొదట ప్రచురించిన version 0.1.0, July 2026 నాటిది. ఇది ఇంకా ప్రారంభ దశలో ఉన్న software గా పరిగణించండి.

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

npm ls -g ద్వారా @nanonets/graft@0.10.1 ప్రింట్ కావాలి. ఆ version ను ఉద్దేశపూర్వకంగా pin చేయండి. సాధారణ npm install -g @nanonets/graft మీరు దాన్ని అమలు చేసే సమయంలో ఉన్న latest tag ను resolve చేస్తుంది. ఒక నెలలో project అనేక minor releases విడుదల చేస్తే, Mondayన మీ సహోద్యోగి install చేసిన tool కంటే Tuesdayన మీకు వేరే tool లభించవచ్చు. Pin చేసిన version వల్ల అందరికీ CLI flags మరియు graph format ఒకేలా ఉంటాయి. అందువల్ల upgrade ఎప్పుడు చేయాలో మీరు నిర్ణయించవచ్చు.

తర్వాత, మీకు చెందిన repository లో దాన్ని wire చేయండి:

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

graft init మీ coding agents లో ఏవాటిని wire చేయాలో అడిగి, తరువాత graph ను build చేస్తుంది. ముందుగా --dry-run అమలు చేసి, అది మార్చబోయే files జాబితాను చదవండి. వాటిలో కొన్ని repository వెలుపల ఉండవచ్చు. graft init idempotent గా పనిచేస్తుంది మరియు ఇప్పటికే ఉన్న configs ను overwrite చేయదు. అందువల్ల దాన్ని రెండోసారి అమలు చేయడం సురక్షితం.

August 2026 నాటికి ఈ wiring Claude Code, Cursor, Codex, GitHub Copilot, Google Gemini, Kiro, Windsurf మరియు AdaL ను support చేస్తుంది. Claude Code తో అత్యంత విస్తృతమైన integration ఉంటుంది: MCP server entry, graph size మరియు staleness చూపించే statusline, graph ను rebuild చేసే post-edit hooks, అలాగే .claude/ కింద skill file. మిగతా వాటికి tools అందుబాటులో ఉన్నాయని agent కు తెలియజేసే instruction లేదా rule file లభిస్తుంది. అందువల్ల “Supported” అంటే Graft wiring ను రాస్తుంది అని మాత్రమే. Agent తన rules file ను చదవకపోతే map ను కూడా ఉపయోగించదు. మీరు రాసిన instructions ను 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 చేస్తే, ఒక పంక్తి మార్పు అనేక వందల ఫైళ్ల diff గా మారుతుంది. ఏ reviewer కూడా దాన్ని చదవరు. అందువల్ల wiring ను commit చేయండి. వాటిలో AGENTS.md మరియు .mcp.json కూడా ఉంటాయి. ఒక సహచరుడు repository ను clone చేసి, graft build ను run చేస్తే, వారికి స్వంత 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 దాన్ని track చేస్తూనే ఉంటుంది. తరువాత చేసే .gitignore edit దాన్ని untrack చేయదు.

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, ఒక task description కోసం file మరియు line వివరాలతో ranked nodes ను తిరిగి ఇస్తుంది. graft_file_api, bodies లేకుండా ఒక file లోని ప్రతి signature ను తిరిగి ఇస్తుంది. graft_trace_calls, callers లేదా callees ను అనేక levels లోకి అనుసరిస్తుంది. graft_find_all, regex matches ను 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 ను చూపించాలి. ఇదే మొత్తం విధానం: సరైనదాన్ని కనుగొనడానికి పది 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 చేర్చబడతాయి. Agent map ను ఉపయోగించినా, ఉపయోగించకపోయినా ఈ ఖర్చు ఉంటుంది. Context లో సరిపోయేంత చిన్న repository పై, ఈ fixed charge అది ఆదా చేసే exploration కంటే ఎక్కువగా ఉండవచ్చు.

కోడ్ మారినప్పుడు గ్రాఫ్‌కు ఏమి జరుగుతుంది

Structural refresh చవకగా, స్వయంచాలకంగా జరుగుతుంది. Graft, git కంటే మీ working tree ను చదువుతుంది. అందువల్ల మీరు commit చేయని edit మరియు stage చేసిన edit రెండూ దానికి సమానంగా కనిపిస్తాయి. ఒక query, stat మారిన files ను మాత్రమే మళ్లీ parse చేస్తుంది. ఈ ప్రక్రియకు సుమారు 3 ms overhead ఉంటుందని project documentation పేర్కొంటుంది. turn-end rebuild లో code మారిన files ను మాత్రమే పరిశీలిస్తుంది. మళ్లీ parse చేయకుండా disk పై ఉన్న graph ఆధారంగా సమాధానం ఇవ్వడానికి GRAFT_NO_REFRESH=1 ను సెట్ చేయండి లేదా --no-refresh ను pass చేయండి. ప్రతిదానినీ మొదటి నుంచి parse చేయడానికి --no-reuse ను pass చేయండి. Graft ను upgrade చేసిన తర్వాత ఇదే ఉపయోగించాలి.

Model రాసే భాగం భిన్నంగా పనిచేస్తుంది. సమస్యలు నిశ్శబ్దంగా ఏర్పడే భాగం కూడా ఇదే. Summaries మరియు cruxes cache చేయబడతాయి. ప్రతి node తన source files యొక్క content hash ను నమోదు చేస్తుంది. అందువల్ల source file మారినప్పుడు node ను current గా చూపకుండా stale గా గుర్తిస్తుంది. అయితే ఏదైనా ప్రక్రియ దానిపై చర్య తీసుకున్నప్పుడే ఆ flag ఉపయోగపడుతుంది. graft build --deep తో refresh చేయండి. దీనివల్ల model tokens మళ్లీ ఖర్చవుతాయి.

Staleness ను స్పష్టంగా కనిపించేలా చేయండి:

graft check .
echo $?

Exit status 0 అంటే graph code కు సరిపోతుందని అర్థం. Exit status 1 అంటే drift ఉందని అర్థం. దీన్ని pre-push hook నుంచి లేదా CI లోని branch పై run చేయండి. అప్పుడు ఆరు నెలల పాత map, March లో తిరిగి రాసిన code గురించి నమ్మకంగా సమాధానం ఇవ్వదు.

ప్రచురించిన benchmark సంఖ్యలను జాగ్రత్తగా పరిశీలించండి

Graft యొక్క ప్రధాన వాదన: “4x వరకు తక్కువ ఖర్చు, 3x వేగం, అలాగే correctness మెరుగ్గా ఉండటం లేదా ఏమాత్రం తగ్గకపోవడం.” ఈ సంఖ్యలు READMEలో ప్రచురించిన ప్రాజెక్ట్ స్వంత benchmarks నుంచి వచ్చాయి. అది నివేదించిన రెండు 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 ను కలిగి ఉంది. వాటిలో ఒకటి Graft repository. ప్రతి task కు మూడు trials నిర్వహించారు. ఇందులో tokens 42% తక్కువగా, tool calls 46% తక్కువగా ఉన్నాయని నివేదించారు. SWE-bench Verified run లో 50 instances ఉన్నాయి. రెండు arms లోనూ ఒకే model ఉపయోగించారు. ఇందులో తక్కువ ఆదా నమోదైంది: tokensలో 23% మరియు tool callsలో 25%. మూడవ run లో merge చేసిన ఐదు PocketBase pull requests ను మళ్లీ అమలు చేశారు. దానికి 11.02 US dollars ఖర్చయ్యాయి. Baseline కు 13.91 ఖర్చయ్యాయి.

ఇవన్నీ vendor benchmarkలుగా పరిగణించండి. ఇవి ఏమి తెలియజేయగలవో పరిమితం చేసే రెండు విషయాలు ఉన్నాయి. నియంత్రిత sweepలో Graft స్వంత repository ఉంది. అంటే దాని authors ప్రత్యేకంగా అనుకూలపరచిన codebase అదే. SWE-bench Verified అనేది ప్రసిద్ధ open-source Python projects నుంచి తీసుకున్న issuesతో కూడిన public dataset. ఎవరూ ఉద్దేశపూర్వకంగా చేయకపోయినా, tools సాధారణంగా public datasets కోసం optimize చేయబడతాయి. ఈ రెండింటిలో ఏదీ మీ private monorepo గురించి చెప్పదు. మీ monorepoకు స్వంత naming conventions, అలాగే ఉపయోగించని code ఉండవచ్చు.

Correctnessను మరోసారి జాగ్రత్తగా పరిశీలించాలి. నియంత్రిత sweepలో అది మారలేదు: mapతో 93%, map లేకుండా 93%. 54% నుంచి 66%కు పెరుగుదల SWE-bench Verifiedలో మాత్రమే కనిపిస్తుంది. మీ token ఖర్చును తగ్గించి, qualityను అదే స్థాయిలో ఉంచే tool అయినా మంచి ఎంపికే. అయితే SWE-bench correctness ఫలితాన్ని sweepలోని token ఫలితంతో కలిపి, రెండింటినీ ఒకే వాదనగా ఉటంకించవద్దు.

మీ స్వంత token delta ను కొలిచిన తర్వాతే ఈ ఫలితాలను నమ్మండి

ముఖ్యమైన ఏకైక సంఖ్య మీ repository నుంచి వచ్చినదే. ఈ పద్ధతికి ఒక మధ్యాహ్నం సమయం పడుతుంది.

మీరు కచ్చితంగా పునరావృతం చేయగల task ను ఎంచుకోండి. Edit కంటే question మంచిది, ఎందుకంటే edit repository ను మార్చేస్తుంది. అప్పుడు రెండో run అదే experiment గా ఉండదు. "Which module enforces the rate limit on the login route" అనేది సరైన రూపం.

Telemetry ను ప్రారంభించి, మీ స్వంత terminal కు పంపండి:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
claude

Console exporter metric records ను సేకరించిన వెంటనే ప్రింట్ చేస్తుంది. మీకు కావాల్సింది claude_code.token.usage. ఇందులో input, output, cacheRead లేదా cacheCreation విలువ కలిగిన type attribute ఉంటుంది. Orientation విలువలు input మరియు cacheRead లో కనిపిస్తాయి, ఎందుకంటే file contents అక్కడే నిల్వ అవుతాయి. ఆ రెండింటినీ కలపండి.

Map అనుసంధానించిన తాజా session లో task ను మూడు సార్లు run చేయండి. తరువాత .mcp.json నుంచి graft entry ను తొలగించి, మరో మూడు సార్లు run చేయండి. ఒక్కో run ను కాకుండా medians ను పోల్చండి. Agent runs లో పెద్ద మార్పులు ఉండవచ్చు. ఒక అననుకూల run వాస్తవానికి విరుద్ధమైన ఫలితాన్ని చూపవచ్చు. Tool-call count ను కూడా నమోదు చేయండి. Tool calls mechanism, tokens effect. కాబట్టి tool calls తగ్గకుండా tokens మాత్రమే తగ్గితే, మరేదో మారి ఉంటుంది.

తరువాత benchmark చూపించని costs ను తీసివేయండి. graft build --deep ప్రతి full refresh లో model tokens ను వినియోగిస్తుంది. ప్రతి request లో ఆరు tool schemas కూడా పంపబడతాయి. మీ agents మీరు అద్దెకు తీసుకున్న server పై నడుస్తుంటే, agent ఖర్చుపై కఠిన పరిమితి పెట్టడం అనుకోని ఖర్చును budget గా మార్చుతుంది. Exporter ను ప్రారంభించిన తర్వాత machine నుంచి నిజంగా ఏ సమాచారం బయటకు వెళ్తుందో coding agent telemetry వాస్తవంగా ఏమి నివేదిస్తుంది వివరిస్తుంది.

కోడ్‌బేస్ మ్యాప్ ఎప్పుడు ఉపయోగకరంగా ఉండదు?

• రిపాజిటరీ ఇప్పటికే context లో సరిపోతుంది. ఒక చిన్న service కు మ్యాప్ అవసరం లేదు. ప్రతి request పై ఆరు tool schemas కోసం మీరు ఇంకా ఖర్చు చేస్తారు. మీ agent ఈరోజు ఏ file అయినా ఒకటి లేదా రెండు tool calls లో కనుగొనగలిగితే, దాన్ని వదిలేయండి.
• మీ language broad tier లో ఉంది. సాధారణ call edges కారణంగా graft callers ఒక caller ను గుర్తించకపోవచ్చు లేదా name collision వల్ల లేనిది సృష్టించవచ్చు. Blast radius ను నమ్మే ముందు graft grep తో నిర్ధారించండి.
• Graph పాతబడింది, కానీ ఎవరూ గమనించలేదు. మార్పులు ఉంటే graft check exit 1 ఇస్తుంది. అయితే ఏదైనా దాన్ని అమలు చేస్తేనే అది ఉపయోగకరం. దానికోసం ఒక hook లేదా CI step ఉండాలి; అలవాటుపై ఆధారపడకండి.
• Monorepo కు scoping అవసరం. ఒకే-git monorepo workspace file, go.mod, pyproject.toml లేదా Cargo.toml ఆధారంగా స్వయంచాలకంగా విభజించబడుతుంది. graft ask "..." --in services/billing/ ఒక sub-project కు మాత్రమే query ను పరిమితం చేస్తుంది. ప్రతి package కు nested AGENTS.md files ఉంచే అదే విధానం మ్యాప్‌కూ వర్తిస్తుంది.
• Agent wiring ను పట్టించుకోవడం లేదు. మ్యాప్ ఉపయోగించబడుతుందా అని నిర్ణయించే ముందు నిజమైన session లో tool calls ను గమనించండి. grep ను ఇంకా అమలు చేస్తున్న agent rules file ను ఎప్పుడూ చదవలేదని అది సూచిస్తుంది.

FAQ

graft/ folder ను git కు commit చేయాలా?

వద్దు. graft build మీ .gitignore కు graft/ ను స్వయంచాలకంగా జోడిస్తుంది, ఎందుకంటే graph అనేది node_modules లాంటి మళ్లీ రూపొందించగల cache. ఇది దాదాపు ప్రతి edit తర్వాత మారుతుంది. అందువల్ల దీనిని commit చేస్తే వందల generated files కింద అసలు diffs కనిపించకుండా పోతాయి. map ఉందని agents కు తెలియజేసే wiring ను commit చేయండి. వాటిలో AGENTS.md మరియు .mcp.json కూడా ఉంటాయి. ప్రతి teammate తన స్థానిక environment లో graft build ను అమలు చేయాలి. మొదటి commit కు ముందు grep -n graft .gitignore మరియు git status --short తో నిర్ధారించండి. git ఒక file ను add చేసిన తర్వాత దాని tracking కొనసాగిస్తుంది. ఆ తర్వాత .gitignore ను edit చేయడం వల్ల అది untrack కాదు.

Graft ను అమలు చేయడానికి ఖర్చు ఉంటుందా?

Structural భాగానికి ఖర్చు ఉండదు. graft build, graft ask, graft check మరియు ఆరు MCP retrieval tools tree-sitter operations. అవి ఎప్పుడూ model ను call చేయవు. graft build --deep చెల్లింపు అవసరమయ్యే భాగం. ఇది LLM ద్వారా plain-English summaries మరియు ప్రతి symbol కు సంబంధించిన cruxes ను రాస్తుంది. దీనిని GRAFT_PROVIDER, GRAFT_API_KEY మరియు GRAFT_MODEL తో configure చేస్తారు. OpenAI-compatible endpoint కోసం GRAFT_BASE_URL ను కూడా ఉపయోగించవచ్చు. Structure మాత్రమే ఉపయోగిస్తూ Graft ను అమలు చేయవచ్చు. Graph కోసం ఒక్క token కూడా ఖర్చు చేయాల్సిన అవసరం లేదు.

నా repository పై codebase map వాస్తవంగా ఎంత ఆదా చేస్తుంది?

కొలతలు లేకుండా ఎవరూ చెప్పలేరు. స్వంత 162-run sweep లో project, map లేని baseline తో పోలిస్తే 42% తక్కువ tokens ను report చేసింది. SWE-bench Verified పై ఈ తగ్గింపు 23%. ఇవి రెండూ vendor benchmarks. వాటిలో ఒకటి Graft స్వంత repository పై కొంతవరకు నిర్వహించబడింది. మీ private code గురించి ఇవేవీ తెలియజేయవు. ఒకే repeatable question ను map తో మూడు సార్లు, map లేకుండా మూడు సార్లు అమలు చేయండి. ఈ సమయంలో CLAUDE_CODE_ENABLE_TELEMETRY=1 మరియు OTEL_METRICS_EXPORTER=console ను set చేయాలి. తరువాత claude_code.token.usage యొక్క median ను input మరియు cacheRead types కోసం పోల్చండి.

నేను refactor చేసినప్పుడు graph కు ఏమవుతుంది?

Structure తనంతట తానే మళ్లీ parse అవుతుంది. Graft working tree గణాంకాలను సేకరించి, మారిన files ను మాత్రమే మళ్లీ parse చేస్తుంది. అందువల్ల rename తదుపరి query లో సుమారు 3 ms overhead తో గుర్తించబడుతుంది. ఇది git history ను కాకుండా files ను చదువుతుంది. కాబట్టి uncommitted work ను కూడా గుర్తిస్తుంది. Model రాసిన summaries మాత్రమే stale అవుతాయి. ప్రతి node తన source files యొక్క content hash ను నిల్వ చేస్తుంది. Source మారితే node ను తిరిగి రాయదు; దాన్ని stale గా గుర్తిస్తుంది. మార్పును చూడటానికి graft check . ను అమలు చేయండి. తరువాత written భాగాన్ని refresh చేయడానికి graft build --deep ను అమలు చేయండి.

ప్రస్తుతం Graft ను ఏ coding agents ఉపయోగించగలవు?

August 2026 నాటికి graft init Claude Code, Cursor, Codex, GitHub Copilot, Google Gemini, Kiro, Windsurf మరియు AdaL ను wire చేస్తుంది. 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 వీటిని skip చేస్తుంది. ఇతర agents కు rules లేదా steering file అందుతుంది. మరే ఇతర MCP client అయినా npx -y @nanonets/graft@0.10.1 mcp command ను register చేసి server ను నేరుగా ఉపయోగించవచ్చు.