Fable method: எந்தவொரு AI மாடலிலும் பயன்படுத்துவது எப்படி?

Fable முறை உண்மையில் எதை வலியுறுத்துகிறது

Fable முறை என்பது ஒரு model-ன் பணிபுரியும் பழக்கவழக்கங்களை வரிசைப்படுத்தப்பட்ட நடைமுறையாக (ordered procedure) எழுதும் சில agent திறன்களின் தொகுப்பாகும். இதன் மூலம் மற்றொரு model அதே நடைமுறையை இயக்க முடியும். இந்த repo Sahir619/fable-method என்ற முகவரியில் உள்ளது, இது MIT உரிமம் பெற்றது. இதன் ஒரு வரி விளக்கம்: "Claude Fable 5 எவ்வாறு செயல்பட்டது என்பதை எந்தவொரு model-ம் இயக்கும் வகையில் திறன்களாக மாற்றி, அதைச் சரியாகச் சரிபார்க்கும் மதிப்பீட்டு முறையுடன் (eval) வழங்குதல்." இந்த வாக்கியத்தின் இரண்டாம் பாதியைச் சோதித்துப் பார்ப்பதே முக்கியமானது.

ஒரு குறிப்பிட்ட model எவ்வாறு சிந்தித்தது என்பதை ஒரு text file உண்மையில் பிரதிபலிக்கிறதா என்பதை Anthropic நிறுவனத்திற்கு வெளியே யாராலும் சரிபார்க்க முடியாது. ஆனால், அந்த text file-ஐப் படிக்கும்போது மலிவான model ஒன்று வித்தியாசமாகச் செயல்படுகிறதா என்பதை, ஒரே ஒரு VPS-ல், ஒரு மதிய நேரத்தில் நீங்களே சோதித்துப் பார்க்கலாம். கீழே உள்ள அனைத்தின் நோக்கமும் இந்த அளவீடுதான்: ஒரே பணியை, இந்த முறையைப் பயன்படுத்தியும் பயன்படுத்தாமலும் இருமுறை செய்து, tool calls மற்றும் செலவைக் கணக்கிடுவது.

'skill' என்ற சொல் உங்களுக்குப் புதியது என்றால், agent skill என்றால் என்ன என்பதிலிருந்து தொடங்கவும்: இது ஒரு folder-க்குள் இருக்கும் SKILL.md கோப்பாகும். அதன் frontmatter விளக்கம், அந்த body-ஐ எப்போது load செய்ய வேண்டும் என்று agent-க்குக் கூறுகிறது. இந்த repo-க்கு பெயர்க்காரணமாக இருந்த model பற்றிய விவரங்கள் Claude Fable 5-ன் செலவு மற்றும் அதன் சிறப்பம்சங்கள் பகுதியில் உள்ளன.

Skills-ஐ நிறுவுதல் மற்றும் நீங்கள் சோதிக்கும் version-ஐ pin செய்தல்

நிறுவுவதற்கு இரண்டு வழிகள் உள்ளன. Claude Code-க்குள், plugin வழிமுறை இரண்டு கட்டளைகளைக் கொண்டது:

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

ஒரு VPS-ல், disk-ல் ஒரு pinned 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 மூன்றை மட்டுமே நகலெடுக்கிறது. எனவே, ஒரு தனிப்பட்ட பயனர் fable-domain-ஐ கைமுறையாக நகலெடுக்காவிட்டால் அது கிடைக்காது:

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

Tag-ஐ pin செய்யவும், மேலும் நீங்கள் பெறும் முடிவுகளுக்கு அருகில் அந்த tag-ஐ குறித்து வைக்கவும். இந்த repo 2026-07-06 முதல் 2026-07-15 வரை ஐந்து releases-ஐ வெளியிட்டது, v1.0.0 முதல் v1.4.0 வரை. இதில் v1.4.0 ஒரு புதிய routing gate-ஐச் சேர்ப்பதன் மூலம் முறையையே மாற்றியது. ஆகஸ்ட் 2026 நிலவரப்படி, v1.4.0 தான் புதிய tag ஆகும். உங்கள் control run ஒரு version விதிகளையும், உங்கள் test run வேறொரு version விதிகளையும் படித்தால், நீங்கள் எதையும் அளவிடவில்லை என்று அர்த்தம்.

நான்கு திறன்களும் மாடலுக்கு என்ன செய்யச் சொல்கின்றன

சுமை தாங்கும் கோப்பு skills/fable-method/SKILL.md ஆகும். இது இரண்டு வாயில்களையும் (gates) ஏழு எண்ணிடப்பட்ட படிகளையும் கொண்டுள்ளது, மேலும் இதன் விதிகள் விவாதிக்கும் அளவுக்குத் துல்லியமானவை.

