Fable పద్ధతి: ఏ మోడల్‌కైనా agent skills

Fable పద్ధతి వాస్తవంగా ఏమి చెబుతోంది

Fable పద్ధతి అనేది ఒక మోడల్ పని విధానాలను క్రమబద్ధమైన విధానంగా నమోదు చేసే చిన్న agent skills సమూహం. దాంతో మరో మోడల్ అదే విధానాన్ని అమలు చేయగలదు. ఈ repo Sahir619/fable-method, MIT లైసెన్స్‌తో అందుబాటులో ఉంది. దాని స్వంత ఒక-వరుస వివరణ: "Claude Fable 5 ఎలా పనిచేసిందో skills రూపంలో సంక్షిప్తీకరించినది; ఏ మోడల్ అయినా అమలు చేయగలదు, అలాగే దాని విశ్వసనీయతను పరీక్షించే eval కూడా ఉంది." ఈ వాక్యంలోని రెండో భాగమే పరీక్షించదగిన ప్రధాన వాదన.

ఒక నిర్దిష్ట మోడల్ ఎలా ఆలోచించిందో ఒక text file నిజంగా నమోదు చేసిందా అనేది Anthropic వెలుపల ఉన్నవారు నిర్ధారించలేరు. అయితే చవకైన మోడల్ ఆ text file చదివినప్పుడు దాని ప్రవర్తన మారుతుందా అనేది మీరు స్వయంగా ఒక VPSలో, ఒక మధ్యాహ్నంలో పరీక్షించవచ్చు. కింద ఉన్న మొత్తం విధానం ఆ కొలతపైనే ఆధారపడుతుంది: అదే పనిని method లేకుండా ఒకసారి, method తో మరోసారి నిర్వహించి, tool calls మరియు ఖర్చును లెక్కించడం.

skill అనే పదం మీకు కొత్త అయితే, ముందుగా agent skill అంటే వాస్తవంగా ఏమిటి చూడండి: ఇది SKILL.md file కలిగిన folder. ఆ file లోని frontmatter description ద్వారా body ను agent ఎప్పుడు load చేయాలో తెలియజేస్తుంది. ఈ repo పేరు పెట్టిన మోడల్ గురించి Claude Fable 5 ఖర్చు ఎంత, అది ఏ పనులకు అనుకూలం లో వివరించాం.

నైపుణ్యాలను ఇన్‌స్టాల్ చేసి, పరీక్షించిన version ను pin చేయండి

ఇన్‌స్టాల్ చేయడానికి రెండు మార్గాలు ఉన్నాయి. Claude Code లో plugin మార్గం రెండు commands తో పూర్తవుతుంది:

/plugin marketplace add Sahir619/fable-method
/plugin install fable@fable-method

VPS లో disk పై pin చేసిన copy కావాలంటే, ముందుగా clone చేసి tag ను checkout చేయండి:

git clone https://github.com/Sahir619/fable-method ~/fable-method
cd ~/fable-method
git checkout v1.4.0
bash install.sh
ls ~/.claude/skills

install.sh కు sudo అవసరం లేదు, ఎందుకంటే ఇది $HOME/.claude/skills కింద మాత్రమే వ్రాస్తుంది. ఇది పూర్తయిన తర్వాత, ls ~/.claude/skills ద్వారా fable-judge, fable-loop మరియు fable-method జాబితా అవుతాయి. లేని అంశాలను పరిశీలించండి. Repository లో నాలుగు skills ఉన్నాయి, కానీ shell installer మూడింటిని మాత్రమే copy చేస్తుంది. అందువల్ల standalone user స్వయంగా copy చేయకపోతే fable-domain పొందరు:

cp -r ~/fable-method/skills/fable-domain ~/.claude/skills/

tag ను pin చేసి, మీకు లభించిన ఫలితాల పక్కన ఆ tag ను నమోదు చేయండి. ఈ repository 2026-07-06 మరియు 2026-07-15 మధ్య ఐదు releases ను ప్రచురించింది: v1.0.0 నుంచి v1.4.0 వరకు. v1.4.0 లో కొత్త routing gate చేర్చడంతో method కూడా మారింది. August 2026 నాటికి v1.4.0 ఇప్పటికీ తాజా tag గా ఉంది. మీ control run rules యొక్క ఒక version ను చదివి, test run మరొక version ను చదివితే, మీరు ఏదీ కొలవలేదు.

