Fable పద్ధతి: ఏ model‌కైనా agent skills

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

Fable పద్ధతి అనేది కొన్ని agent skills సమాహారం. ఇవి ఒక model పని చేసే విధానాన్ని క్రమబద్ధమైన ప్రక్రియగా లిఖితపరుస్తాయి. అందువల్ల వేరొక model అదే ప్రక్రియను అమలు చేయగలదు. ఈ repo Sahir619/fable-method MIT లైసెన్స్‌లో ఉంది. దాని స్వంత ఒక-లైన్ వివరణ: "how Claude Fable 5 worked, distilled into skills any model can run, with the eval that keeps it honest." ఈ వాక్యంలోని రెండో భాగాన్ని పరీక్షించడమే ముఖ్యమైన విషయం.

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

skill అనే పదం మీకు కొత్త అయితే, ముందుగా agent skill అంటే వాస్తవంగా ఏమిటి చూడండి. ఇది ఒక SKILL.md file ను కలిగి ఉన్న folder. ఆ file లోని frontmatter description body ను ఎప్పుడు load చేయాలో agent కు తెలియజేస్తుంది. ఈ repo పేరు పొందిన model గురించి 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 ను జాబితా చేస్తుంది. అక్కడ లేని వాటిని గమనించండి. Repo లో నాలుగు skills ఉన్నాయి, కానీ shell installer మూడింటినే copy చేస్తుంది. అందువల్ల standalone user స్వయంగా copy చేయకపోతే fable-domain పొందడు:

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

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

ఈ నాలుగు skills మోడల్‌కు ఏమి చేయమని చెబుతాయి

ప్రధాన నియమాల ఫైల్ `skills/fable-method/SKILL.md`. ఇందులో రెండు gates మరియు సంఖ్యలతో ఉన్న ఏడు steps ఉన్నాయి. దీని నియమాలు స్పష్టంగా ఉండటంతో వాటి ఆధారంగా నిర్ణయాలను సమర్థించవచ్చు.

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

తరువాత loop వస్తుంది: అభ్యర్థనను classify చేయాలి, పని పూర్తయినట్లు నిర్ణయించే ప్రమాణాలను define చేయాలి, 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 తో తిరిగి అప్పగించాలి.

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

fable-loop ఇదే method ను నాలుగు 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 అనేది evidence కాదు; అది claims సమాహారం." ఇది పూర్తయిన report నుంచి claims ను సేకరిస్తుంది. `git diff మరియు git status` ఆధారంగా ground truth ను నిర్ధారిస్తుంది. Report నడిపినట్లు చెప్పే ప్రతి verification ను మళ్లీ నడుపుతుంది. అలాగే పేరుతో పేర్కొన్న fraud list కోసం పరిశీలిస్తుంది: బలహీనపరచిన checks, తప్పుడు completion, scope creep, అనధికార action, spec betrayal, మరియు మిగిలిపోయిన debris. ఇది VERIFIED, VERIFIED WITH CAVEATS లేదా REFUTED ఫలితాలను ఇస్తుంది. మళ్లీ ఉత్పత్తి చేయలేని దేనినైనా అది పాస్ అయిందని ఊహించకుండా UNVERIFIABLE గా గుర్తిస్తుంది. Installer చివరి line కూడా దీనినే సూచిస్తుంది: "Try it: agent పని పూర్తయిందని చెప్పిన తరువాత Claude Code తెరిచి /fable-judge అని type చేయండి."

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

ఏ భాగాలు మరొక మోడల్‌కు అనుకూలంగా మారుతాయి, ఏవి కావు

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

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

ఒక భాగాన్ని మాత్రం సులభంగా port చేయలేరు. fable-loop లో harness parallel subagents ను ప్రారంభించి, వాటిని వేర్వేరు models కు పంపగలదని భావిస్తుంది. Subagents లేని agent ఈ stages ను ఒకే model పై serial గా అమలు చేస్తుంది. దాంతో ఈ design కు కారణమైన parallelism మరియు cost saving తొలగిపోతాయి. మిగిలేది అదనపు 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 చేస్తే, మీరు పంపే ప్రతి request లో ఆ 2,600 పదాలు ఉంటాయి. అది one-line typo fix అయినా, refactor అయినా ఇదే జరుగుతుంది. ఇది నిజమైన cost difference. 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 ను ఎంచుకోండి: తప్పనిసరిగా pass కావాల్సిన failing test లేదా 0 తో exit కావాల్సిన script. అస్పష్టమైన task అస్పష్టమైన పోలికకు దారితీస్తుంది, ఎందుకంటే ఫలితాల బదులు వివరణను అంచనా వేయాల్సి వస్తుంది.

--bare తో control arm ను నడపండి. ఇది hooks, skills, plugins మరియు CLAUDE.md యొక్క auto-discovery ను దాటవేస్తుంది. ఇదే దీన్ని 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 లో ఉంచండి, ఎందుకంటే user-invoked skills print mode లో expand అవుతాయి: claude -p "/fable-method $task". కనిపించే ప్రవర్తన ఒకేలా ఉన్నప్పటికీ, system-prompt arm తో పోలిస్తే cost profile భిన్నంగా ఉండవచ్చని ఆశించండి.

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

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

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

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

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

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

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