முதலாவது அற்பத்தன்மை வாயில் (triviality gate): மாற்றம் ஒரு கோப்பை மட்டும் தொடும்போது, சுமார் 10 வரிகளுக்குள் இயங்கும்போது, புதிய செயல்பாட்டைச் சேர்க்காதபோது, மற்றும் நீங்கள் எதை மாற்ற வேண்டும் என்று ஏற்கனவே தெரிந்திருக்கும்போது, எந்தச் சடங்கும் இன்றி நேரடியாகச் செயல்படுங்கள். அந்த உள்ளுணர்வை மட்டுமே அடிப்படையாகக் கொண்டு ஒரு தனித் திறன் கட்டமைக்கப்பட்டுள்ளது, Ponytail, இது ஒரு ஏஜென்டைச் செயல்படும் மிகச்சிறிய மாற்றத்தை நோக்கித் தள்ளுகிறது, மேலும் அதன் முக்கிய விதியை எதையும் நிறுவ வேண்டிய அவசியமின்றி உங்கள் சொந்த அறிவுறுத்தல்களில் நகலெடுக்கும் அளவுக்குச் சுருக்கமாக உள்ளது. அடுத்ததாகப் பொருத்தம் வாயில் (fit gate) வருகிறது; இது பதில்கள் எங்கு உள்ளன என்பதைப் பொறுத்து கோரிக்கையை வழிநடத்துகிறது: நீங்கள் திறக்கக்கூடிய மூலங்கள், முதலில் ஆய்வு செய்ய வேண்டிய நுட்பம், அல்லது உங்கள் சொந்த அனுமானம் (இதை உண்மையாக முன்வைக்காமல் குறைந்த நம்பிக்கை கொண்டதாகக் குறிப்பிட வேண்டும்). அந்த நடுப்பகுதி, ஏஜென்ட் உண்மையில் இணையத்தை அணுக முடிந்தால் மட்டுமே செயல்படும்; இது பாதுகாக்கப்பட்ட VPS-ல் இருந்தால், அதற்குச் சொந்தமான தேடல் backend-ஐ வழங்க வேண்டும், உதாரணமாக JSON தேடல் கருவியாக வெளிப்படுத்தப்பட்ட self-hosted SearXNG instance.

பிறகு லூப்: கோரிக்கையை வகைப்படுத்துதல், 'முடிந்தது' என்பதை வரையறுத்தல், ஆதாரங்களைச் சேகரித்தல், முடிவெடுத்தல், செயல்படுதல், சரிபார்த்தல், அறிக்கை செய்தல். படி 2, கோப்புகளைத் தேர்ந்தெடுப்பதற்கு முன் directory-ஐப் பட்டியலிட்டுத் திசையமைப்பை உறுதி செய்யச் சொல்கிறது, நினைவாற்றலை விட முதன்மை மூலங்களுக்கு முன்னுரிமை அளிக்கச் சொல்கிறது, மேலும் புதிய தகவல்களைத் தராத இரண்டு தொடர்ச்சியான தேடல்களுக்குப் பிறகு நிறுத்தச் சொல்கிறது. படி 4, எந்தவொரு திருத்தத்திற்கும் முன் ஒரு INTENT: வரியை எழுதச் சொல்கிறது; அதில் குறியீடு என்ன செய்கிறது, தோல்வியுற்ற சோதனை என்ன எதிர்பார்க்கிறது, மற்றும் spec என்ன சொல்கிறது என்பதைக் குறிப்பிட வேண்டும். இவை மூன்றிற்கும் முரண்பாடு இருந்தால் திருத்த வேண்டாம், ஏனெனில் அந்த முரண்பாடே உண்மையான கண்டுபிடிப்பு. படி 5, மறுமுயற்சிகளைக் கட்டுப்படுத்துகிறது: ஒரே சிக்கலில் மூன்று தோல்வியுற்ற திருத்தம்-மற்றும்-சரிபார்ப்பு சுழற்சிகளுக்குப் பிறகு, நிறுத்திவிட்டு உண்மையான வெளியீட்டுடன் திரும்ப ஒப்படைக்க வேண்டும்.

கோப்பின் மிகவும் சோதிக்கக்கூடிய பகுதி அதன் நான்கு அறிக்கை டோக்கன்கள் ஆகும். ஒரு நடத்தை மாற்றத்திற்கு INTENT: வரி தேவை. வெளிநோக்கிய செயல்பாட்டிற்கு AUTH: user said "<exact words>" தேவை, இது பயனரை மேற்கோள் காட்டுகிறது, ஏனெனில் ஆவணங்கள் என்பது அங்கீகாரம் அல்ல என்று repo தெளிவாகக் கூறுகிறது. பரிந்துரைக்கப்பட்ட ஆனால் எடுக்கப்படாத செயல்பாட்டிற்கு PENDING: வரி தேவை. சரிசெய்யப்பட்ட குறைபாட்டிற்கு TWINS: searched <pattern> - found <N> other sites தேவை. அந்த நான்கு சரங்களும் தேவைப்படும்போது தோன்றுகின்றனவா என்பதைச் சரிபார்க்க நீங்கள் முறையை நம்ப வேண்டியதில்லை, இதுவே முழு விஷயத்தையும் வெறும் உணர்வுகளாக இல்லாமல் அளவிடக்கூடியதாக மாற்றுகிறது.