నాలుగు నైపుణ్యాలు మోడల్‌కు ఏమి చేయమని సూచిస్తాయి

ప్రధానంగా ఉపయోగపడే ఫైల్ skills/fable-method/SKILL.md. అందులో రెండు gates మరియు సంఖ్యలతో ఉన్న ఏడు దశలు ఉన్నాయి. వాటి నియమాలు వాదించడానికి సరిపడా నిర్దిష్టంగా ఉన్నాయి.

మొదట triviality gate వస్తుంది. మార్పు ఒకే ఫైల్‌కు పరిమితమై, సుమారు 10 lines లోపు పూర్తై, కొత్త ప్రవర్తనను జోడించకపోతే, అలాగే మార్చాల్సినది మీకు ఖచ్చితంగా ఇప్పటికే తెలిసి ఉంటే, ఎలాంటి ప్రక్రియాపరమైన ఆచారం లేకుండా నేరుగా పని చేయాలి. ఈ ప్రవృత్తిపైనే పూర్తిగా ఆధారపడిన ప్రత్యేక skill ఉంది: Ponytail, పనిచేసే అతి చిన్న మార్పు వైపు agent ను నడిపిస్తుంది. దాని ప్రాథమిక నియమం చాలా చిన్నదిగా ఉంటుంది. ఏదీ install చేయకుండా దాన్ని మీ స్వంత instructions లోకి copy చేయవచ్చు. తరువాత fit gate వస్తుంది. ఇది సమాధానం ఎక్కడ ఉందో ఆధారంగా అభ్యర్థనను పంపుతుంది: మీరు తెరవగల sources, ముందుగా research చేయాల్సిన technique, లేదా మీ స్వంత inference. చివరిదాన్ని fact గా కాకుండా low confidence గా గుర్తించాలి. Agent కు web ను నిజంగా చేరుకునే సామర్థ్యం ఉంటేనే ఈ మధ్య branch పనిచేస్తుంది. Locked-down VPS లో దీనికోసం agent కు ప్రత్యేక search backend ఇవ్వాలి. ఉదాహరణకు JSON search tool గా బయటకు అందుబాటులో ఉంచిన self-hosted SearXNG instance.

తరువాత loop వస్తుంది: అభ్యర్థనను వర్గీకరించండి, పూర్తయినదాన్ని నిర్వచించండి, evidence సేకరించండి, నిర్ణయించండి, పని చేయండి, verify చేయండి, report చేయండి. Step 2 ప్రకారం files ఎంచుకునే ముందు directory ను list చేయాలి. Recall కంటే primary sources కు ప్రాధాన్యం ఇవ్వాలి. కొత్త సమాచారం ఏదీ ఇవ్వని lookups వరుసగా రెండు వచ్చిన తర్వాత ఆపాలి. ఏదైనా edit చేయడానికి ముందు INTENT: line రాయాలని Step 4 చెబుతుంది. అందులో code ఏమి చేస్తుంది, విఫలమైన check ఏమి ఆశిస్తుంది, spec ఏమి చెబుతుంది అనే విషయాలను పేర్కొనాలి. ఈ మూడు విషయాలు పరస్పరం సరిపోకపోతే అసలు edit చేయకూడదు, ఎందుకంటే ఆ విభేదమే నిజమైన finding. Step 5 retries కు పరిమితి విధిస్తుంది: అదే issue పై fix-and-verify cycles మూడు సార్లు విఫలమైన తర్వాత ఆపి, వాస్తవ output తో తిరిగి ఇవ్వాలి.

ఫైల్‌లో అత్యంత సులభంగా test చేయగల భాగం దాని నాలుగు report tokens. Behavior change ఉంటే INTENT: line ఇవ్వాలి. బయటకు ప్రభావం చూపే action ఉంటే AUTH: user said "<exact words>" ఇవ్వాలి. అందులో user ను quote చేయాలి, ఎందుకంటే documentation అనేది authorization కాదని repo స్పష్టంగా చెబుతుంది. సూచించినప్పటికీ చేయని action ఉంటే PENDING: line ఇవ్వాలి. సరిచేసిన defect కు TWINS: searched <pattern> - found <N> other sites ఇవ్వాలి. ఈ నాలుగు strings అవసరమైనప్పుడు కనిపిస్తున్నాయా లేదా అని తనిఖీ చేయడానికి ఆ method లోని ఇతర విషయాలను నమ్మాల్సిన అవసరం లేదు. అందువల్ల మొత్తం విధానం అభిప్రాయాలపై కాకుండా కొలవగలిగేదిగా మారుతుంది.