రెండు files కోసం దీన్ని run చేయండి. తేడా యొక్క రూపం totals కంటే ఎక్కువ సమాచారాన్ని ఇస్తుంది. ఎక్కువ files చదివి, తక్కువ edits చేసే method run, ఆ method కోరిన విధంగానే పనిచేస్తోంది. మీరు చెల్లిస్తున్న trade-off ఇదే. అదే edits చేసి, 40 percent ఎక్కువ ఖర్చు చేసిన method run ఆ taskలో మీకు ఏమీ ఇవ్వలేదు.

ఈ numbers గురించి రెండు జాగ్రత్తలు పాటించండి. మొదటిది, ~/.claude/projects/ కింద ఉన్న session transcripts నుంచి output_tokens విలువలను కలిపి total అని చెప్పకండి. ఆ per-message usage blocks streaming సమయంలో తీసుకున్న snapshots మాత్రమే. అవి తక్కువగా లెక్కిస్తున్నాయని తెలిపే open reports ఉన్నాయి. నమ్మాల్సిన సంఖ్య result line లో ఉన్నదే. రెండవది, ప్రతి arm కు ఒక run మాత్రమే చేస్తే అది anecdote అవుతుంది. అందువల్ల ఒక తేడాను నమ్మే ముందు అదే task పై ప్రతి arm ను మూడు లేదా నాలుగు సార్లు run చేయండి. ఎందుకంటే అదే task పై అదే agent చేసిన రెండు runs మధ్య కూడా ఇప్పటికే తేడా ఉంటుంది. ఖర్చు యొక్క దీర్ఘకాలిక చిత్రానికి, Claude Code ఖర్చును 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, diffing మరియు execution ద్వారా ధృవీకరించే blind LLM judges." దాదాపు ఏ skill repo విడుదల చేసే ఆధారాలకన్నా ఇది ఎక్కువ ఆధారాన్ని అందిస్తుంది. అలాగే eval/RESULTS.md ప్రతి రౌండ్‌ను విడిగా నమోదు చేస్తుంది; విఫలమైన సందర్భాలను కూడా ఉంచుతుంది. అయితే శీర్షికలోని సంఖ్య సూచించినంత విస్తృతంగా ఇది ఉండదు. శీర్షికలోని వరుసల వెనుక ఉన్న individual 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 rows లో అతిపెద్ద భాగం 4 runs పై ఆధారపడి ఉంటుంది. మిగిలిన మూడు rows ఒక్కొక్కటి 2 runs పై ఆధారపడి ఉంటాయి. Repo కూడా దీన్ని స్పష్టంగా చెబుతుంది. Log ప్రారంభంలో ఉన్న శాశ్వత పరిమితుల్లో ఇలా ఉంది: "మొత్తం మీద sample size చిన్నదే (ప్రతి cell కు 1-4 runs), LLM judges ఉపయోగించబడ్డాయి (బహుళ outputs ను పోల్చే సందర్భాల్లో blind గా ఉంటాయి, కానీ baseline గా కనిపించే అదే frontier model పై నిర్మించబడ్డాయి), synthetic fixtures ఉపయోగించబడ్డాయి, research ground truth దాని run date వరకు మాత్రమే తాజాగా ఉంటుంది." ఇంకా నేరుగా ఇలా చెబుతుంది: "ఈ log ఉద్దేశం method edits ను పరీక్షించడం మాత్రమే; దీన్ని benchmark గా ఎవరూ పొరబడకూడదు."

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

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

Packaging కేవలం సంప్రదాయాన్ని అనుసరించే విధంగా ఉంది

ఇక్కడ నాలుగు విమర్శలు చేయాలి. వాటిలో ఏదీ ఈ 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 కథనం కేవలం అలంకారం. ఈ procedure స్వతంత్రంగా సరిపోతుంది. దీనికి origin myth అవసరం లేదు.

నాలుగు skills అనేవి ఈ content కు అవసరమైన దానికంటే ఎక్కువ surface area కలిగిస్తున్నాయి. 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 ఏదీ లేదు. మీ field కు సంబంధించిన adapter ఇంకా బాగుండవచ్చు. అయితే అది trap fixture ను ఎదుర్కొని నిలిచినది కాదు; రచయిత తయారు చేసిన draft మాత్రమే.

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

మిగతా ఏదీ ఉంచకపోయినా ఉంచాల్సినవి

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

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

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

FAQ

Fable method ను Claude కాకుండా ఇతర models తో కూడా ఉపయోగించవచ్చా?

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

ఈ skills ను run చేయడానికి ఎక్కువ tokens ఖర్చవుతాయా?

అవును. ఎంత ఖర్చవుతుందో వాటిని ఎలా load చేస్తారనే దానిపై ఆధారపడి ఉంటుంది. Skills గా install చేసినప్పుడు description task కు సరిపోలినప్పుడే body load అవుతుంది. అందువల్ల సంబంధం లేని request కు దాదాపు ఎలాంటి అదనపు ఖర్చు ఉండదు. System prompt లో paste చేస్తే AGENTS.md లోని సుమారు 2,600 words ప్రతి 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 ను publish చేసింది. అందులో v1.4.0 routing rules ను మార్చింది. మీరు కొలుస్తున్న సమయంలో main ను track చేస్తే control run మరియు test run వేర్వేరు instructions ను చదివే అవకాశం ఉంది. అప్పుడు comparison కు విలువ ఉండదు. మీ results తో పాటు tag ను record చేయండి.

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

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