fable-loop என்பது நான்கு நிலைகளில் ஒரு orchestration-ஆக இயங்கும் அதே முறையாகும்: இணையான ஆதார subagents-உடன் திட்டமிடுதல், main thread-ல் செயல்படுத்துதல், வெவ்வேறு கோணங்களைக் கொண்ட ஒன்று முதல் மூன்று தாக்குதல் subagents-ஐக் கொண்டு சரிபார்த்தல், பிறகு தணிக்கை செய்து அறிக்கை செய்தல். இது ஆதாரங்கள் மற்றும் தாக்குதல் பாத்திரங்களில் மலிவான மாடல்களையும், முடிவுகள் மற்றும் திருத்தங்களில் வலிமையான மாடலையும் பயன்படுத்துகிறது.

fable-judge என்பது மற்றவற்றைத் தூக்கி எறிந்தாலும் நிறுவுவதற்குத் தகுதியான பகுதியாகும். "ஒரு அறிக்கை என்பது ஆதாரங்களின் தொகுப்பு, ஆதாரமே அல்ல" என்பதே இதன் நிலைப்பாடு. இது ஒரு முடிக்கப்பட்ட அறிக்கையிலிருந்து உரிமைகோரல்களைச் சேகரிக்கிறது, git diff மற்றும் git status ஆகியவற்றிலிருந்து அடிப்படை உண்மையை நிறுவுகிறது, அறிக்கை செய்ததாகக் கூறும் ஒவ்வொரு சரிபார்ப்பையும் மீண்டும் இயக்குகிறது, மேலும் மோசடிப் பட்டியலைத் தேடுகிறது: பலவீனமான சோதனைகள், தவறான நிறைவு, scope creep, அங்கீகரிக்கப்படாத செயல்பாடு, spec மீறல், மற்றும் எஞ்சிய குப்பைகள். இது VERIFIED, VERIFIED WITH CAVEATS, அல்லது REFUTED என்று திரும்ப அளிக்கிறது, மேலும் அது மீண்டும் உருவாக்க முடியாத எதையும் அது தேர்ச்சி பெற்றதாகக் கருதாமல் UNVERIFIABLE என்று குறிக்கிறது. நிறுவியின் சொந்த முடிவு வரி இதைக் காட்டுகிறது: "முயற்சி செய்யுங்கள்: Claude Code-ஐத் திறந்து, ஏஜென்ட் வேலை முடிந்துவிட்டதாகக் கூறிய பிறகு /fable-judge என்று தட்டச்சு செய்யுங்கள்." வேலை முடிந்த பிறகு இயக்குவதை விட, வேலையிலேயே அந்தச் சோதனையை உருவாக்க விரும்பினால், Old Coder திறன், நீங்கள் அங்கீகரிக்கும் ஒரு SPEC-ஐயும், நீங்களே மீண்டும் இயக்கக்கூடிய ஒரு EVIDENCE அறிக்கையையும் ஏஜென்டை உருவாக்கச் செய்கிறது, இதில் mutation testing என்பது ஒரு சோதனை உண்மையில் regression-ஐக் கண்டறியும் என்பதற்கான ஆதாரமாகச் செயல்படுகிறது.

fable-domain என்பது trap fixtures மற்றும் smoke evals கொண்ட domain adapter தொகுப்புகளை உருவாக்குகிறது. எட்டு adapters உள்ளன: marketing, research, data analysis, business and ops, finance, legal and compliance, design and UX, மற்றும் devops. மருத்துவ மற்றும் மருத்துவமனை சார்ந்த பணிகள் வேண்டுமென்றே இதில் சேர்க்கப்படவில்லை.

எந்தப் பகுதிகள் மற்ற மாடல்களுக்கு மாற்றத்தக்கவை, எவை மாற்றத்தக்கவை அல்ல

இந்தக் களஞ்சியம் (repo) இதற்கான பதிலை AGENTS.md மூலம் நேரடியாக வழங்குகிறது: "எந்தவொரு coding agent அல்லது harness-க்கும் (Codex, Cursor, aider, ஒரு raw system prompt) ஏற்றவாறு மாற்றக்கூடிய பதிப்பு. SKILL.md-ன் அதே முறை; இந்தக் கோப்பை உங்கள் agent அறிவுறுத்தல்களில் ஒட்டவும் அல்லது உங்கள் repo-வின் root-ல் AGENTS.md எனச் சேமிக்கவும்." இது சுமார் 2,600 சொற்களைக் கொண்டது மற்றும் அதே gates, steps மற்றும் modes-களைக் கொண்டுள்ளது. நீங்கள் ஏற்கனவே repo-root அறிவுறுத்தல் கோப்புகளைப் பயன்படுத்துபவர் என்றால், AGENTS.md மற்றும் HUMAN.md மரபு அந்தக் கோப்பு எங்கு இருக்க வேண்டும், யார் அதைப் படிக்க வேண்டும் என்பதை விளக்குகிறது.