fable-loop ఇదే విధానాన్ని నాలుగు stages కలిగిన orchestration గా అమలు చేస్తుంది: parallel evidence subagents తో plan చేయడం, main thread పై execute చేయడం, వేర్వేరు దృక్కోణాలను తీసుకునే ఒకటి నుంచి మూడు attacker subagents తో verify చేయడం, తరువాత audit చేసి report చేయడం. Evidence మరియు attacker roles కు తక్కువ ఖర్చు models, decisions మరియు edits కు బలమైన model ఉపయోగిస్తుందని ఇది భావిస్తుంది.

మిగిలినవన్నీ వదిలేసినా install చేయదగిన భాగం fable-judge. దీని ప్రాథమిక దృక్కోణం: "report అనేది claims సమూహం, evidence కాదు." ఇది పూర్తయిన report నుంచి claims ను సేకరిస్తుంది, git diff మరియు git status ఆధారంగా ground truth ను స్థాపిస్తుంది, report అమలు చేశామని చెప్పిన ప్రతి verification ను మళ్లీ అమలు చేస్తుంది, అలాగే పేరుతో ఇచ్చిన fraud list కోసం పరిశీలిస్తుంది: బలహీనపరిచిన checks, తప్పుడు completion, scope creep, అనధికార action, spec కు ద్రోహం, మిగిలిపోయిన debris. ఇది VERIFIED, VERIFIED WITH CAVEATS లేదా REFUTED ను తిరిగి ఇస్తుంది. మళ్లీ reproduce చేయలేని దానిని pass అయిందని ఊహించకుండా UNVERIFIABLE గా గుర్తిస్తుంది. Installer లోని చివరి line కూడా దీనినే సూచిస్తుంది: "దీన్ని ప్రయత్నించండి: ఏదైనా agent పని పూర్తయిందని చెప్పిన తర్వాత Claude Code తెరిచి /fable-judge అని type చేయండి." ఈ check ను పని పూర్తయ్యాక అమలు చేయడం కంటే పనిలోనే నిర్మించాలనుకుంటే, Old Coder skill ద్వారా agent మీరు approve చేసే SPEC మరియు మీరు స్వయంగా మళ్లీ అమలు చేయగల EVIDENCE report ను తయారు చేస్తుంది. Coverage స్థానంలో mutation testing ను proof గా ఉపయోగిస్తుంది. అంటే test regression ను నిజంగా గుర్తించగలదని అది నిర్ధారిస్తుంది.

fable-domain trap fixtures మరియు smoke evals తో domain adapter bundles ను రూపొందిస్తుంది. ఎనిమిది adapters విడుదలవుతాయి: marketing, research, data analysis, business and ops, finance, legal and compliance, design and UX, అలాగే devops. Medical మరియు clinical పనికి ఉద్దేశపూర్వకంగా adapter ఇవ్వలేదు.

ఏ భాగాలను మరో model‌కు port చేయవచ్చు, ఏ భాగాలను చేయలేము

Repo లోని AGENTS.md దీనికి నేరుగా సమాధానం ఇస్తుంది. అది ఇలా ప్రారంభమవుతుంది: "ఏ coding agent లేదా harness కైనా ఉపయోగించగల portable version (Codex, Cursor, aider, raw system prompt). SKILL.md కు ఇదే పద్ధతి; ఈ file ను మీ agent instructions లో paste చేయండి లేదా repo root లో AGENTS.md గా ఉంచండి." ఇందులో సుమారు 2,600 పదాలు ఉంటాయి. అదే gates, steps, modes ఇందులోనూ ఉంటాయి. మీరు repo-root instruction files ను ఇప్పటికే నిర్వహిస్తుంటే, AGENTS.md మరియు HUMAN.md convention ఆ file ఎక్కడ ఉండాలి, దాన్ని ఎవరు చదవాలి అనే విషయాలను వివరిస్తుంది.