இரண்டு பகுதிகள் எளிதாக மாற்றத்தக்கவை. இந்த முறையின் உரை (method text) என்பது மாடல்-சார்ந்த குறியீடுகள் இல்லாத, வரிசைப்படுத்தப்பட்ட ஒரு prompt ஆகும். எனவே, அறிவுறுத்தல்களைப் பின்பற்றும் எந்தவொரு மாடலும் இதைப் பின்பற்ற முடியும். மாடலின் தரம் அதிகரிக்க, அதற்கான உழைப்பு குறையும் என்பதே இந்தக் களஞ்சியத்தின் அடிப்படை வாதம். judge-ம் மாற்றத்தக்கது; agent-க்கு shell மற்றும் repository அணுகல் இருந்தால் போதும். ஏனெனில், அது செய்யும் அனைத்தும் git diff மற்றும் பயனர் இயக்கக்கூடிய கட்டளைகளை மீண்டும் இயக்குவது மட்டுமே.

ஒரு பகுதி மட்டும் எளிதாக மாற்றத்தக்கதல்ல. fable-loop என்பது, harness-ஆல் இணையாக (parallel) subagents-களை உருவாக்கி அவற்றை வெவ்வேறு மாடல்களுக்கு அனுப்ப முடியும் என்று கருதுகிறது. subagents இல்லாத ஒரு agent, அந்த நிலைகளை ஒரே மாடலில் வரிசையாக (serially) இயக்கும். இது வடிவமைப்பின் நோக்கமான parallelism மற்றும் செலவு சேமிப்பை நீக்கிவிடுகிறது. இறுதியில் எஞ்சுவது கூடுதல் சொற்களஞ்சியத்துடன் கூடிய fable-method மட்டுமே.

சிறிய விஷயங்கள் இரண்டு harness-க்கு மட்டுமே உரியவை, அவற்றை எளிதில் கவனிக்கத் தவறிவிடலாம். /fable-method trigger என்பது ஒரு Claude Code slash command ஆகும். எனவே, மற்றொரு harness-ல் நீங்கள் இந்த முறையை விவரிப்பதன் மூலம் செயல்படுத்த வேண்டும். மேலும், SKILL.md frontmatter விளக்கம் என்பது, ஒரு பணிக்குத் தேவைப்படும்போது மட்டுமே agent அந்தப் பகுதியை ஏற்றிக்கொள்ள உதவுகிறது. அதாவது, நிறுவப்பட்ட ஒரு திறன் (skill) செயல்படுத்தப்படும் வரை எந்தச் செலவையும் ஏற்படுத்தாது. அதற்குப் பதிலாக AGENTS.md-ஐ ஒரு system prompt-ல் ஒட்டினால், அந்த 2,600 சொற்களும் நீங்கள் அனுப்பும் ஒவ்வொரு கோரிக்கையிலும் இடம்பெறும். அது ஒரு வரியைத் திருத்தும் பணியாக இருந்தாலும் சரி, அல்லது ஒரு பெரிய refactor பணியாக இருந்தாலும் சரி. இது ஒரு உண்மையான செலவு வேறுபாடு. திறன் தொகுப்பு (skill packaging) இருப்பதற்கான முக்கிய காரணமே இதுதான்.

VPS-ல் A/B சோதனை செய்வது எப்படி: ஒரே பணியை இருமுறை செய்தல்

இரண்டு ஒரே மாதிரியான working copies-ஐ அமைக்கவும், அப்போதுதான் ஒரு 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

கருத்து வேறுபாடுகளுக்கு இடமில்லாத, கண்கூடாகப் பார்க்கக்கூடிய முடிவுகளைத் தரும் ஒரு பணியைத் தேர்ந்தெடுக்கவும்: வெற்றி பெற வேண்டிய ஒரு failing test அல்லது 0 என exit ஆக வேண்டிய ஒரு script. தெளிவற்ற பணி தெளிவற்ற ஒப்பீட்டையே தரும், ஏனெனில் முடிவுகளுக்குப் பதிலாக நீங்கள் உரைநடையை (prose) மதிப்பீடு செய்ய வேண்டியிருக்கும்.

Control arm-ஐ --bare கொண்டு இயக்கவும், இது hooks, skills, plugins மற்றும் CLAUDE.md ஆகியவற்றின் auto-discovery-ஐத் தவிர்க்கும். அந்த flag தான் இதை ஒரு control-ஆக மாற்றுகிறது: நீங்கள் முன்பு நிறுவிய 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 கூடுதலாக ஏற்றும்:

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-ஐ நிறுவி, skill பெயரை prompt string-க்குள் வைக்கவும், ஏனெனில் user-invoked skills print mode-ல் விரிவடையும்: claude -p "/fable-method $task". காணக்கூடிய செயல்பாடு ஒரே மாதிரியாக இருந்தாலும், cost profile மாறுபடும் என்பதை எதிர்பார்க்கலாம்.