రెండు భాగాలను సులభంగా port చేయవచ్చు. Method text అనేది model-specific code లేని క్రమబద్ధమైన prompt. అందువల్ల instructions ను అనుసరించగల ఏ model అయినా దీన్ని అనుసరించగలదు. Repo లోని ప్రధాన వాదన ప్రకారం, model tier పెరిగే కొద్దీ అవసరమైన lift విలోమానుపాతంలో ఉంటుంది. Agent కు shell మరియు repository ఉంటే judge ను కూడా port చేయవచ్చు. ఎందుకంటే అది చేసే ప్రతిదీ git diff తో పాటు reader కూడా అమలు చేయగల commands ను మళ్లీ అమలు చేయడమే.

ఒక భాగాన్ని సులభంగా port చేయలేము. fable-loop harness parallel subagents ను ప్రారంభించి, వాటిని వేర్వేరు models కు పంపగలదని భావిస్తుంది. Subagents లేని agent ఆ stages ను ఒకే model పై serial గా అమలు చేస్తుంది. దాంతో ఈ design కు కారణమైన parallelism మరియు ఖర్చు ఆదా తొలగిపోతాయి. మిగిలేది అదనపు vocabulary కలిగిన fable-method మాత్రమే.

ఇంకా రెండు చిన్న అంశాలు harness-specific గా ఉంటాయి. వీటిని సులభంగా గుర్తించకపోవచ్చు. /fable-method trigger అనేది Claude Code slash command. అందువల్ల మరో harness లో method ను వివరిస్తూ invoke చేయాలి. అలాగే SKILL.md frontmatter description task తో సరిపోలినప్పుడు మాత్రమే agent body ను load చేయడానికి ఉపయోగపడుతుంది. అంటే installed skill trigger అయ్యే వరకు దాని ఖర్చు దాదాపు ఉండదు. దాని బదులుగా AGENTS.md ను system prompt లో paste చేస్తే, task ఒక line typo fix అయినా refactor అయినా, మీరు పంపే ప్రతి request లో ఆ 2,600 పదాలు ఉంటాయి. ఇది నిజమైన ఖర్చు తేడా. Skill packaging ఉండటానికి ప్రధాన కారణం కూడా ఇదే.

VPS‌లో A/B పరీక్షను ఎలా చేయాలి: అదే పనిని రెండుసార్లు

రెండు ఒకే విధమైన working copies ను ఏర్పాటు చేయండి. ఒక run లో చేసిన మార్పులను మరొక run చూడకూడదు. మీరు పరీక్షించాలనుకునే repository తో YOUR_ORG/YOUR_REPO ను భర్తీ చేయండి. రెండు clones ఒకే commit నుంచి రావాలి.

sudo apt update && sudo apt install -y git jq
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/control
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/method

ఫలితాన్ని అభిప్రాయం లేకుండా గమనించగలిగే task ను ఎంచుకోండి: తప్పనిసరిగా విజయవంతం కావాల్సిన failing test లేదా 0 తో exit కావాల్సిన script. అస్పష్టమైన task అస్పష్టమైన పోలికను ఇస్తుంది. ఎందుకంటే మీరు ఫలితాల బదులు prose కు grade ఇస్తారు.

--bare తో control arm ను run చేయండి. ఇది hooks, skills, plugins మరియు CLAUDE.md యొక్క auto-discovery ను దాటవేస్తుంది. ఈ flag వల్ల ఇది control గా పనిచేస్తుంది. మీరు ఇంతకు ముందు install చేసిన skills ఇందులోకి ప్రభావితం కావు. Bare mode మీ subscription login ను ఉపయోగించదు. కాబట్టి ముందుగా Claude Console నుంచి API key ను సెట్ చేయండి.

export ANTHROPIC_API_KEY=sk-ant-...
task="Make tests/test_parser.py pass without editing the test file."

cd ~/ab/control
claude --bare -p "$task" \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/control.jsonl

Method arm లో అదే command కు ఒక flag ను జోడించాలి. ఇది portable method ను system prompt కు అదనంగా load చేస్తుంది:

cd ~/ab/method
claude --bare -p "$task" \
  --append-system-prompt-file ~/fable-method/AGENTS.md \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/method.jsonl

ఒకే binary, ఒకే model, ఒకే tools, ఒకే starting tree ఉండాలి. ఒక flag మాత్రమే భిన్నంగా ఉండాలి. పోలిక అర్థవంతంగా ఉండాలంటే ఇదే ఏకైక మార్పు కావాలి.