படிகளின் எண்ணிக்கை மற்றும் செலவைக் கணக்கிடுதல்

இரண்டு இயக்கங்களும் (runs) JSON நிகழ்வுகளின் தொடர்ச்சியை உருவாக்கின. கடைசி வரியில் உள்ள result செய்தி, இறுதி உரை, செலவு மற்றும் session மெட்டாடேட்டாவைக் கொண்டிருக்கும். எந்தவொரு script-ஐயும் உருவாக்கும் முன், அந்த வரியை ஒருமுறை அச்சிட்டுப் படித்துப் பார்க்கவும், ஏனெனில் Claude Code releases-க்கு இடையே field பெயர்கள் மாறக்கூடும்.

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

ஒவ்வொரு இயக்கத்திற்கான செலவும் அந்த வரியிலிருந்தே கிடைக்கிறது, அதைத்தான் நீங்கள் ஒப்பிட வேண்டும்:

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

அதே கோப்பில் உள்ள tool calls-ஐ எண்ணுவதன் மூலம் எடுக்கப்பட்ட படிகளின் எண்ணிக்கை கிடைக்கிறது:

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

இரண்டு கோப்புகளுக்கும் இதை இயக்கவும். அந்த வித்தியாசத்தின் வடிவம், மொத்த எண்ணிக்கையை விட அதிகத் தகவல்களைத் தரும். அதிக கோப்புகளைப் படித்துக் குறைவான மாற்றங்களைச் செய்யும் ஒரு முறை, அந்த முறை எதற்காகக் கேட்கப்பட்டதோ அதைச் செய்கிறது; அதுதான் நீங்கள் பெறும் பலன். அதே மாற்றங்களைச் செய்து, நாற்பது சதவீதம் அதிக செலவாகும் ஒரு முறை, அந்தப் பணியில் உங்களுக்கு எந்தப் பலனையும் தரவில்லை.

எண்களைப் பொறுத்தவரை இரண்டு எச்சரிக்கைகள். முதலாவதாக, ~/.claude/projects/-க்குக் கீழ் உள்ள session transcripts-லிருந்து output_tokens-ஐக் கூட்டி அதை மொத்தத் தொகை என்று அழைக்காதீர்கள்: அந்த per-message usage தொகுதிகள் streaming-ன் போது எடுக்கப்பட்ட snapshots ஆகும், மேலும் அவை குறைவாகக் கணக்கிடப்படுவதாகப் புகார்கள் உள்ளன. result வரியே நீங்கள் நம்ப வேண்டிய எண். இரண்டாவதாக, ஒரு பணிக்கு ஒரு இயக்கம் என்பது ஒரு தனிப்பட்ட அனுபவம் மட்டுமே, எனவே ஒரு வித்தியாசத்தை நம்புவதற்கு முன், அதே பணியில் ஒவ்வொரு முறையையும் மூன்று அல்லது நான்கு முறை இயக்கவும், ஏனெனில் ஒரே agent ஒரே பணியை இரண்டு முறை செய்தாலே அவற்றுக்கிடையே வேறுபாடுகள் இருக்கும். செலவு குறித்த நீண்டகாலப் பார்வைக்கு, Claude Code செலவைக் கண்காணிக்கும் கருவிகள் மற்றும் Claude Code tokens-ஐ எவ்வாறு கணக்கிடுகிறது ஆகியன cache வரிகள் ஏன் raw counts-ஐ விட அதிகமாக உள்ளன என்பதை விளக்குகின்றன.

Agent கவனிக்கப்படாமல் இயங்கும்போது, உங்களுக்கு முக்கியமான எதையும் அது அணுக முடியாது என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். Claude Code-ஐ VPS-ல் பாதுகாப்பாக இயக்குவது என்பது பயனர் கணக்கு மற்றும் permission flags பற்றிய விவரங்களை உள்ளடக்கியது.

Repository-ன் சொந்த மதிப்பீடு, நேர்மையான வாசிப்பு

README-ன் தலைப்பு "பதினைந்து மதிப்பீட்டுச் சுற்றுகள், 260-க்கும் மேற்பட்ட ஏஜென்ட் இயக்கங்கள், diffing மற்றும் execution மூலம் சரிபார்க்கும் குருட்டு LLM நடுவர்கள்" என்பதாகும். இது பெரும்பாலான திறன் களஞ்சியங்கள் (skill repos) வெளியிடுவதை விட அதிக ஆதாரங்களைக் கொண்டுள்ளது, மேலும் eval/RESULTS.md தோல்விகளை நீக்காமல் ஒவ்வொரு சுற்றாக எழுதப்பட்டுள்ளது. தலைப்பு வரிசையில் உள்ள எண்களை விட, தனிப்பட்ட செல்களைப் பார்க்கும்போது இது மெலிதாகத் தெரிகிறது.

[
  {
    "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 இயக்கங்களை அடிப்படையாகக் கொண்டவை. மற்ற மூன்று வரிசைகளும் தலா 2 இயக்கங்களைக் கொண்டுள்ளன. பதிவின் தொடக்கத்தில் உள்ள வரம்புகள் குறித்த குறிப்பில் களஞ்சியமே இதைக் குறிப்பிடுகிறது: "முழுவதும் சிறிய n (ஒவ்வொரு செல்லுக்கும் 1-4 இயக்கங்கள்), LLM நடுவர்கள் (பல வெளியீடுகள் ஒப்பிடப்படும்போது குருட்டுத்தன்மை கொண்டது, ஆனால் அதே frontier model-ஐ அடிப்படையாகக் கொண்டது), செயற்கை fixtures, ஆராய்ச்சி உண்மைத்தன்மை (ground truth) அதன் இயக்கத் தேதியைப் பொறுத்தது மட்டுமே." மேலும் நேரடியாகக் கூறினால்: "இந்த முறை மாற்றங்கள் சோதிக்கப்பட வேண்டும் என்பதற்காகவே இந்த பதிவு உள்ளது, இது ஒரு benchmark என்று யாரும் தவறாகக் கருதக்கூடாது."

இதற்கு மதிப்பளிக்க வேண்டும். தனது சொந்த n-ஐ வெளியிடும் ஒரு ஆசிரியர், தனது நடுவர் அதே baseline model-ஐ அடிப்படையாகக் கொண்டது என்ற சிக்கலை வெளிப்படையாகக் கூறுவது, இந்த வகைப்பாட்டில் வழக்கமாக இருப்பதை விட நேர்மையானது. ஆசிரியர் உண்மையில் சோதனைகளை இயக்கி, தோல்விகளைப் பதிவு செய்ததற்கான ஆதாரமாக இந்த எண்களைக் கருதவும். உங்கள் சொந்த codebase-ஐப் பொறுத்தவரை, உங்கள் A/B சோதனை மட்டுமே உங்களுக்கு உண்மையான தகவலைத் தரும்.

இந்த முறை எங்கு பலனளிக்காது என்பது குறித்தும் README தெளிவாக உள்ளது, அதுவே அதன் மிக பயனுள்ள பத்தியாகும். திறன்மிக்க மாதிரிகளில் (capable models) சாதாரண சிறிய பணிகளுக்கு இது எந்த முன்னேற்றத்தையும் தருவதில்லை. "இந்த முறையால் ஒரு மாதிரியின் தகவல்களைப் புதுப்பிக்க முடியாது; அறிவு சார்ந்த ஆராய்ச்சியில் அடிப்படை frontier மாதிரிகளே வெற்றி பெறும்" என்று அது கூறுகிறது. மேலும், "பொறிகள் (அதிகார முரண்பாடுகள், தவறான நிறைவு கோரிக்கைகள், பலவீனமான executors, கவனிக்கப்படாத இயக்கங்கள்) போன்ற இடங்களில் மட்டுமே இதன் மதிப்பு உள்ளது, எல்லா இடங்களிலும் அல்ல" என்று அது குறிப்பிடுகிறது. நீங்கள் கவனித்துக்கொண்டிருக்கும்போது ஒரு வலுவான மாதிரியில் சிறிய மாற்றங்களைச் செய்யும் ஏஜென்ட் பணியாக இருந்தால், எந்த மாற்றத்தையும் நீங்கள் அளவிட முடியாது. இதுவே கவனிக்கப்படாத மலிவான மாதிரியாக இருந்தால், அங்கு ஒரு இடைவெளி தெரியும், இதுவே Opus, Sonnet மற்றும் Haiku ஆகியவற்றுக்கு இடையேயான தேர்வு என்பதையும் அதே முடிவின் ஒரு பகுதியாக மாற்றுகிறது.

பேக்கேஜிங் ஒரு சடங்காக இருக்கும் இடம்

நான்கு விமர்சனங்களை முன்வைக்கலாம், ஆனால் இவை எவையும் இந்த repo-வை தவிர்ப்பதற்கான காரணங்கள் அல்ல.

இதன் கட்டமைப்பு ஆதாரங்களை விட அதிகமாகப் பேசுகிறது. "Claude Fable 5 எவ்வாறு செயல்பட்டது" என்பது ஒரு மாதிரியின் (model) உட்புற செயல்பாடுகள் குறித்த கூற்று; இதை Anthropic நிறுவனத்திற்கு வெளியே யாராலும் சரிபார்க்க முடியாது. இந்த repo-வின் மைய வாக்கியமே இதை மறுக்கிறது: "தரம் என்பது கட்டமைப்பிலும், ஆதாரத்திலும், நேர்மையிலும் உள்ளது, மாதிரியில் இல்லை." தரம் கட்டமைப்பில் இருந்தால், அதன் தோற்றம் குறித்த கதை ஒரு அலங்காரம் மட்டுமே. இந்த நடைமுறை தானாகவே வலுவானது, இதற்கு ஒரு தோற்றக் கதை தேவையில்லை.

நான்கு திறன்கள் (skills) என்பது உள்ளடக்கத்திற்குத் தேவையானதை விட மேலோட்டமாக உள்ளது. fable-loop, fable-method-ன் பெரும்பகுதியை மீண்டும் கூறுகிறது, அதைச் சுற்றி ஒரு orchestration-ஐ அமைக்கிறது. subagents இல்லாத ஒரு சூழலில், இது மீண்டும் fable-method-ஆகவே சுருங்கிவிடும். இரண்டையும் நிறுவும் முன், அந்த இரண்டு கோப்புகளையும் அருகருகே வைத்துப் படியுங்கள்.

எட்டு domain adapters என்பது இந்த eval சோதிக்காத ஒரு பரந்த அளவிலான வசதியாகும். அந்த எட்டில் இரண்டு மட்டுமே log-ல் காணப்படுகின்றன: round 9-ல் marketing, round 12-ல் devops. finance, legal, design மற்றும் data adapters ஆகியவற்றுக்கு எந்தவொரு round-ம் இல்லை. உங்கள் துறைக்கான adapter சிறப்பாக இருக்கலாம். இருப்பினும், இது ஒரு சோதனைக் களத்தில் (trap fixture) தேர்ச்சி பெற்றதல்ல, ஆசிரியரின் வரைவு மட்டுமே.

மேலும், installer எதை வழங்குகிறது என்பதில் repo-வுடன் முரண்படுகிறது, நான்கு திறன்களில் மூன்றை ~/.claude/skills-க்குள் நகலெடுக்கிறது. இது சிறிய குறைபாடுதான். ஆனால், பேக்கேஜிங் சரிபார்க்கப்படுவதற்கு முன்பே வேகமாக மாற்றப்பட்டுள்ளது என்பதை இது காட்டுகிறது. இதை எவ்வளவு விரைவாக முழுமையாகப் பயன்படுத்தலாம் என்று முடிவெடுக்கும்போது இதைக் கவனத்தில் கொள்ள வேண்டும்.

வேறு எதையும் கடைபிடிக்காவிட்டாலும் கவனத்தில் கொள்ள வேண்டியவை

பிராண்டிங் அம்சங்களை நீக்கினாலும், நீங்கள் எந்த ஏஜெண்டைப் பயன்படுத்தினாலும் பின்வரும் நான்கு விதிகள் தனித்துச் செயல்படும்.

• அங்கீகார மேற்கோள் (Authorization quote). மாற்ற முடியாத அல்லது வெளிப்புறமாகச் செயல்படும் எந்தவொரு செயலுக்கும், பயனரின் சொந்த வார்த்தைகள் தேவை. அவை AUTH: வரியாக எழுதப்பட வேண்டும். மேற்கோளைக் கண்டறிய முடியாத ஏஜெண்ட் எந்தச் செயலையும் செய்யக்கூடாது.
• இரட்டைச் சரிபார்ப்பு (Twin check). ஒரு பிழையைச் சரிசெய்த பிறகு, அதே தவறான அமைப்பு திட்டத்தின் பிற இடங்களிலும் உள்ளதா என்று தேடி, அதன் எண்ணிக்கையை அறிக்கையிட வேண்டும்; எண்ணிக்கை பூஜ்ஜியமாக இருந்தாலும் அதைக் குறிப்பிட வேண்டும்.
• கண்காணிப்பு மூலம் சரிபார்ப்பு (Verification by observation). உடைந்த build-ன் மேல் ஒரு பச்சை நிற இலக்குச் சரிபார்ப்பு (targeted check) இருப்பது தோல்வியுற்ற சரிபார்ப்பே தவிர, அது வெற்றி அல்ல.
• விளைவை முன்னிலைப்படுத்தும் அறிக்கை (Outcome-first reporting). தவிர்க்கப்பட்ட அல்லது சரிபார்க்கப்படாத விஷயங்களை அமைதியாக நீக்காமல், அவற்றை எச்சரிக்கையாக (caveat) குறிப்பிட வேண்டும்.

இந்த நான்கையும் பின்பற்றுவதற்கு எந்தச் செலவும் இல்லை, மேலும் இணக்கத்தன்மையை (compliance) grep மூலம் சரிபார்க்கலாம். இதிலிருந்து தொடங்குங்கள், மேலே உள்ள harness மூலம் அளவிடுங்கள், பின்னர் மீதமுள்ள repo உங்கள் context budget-க்குத் தகுதியானதா என்பதை முடிவு செய்யுங்கள். ஒரு ஏஜெண்டிற்குச் செயல்பாட்டு முறையை விட, திட்டத்தின் பின்னணித் தகவல்களை (project context) வழங்க விரும்பினால், ஏஜெண்டுகள் திருத்துவதற்கு முன் வாசிக்கும் ஒரு DESIGN.md கோப்பை உருவாக்குவது சிறந்த அடுத்தகட்ட நடவடிக்கையாகும்.

FAQ

Fable முறை Claude அல்லாத பிற மாதிரிகளிலும் (models) செயல்படுமா?

இந்த முறையின் உரை செயல்படும். இது எந்தவொரு குறிப்பிட்ட மாதிரிக்கும் (model) உரிய குறியீடுகள் இல்லாத, வரிசைப்படுத்தப்பட்ட prompt ஆகும். இந்த repo, Codex, Cursor, aider அல்லது raw system prompt-களுக்காக AGENTS.md-ஐ ஒரு portable நகலாக வழங்குகிறது. இரண்டு விஷயங்கள் மட்டும் மாறாது. /fable-method மற்றும் /fable-judge தூண்டுதல்கள் (triggers) Claude Code slash commands என்பதால், பிற இடங்களில் நீங்கள் இந்த முறையை விவரிப்பதன் மூலம் செயல்படுத்த வேண்டும். மேலும், fable-loop என்பது வெவ்வேறு மாதிரிகளில் இணையாக subagents-களை உருவாக்கும் ஒரு harness-ஐ அடிப்படையாகக் கொண்டது; அது இல்லையெனில், இது வரிசையாக இயங்கி, கூடுதல் படிகளுடன் fable-method-ஐ உங்களுக்கு வழங்கும்.

இந்தத் திறன்களை (skills) இயக்குவதற்கு அதிக tokens செலவாகுமா?

ஆம், நீங்கள் அவற்றை எவ்வாறு ஏற்றுகிறீர்கள் என்பதைப் பொறுத்து செலவு மாறுபடும். திறன்களாக நிறுவப்படும்போது, பணியின் விவரணத்துடன் பொருந்தும்போது மட்டுமே அதன் உள்ளடக்கம் ஏற்றப்படும், எனவே தொடர்பில்லாத கோரிக்கைகளுக்கு கிட்டத்தட்ட எந்தச் செலவும் இருக்காது. System prompt-ல் ஒட்டப்படும்போது, சுமார் 2,600 சொற்கள் கொண்ட AGENTS.md ஒவ்வொரு கோரிக்கையிலும் உடன் வரும். திருத்துவதற்கு முன் நோக்குநிலை (orientation), முடிவெடுப்பதற்கு முன் சான்றுகள் (evidence), மற்றும் உண்மையான சரிபார்ப்பு (verification) ஆகியவற்றை இந்த முறை கோருவதால், இயக்கத்தின் போதும் அதிக செலவாகும். இதை அளவிடுங்கள்: --output-format json-ஐப் பயன்படுத்தி ஒரே பணியை இரு முறைகளிலும் இயக்கி, total_cost_usd புலத்தை ஒப்பிட்டுப் பாருங்கள்.

நான் எந்த fable-method பதிப்பை நிறுவ வேண்டும், ஏன் அதை pin செய்ய வேண்டும்?

நிறுவுவதற்கு முன் git checkout v1.4.0-ஐ இயக்கவும். அந்த tag 2026-07-15 தேதியிடப்பட்டது மற்றும் ஆகஸ்ட் 2026 நிலவரப்படி அதுவே புதியது. அதற்கு முந்தைய ஒன்பது நாட்களில் இந்த repo ஐந்து releases-களை வெளியிட்டது, மேலும் v1.4.0 routing விதிகளை மாற்றியது. நீங்கள் அளவிடும்போது main-ஐப் பின்தொடர்வது, உங்கள் control run மற்றும் test run ஆகியவை வெவ்வேறு அறிவுறுத்தல்களைப் படிக்கக்கூடும் என்பதால், ஒப்பீட்டைப் பயனற்றதாக்கும். உங்கள் முடிவுகளுடன் அந்த tag-ஐயும் பதிவு செய்யுங்கள்.

இந்த repo-வில் உள்ள eval நான் நம்பக்கூடிய ஒரு benchmark-ஆ?

இதை இந்த முறையின் மாற்றப் பதிவாக (change log) கருதுங்கள், அதன் ஆசிரியரும் அதையே கூறுகிறார்: "முறை மாற்றங்கள் சோதிக்கப்பட வேண்டும் என்பதற்காகவே இந்த log உள்ளது, இதை யாரும் benchmark என்று தவறாகக் கருதக்கூடாது." கோப்பின் தொடக்கத்திலேயே அதன் வரம்புகள் குறிப்பிடப்பட்டுள்ளன: ஒரு cell-க்கு 1 முதல் 4 இயக்கங்கள், செயற்கையான fixtures, மற்றும் அதே frontier மாதிரியை அடிப்படையாகக் கொண்ட LLM judges. சுற்றுகள் உண்மையானவை மற்றும் தோல்வியுற்ற சோதனைகளும் இதில் சேர்க்கப்பட்டுள்ளன, இது பெரும்பாலான repo-க்கள் வெளியிடுவதை விட அதிகம். இது உங்கள் codebase-ல் என்ன நடக்கும் என்பதற்கான அளவீடு அல்ல, எனவே இரு-முனை ஒப்பீட்டை (two-arm comparison) நீங்களே செய்து பாருங்கள்.