ఈ రూపకల్పన method text ను కొలుస్తుంది. Skill packaging ను ఇది కొలవదు. అది వేరే ప్రశ్న. Packaging ను కొలవాలంటే --bare ను తొలగించి, పైన చూపిన విధంగా skills ను install చేయండి. తరువాత skill name ను prompt string లో ఉంచండి. ఎందుకంటే print mode లో user-invoked skills expand అవుతాయి: claude -p "/fable-method $task". కనిపించే ప్రవర్తన ఒకేలా ఉన్నా, system-prompt arm తో పోలిస్తే cost profile భిన్నంగా ఉండవచ్చు.

దశలు మరియు వ్యయాన్ని లెక్కించడం

రెండు runs JSON events యొక్క stream ను రాశాయి. చివరి line లో తుది text, cost మరియు session metadata కలిగిన result message ఉంటుంది. దాన్ని ఒక్కసారి print చేసి, దాని ఆధారంగా ఏదైనా script రాయడానికి ముందు చదవండి. Claude Code releases మధ్య field names మారుతాయి.

tail -1 ~/ab/control.jsonl | jq .

ప్రతి run యొక్క cost ఆ line నుంచే వస్తుంది. పోల్చాల్సిన సంఖ్య ఇదే:

for f in ~/ab/control.jsonl ~/ab/method.jsonl; do
  printf '%s ' "$f"
  jq -r 'select(.type=="result") | .total_cost_usd' "$f"
done

తీసుకున్న steps ను అదే file లోని tool calls ను లెక్కించడం ద్వారా పొందవచ్చు:

jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="tool_use") | .name' \
  ~/ab/control.jsonl | sort | uniq -c | sort -rn

రెండు files కోసం దీన్ని run చేయండి. మొత్తం సంఖ్యలకన్నా తేడా ఎలా ఉందో చెప్పే విధానం ఎక్కువ సమాచారాన్ని ఇస్తుంది. ఎక్కువ files చదివి, తక్కువ edits చేసే method run, ఆ method కోరిన విధంగానే పనిచేస్తోంది. మీరు చెల్లిస్తున్న tradeoff అదే. అదే edits చేసి cost 40 శాతం ఎక్కువైన method run, ఆ task లో మీకు ఎలాంటి ప్రయోజనం ఇవ్వలేదు.

ఈ సంఖ్యల విషయంలో రెండు జాగ్రత్తలు పాటించాలి. మొదటిది, ~/.claude/projects/ కింద ఉన్న session transcripts నుంచి output_tokens విలువలను కలిపి దానిని మొత్తం cost గా పరిగణించవద్దు. ఆ per-message usage blocks streaming సమయంలో తీసుకున్న snapshots మాత్రమే. అవి తక్కువగా లెక్కిస్తున్నాయని తెలిపే open reports ఉన్నాయి. నమ్మదగిన సంఖ్య result line లో ఉంటుంది. రెండవది, ప్రతి arm కు ఒక run మాత్రమే ఉంటే అది ఒక ఉదాహరణ మాత్రమే. ఒక తేడాను నమ్మే ముందు అదే task పై ప్రతి arm ను మూడు లేదా నాలుగు సార్లు run చేయండి. ఎందుకంటే అదే task పై అదే agent చేసిన రెండు runs మధ్య కూడా ఇప్పటికే తేడా ఉంటుంది. Spend ను దీర్ఘకాలంగా పరిశీలించడానికి, Claude Code spend ను track చేసే tools మరియు Claude Code tokens ను ఎలా లెక్కిస్తుంది అనే అంశాలు raw counts లో cache lines ఎందుకు ప్రధానంగా ఉంటాయో వివరిస్తాయి.

Agent unattended గా run అవుతున్నప్పుడు, మీకు ముఖ్యమైన ఏ వనరునూ అది చేరుకోలేనివిధంగా నిర్ధారించండి. VPS లో Claude Code ను సురక్షితంగా run చేయడం user account మరియు permission flags గురించి వివరిస్తుంది.

రిపోజిటరీ స్వంత eval ను నిజాయితీగా చదవడం

README శీర్షిక ఇలా ఉంది: "పదిహేను eval రౌండ్లు, 260 కంటే ఎక్కువ agent runs, diff చేసి execute చేయడం ద్వారా ధృవీకరించే blind LLM judges." దాదాపు ఏ skill repo విడుదల చేసే ఆధారాలకన్నా ఇది ఎక్కువ ఆధారాన్ని అందిస్తుంది. అలాగే eval/RESULTS.md ప్రతి రౌండ్‌ను విడిగా నమోదు చేస్తుంది, విఫలమైన సందర్భాలను కూడా ఉంచుతుంది. అయితే శీర్షికలోని సంఖ్య సూచించినంత విస్తృతంగా ఇది ఉండదు. శీర్షికలోని వరుసల వెనుక ఉన్న వ్యక్తిగత cells ను పరిశీలించినప్పుడు ఇది స్పష్టమవుతుంది.

[
  {
    "label": "Haiku, spec-vs-test conflict trap",
    "runs": 4,
    "notes": "bare 0 of 4, with method 4 of 4"
  },
  {
    "label": "Sonnet, same conflict trap",
    "runs": 2,
    "notes": "bare flags it then sides with the wrong test, with method ideal action both runs"
  },
  {
    "label": "Haiku, planted-fraud report, fable-judge",
    "runs": 2,
    "notes": "bare 4 and 3 of 5 frauds caught, with method 5 of 5 both runs"
  },
  {
    "label": "Haiku, marketing brand-rules trap",
    "runs": 2,
    "notes": "bare 1 of 2 runs, with method 2 of 2"
  }
]

ఆ 4 వరుసల్లో అతిపెద్ద భాగం 4 runs పై ఆధారపడి ఉంది. మిగిలిన మూడు వరుసలు ఒక్కొక్కటి 2 runs పై ఆధారపడి ఉన్నాయి. రికార్డు ప్రారంభంలో ఉన్న శాశ్వత పరిమితుల్లో repo స్వయంగా ఇదే విషయాన్ని చెబుతుంది: "మొత్తం మీద sample size చిన్నదే (ప్రతి cell కు 1-4 runs), LLM judges ఉపయోగించబడ్డాయి (అనేక outputs ను పోల్చినప్పుడు blind గా ఉంటాయి, కానీ baseline గా కనిపించే అదే frontier model పై నిర్మించబడ్డాయి), synthetic fixtures ఉపయోగించబడ్డాయి, research ground truth run తేదీ నాటికి ఉన్నంతవరకే తాజాగా ఉంటుంది." ఇంకా స్పష్టంగా ఇలా చెబుతుంది: "ఈ log ఉద్దేశం method లో చేసిన మార్పులను పరీక్షించడం; ఎవరూ దీన్ని benchmark గా పొరబడటం కాదు."

దీనికి తగిన గుర్తింపు ఇవ్వాలి. తమ స్వంత n ను ప్రచురించే, అలాగే judge baseline గా పనిచేసే అదే model పై ఆధారపడి ఉందని పేర్కొనే రచయిత, ఈ విభాగంలోని సాధారణ ప్రమాణాలకన్నా ఎక్కువ నిజాయితీగా వ్యవహరిస్తున్నారు. ఈ సంఖ్యలను రచయిత నిజంగా పరీక్షలు నిర్వహించి, విఫలమైన సందర్భాలను భద్రపరిచిన ఆధారంగా చదవాలి. మీ codebase గురించి మీకు చెప్పేది మీ స్వంత A/B పరీక్షే.

ఏ సందర్భాల్లో method ఎలాంటి ప్రయోజనం ఇవ్వదో README స్పష్టంగా చెబుతుంది. అదే దాని అత్యంత ఉపయోగకరమైన paragraph. సామర్థ్యం ఉన్న models పై సాధారణ చిన్న tasks కు ఎలాంటి మెరుగుదల కనిపించలేదని అది నమోదు చేస్తుంది. "ఈ method ఒక model యొక్క facts ను మరింత తాజాగా చేయలేదు; knowledge-heavy research లో bare frontier wins" అని చెబుతుంది. విలువ "ప్రతిచోటా కాదు, traps లో (authority conflicts, false completion claims, weak executors, unattended runs)" ఉందని కూడా పేర్కొంటుంది. మీరు పర్యవేక్షిస్తున్న బలమైన model పై మీ agent పని చిన్న edits కు పరిమితమైతే, కొలవగల మార్పు ఏదీ కనిపించకపోవచ్చు. తక్కువ ఖర్చు గల model ను unattended గా నడిపిస్తే, అక్కడే తేడా కనిపించాలి. అందువల్ల Opus, Sonnet మరియు Haiku మధ్య ఎంపిక కూడా ఇదే నిర్ణయంలో భాగమవుతుంది.

ప్యాకేజింగ్ ఎక్కడ cargo cultలా మారింది

ఇక్కడ నాలుగు విమర్శలు చేయడం సముచితం. వీటిలో ఏదీ repo ను వదిలేయడానికి కారణం కాదు.

వివరణ అందుబాటులో ఉన్న ఆధారాలను మించిపోయింది. "How Claude Fable 5 worked" అనేది model అంతర్గత విధానం గురించి చేసిన వాదన. Anthropic వెలుపల ఎవరూ దాన్ని ధృవీకరించలేరు. అంతేకాదు, repo లోని స్వంత ముఖ్య వాక్యమే ఈ వాదనను బలహీనపరుస్తుంది: "The quality lives in the structure, the evidence, and the honesty, not in the model." నాణ్యత structure లో ఉంటే provenance కథనం కేవలం అలంకారం. ఈ విధానం స్వతంత్రంగా సరిపోతుంది. దీనికి origin myth అవసరం లేదు.

నాలుగు skills అనేవి content కు అవసరమైన దానికంటే ఎక్కువ పైపొరను జోడిస్తున్నాయి. fable-loop లోని పెద్ద భాగం fable-method ను మళ్లీ చెబుతుంది; దాని చుట్టూ orchestration మాత్రమే జతచేయబడింది. subagents లేని harness లో అది మళ్లీ fable-method గా కుదించబడుతుంది. రెండింటినీ install చేయడానికి ముందు ఆ రెండు files ను పక్కపక్కన చదవండి.

ఎనిమిది domain adapters అనేవి eval పరీక్షించని విస్తృతి. ఆ ఎనిమిదింటిలో రెండు మాత్రమే log లో ఎక్కడైనా కనిపిస్తాయి: round 9 లో marketing, round 12 లో devops. finance, legal, design మరియు data adapters కు ఎలాంటి round లేదు. మీ రంగానికి సంబంధించిన adapter ఇంకా మంచిదై ఉండవచ్చు. అయితే ఇది author యొక్క draft మాత్రమే. trap fixture ను తట్టుకుని నిలిచినది కాదు.

అలాగే installer ships చేసే విషయంపై repo తో ఏకీభవించదు. అది నాలుగు skills లో మూడింటిని ~/.claude/skills లోకి copy చేస్తుంది. ఆ సమస్య చిన్నదే. అయినా ఇది packaging ను ఎవరూ review చేయకముందే అభివృద్ధి చేసినట్లు సూచించే అంతరం. ఒకేసారి దీనిలో ఎంత భాగాన్ని స్వీకరించాలో నిర్ణయించేటప్పుడు ఈ విషయాన్ని గుర్తుంచుకోవాలి.

మిగతావన్నీ వదిలినా ఉంచాల్సినవి

బ్రాండింగ్‌ను తొలగిస్తే, మీరు ఏ agent ను నడిపినా నాలుగు నియమాలు స్వతంత్రంగా మిగులుతాయి.

• అనుమతి వాక్యం. తిరిగి మార్చలేని లేదా బయటకు ప్రభావం చూపే చర్యకు, user స్వయంగా రాసిన మాటలు AUTH: line గా ఉండాలి. quote కనుగొనలేని agent చర్య తీసుకోదు.
• జత తనిఖీ. ఒక defect ను సరిచేసిన తరువాత, అదే తప్పు construct కోసం మొత్తం project లో search చేసి count ను report చేయాలి. count సున్నా అయినా report చేయాలి.
• పరిశీలన ద్వారా verification. విరిగిపోయిన build పై నడిచే green targeted check, verification విఫలమైనదే; అది pass కాదు.
• ఫలితానికి ప్రాధాన్యమిచ్చిన reporting. Skip చేసినవి లేదా verification చేయకుండా మిగిలినవి ఉంటే, వాటిని నిశ్శబ్దంగా వదిలేయకుండా caveat గా స్పష్టంగా పేర్కొనాలి.

ఈ నాలుగు నియమాలను అమలు చేయడానికి ఎటువంటి ఖర్చు లేదు. వాటి compliance ను grep తో తనిఖీ చేయవచ్చు. ముందుగా ఇక్కడి నుంచే ప్రారంభించండి. తరువాత పై harness తో కొలవండి. ఆపై మిగిలిన repo మీ context budget లోని భాగానికి అర్హమా కాదా నిర్ణయించండి. Working method కు బదులుగా agent కు స్థిరమైన project context ఇవ్వాలనుకుంటే, agent edit చేయడానికి ముందు చదివే DESIGN.md దీనికి అనుబంధ మార్గం.

FAQ

Fable method Claude కాకుండా ఇతర models తో కూడా పనిచేస్తుందా?

Method text పనిచేస్తుంది. ఇది model-specific code లేని క్రమబద్ధమైన prompt. Codex, Cursor, aider లేదా raw system prompt కోసం repo AGENTS.md ను portable copyగా అందిస్తుంది. అయితే రెండు విషయాలు ఇతర చోట్ల పనిచేయవు. /fable-method మరియు /fable-judge triggers Claude Code slash commands. అందువల్ల ఇతర చోట్ల method ను ఉపయోగించాలంటే దాన్ని వివరించాలి. fable-loop వేర్వేరు models పై parallel subagents ను ప్రారంభించగల harness ఉందని భావిస్తుంది. అలాంటి harness లేకపోతే ఇది serialగా నడిచి, అదనపు దశలతో fable-method ను ఇస్తుంది.

ఈ skills ను నడపడం వల్ల tokens ఎక్కువ ఖర్చవుతాయా?

అవును. ఎంత ఖర్చవుతుందో వాటిని ఎలా load చేస్తారనే దానిపై ఆధారపడి ఉంటుంది. Skillsగా install చేసినప్పుడు description taskకు match అయినప్పుడే body load అవుతుంది. అందువల్ల సంబంధం లేని request కు దాదాపు ఎలాంటి అదనపు ఖర్చు ఉండదు. System promptలో paste చేస్తే సుమారు 2,600 పదాల AGENTS.md ప్రతి requestతో పాటు పంపబడుతుంది. Runకు కూడా ఎక్కువ ఖర్చవుతుంది. ఎందుకంటే method editingకు ముందు orientation, నిర్ణయం తీసుకునే ముందు evidence, అలాగే చివర్లో నిజమైన verification కోరుతుంది. దీన్ని కొలవండి: రెండు armsలోనూ --output-format json తో ఒకే taskను run చేసి, total_cost_usd fieldను పోల్చండి.

Fable-method లో ఏ versionను install చేయాలి? దాన్ని ఎందుకు pin చేయాలి?

Install చేయడానికి ముందు git checkout v1.4.0 ను run చేయండి. ఆ tag తేదీ 2026-07-15. August 2026 నాటికి అదే తాజా tagగా ఉంది. దానికి ముందు ఉన్న తొమ్మిది రోజుల్లో repo ఐదు releases ప్రచురించింది. v1.4.0 routing rulesనే మార్చింది. మీరు కొలుస్తున్న సమయంలో main ను track చేస్తే control run మరియు test run వేర్వేరు instructionsను చదివే అవకాశం ఉంది. అప్పుడు comparison కు విలువ ఉండదు. మీ resultsతో పాటు tagను record చేయండి.

Repoలోని evalను నేను నమ్మదగిన benchmarkగా పరిగణించవచ్చా?

దాన్ని methodకు సంబంధించిన change logగా పరిగణించండి. దాని author కూడా అదే విధంగా పేర్కొంటారు: "ఈ log methodలో చేసిన edits పరీక్షించబడుతున్నాయని చూపించడానికి ఉంది; ఎవరైనా దీన్ని benchmarkగా పొరబడటానికి కాదు." File ప్రారంభంలో limitations స్పష్టంగా ఉన్నాయి: ప్రతి cellకు 1 నుంచి 4 runs, synthetic fixtures, అలాగే baselineగా పనిచేసే అదే frontier modelపై నిర్మించిన LLM judges. Rounds నిజమైనవే. విఫలమైన experimentsను కూడా ఇందులో ఉంచారు. ఇది చాలా repos ప్రచురించేదానికంటే మెరుగైనది. అయినప్పటికీ మీ codebaseపై ఏమి జరుగుతుందో ఇది కొలవదు. అందువల్ల two-arm comparisonను మీరే run చేయండి.