Fable முறையை பயன்படுத்தி AI agent திறன்களை உருவாக்குவது

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-ல் ஒரு குறிப்பிட்ட version-ஐ pin செய்து வைத்திருக்க விரும்பினால், முதலில் 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 வாயில்: மாற்றம் ஒரு கோப்பை மட்டும் தொடும்போது, 10 வரிகளுக்குள் இயங்கும்போது, புதிய செயல்பாட்டைச் சேர்க்காதபோது, மற்றும் நீங்கள் எதை மாற்ற வேண்டும் என்று ஏற்கனவே தெரிந்திருக்கும்போது, எந்தச் சடங்கும் இன்றி நேரடியாகச் செயல்படுங்கள். இந்த உள்ளுணர்வை மட்டுமே அடிப்படையாகக் கொண்டு ஒரு தனித் திறன் உருவாக்கப்பட்டுள்ளது, அதுதான் Ponytail, இது ஒரு ஏஜென்ட்டைச் செயல்படும் மிகச்சிறிய மாற்றத்தை நோக்கித் தள்ளுகிறது, இதன் முக்கிய விதி எதையும் நிறுவத் தேவையில்லாமல் உங்கள் சொந்த அறிவுறுத்தல்களில் நகலெடுக்கும் அளவுக்குச் சிறியது. அடுத்து வருவது fit வாயில், இது பதில்கள் எங்கிருந்து கிடைக்கின்றன என்பதைப் பொறுத்து கோரிக்கையை வழிநடத்துகிறது: நீங்கள் திறக்கக்கூடிய ஆதாரங்கள், முதலில் ஆராய்ச்சி செய்ய வேண்டிய நுட்பம், அல்லது உங்கள் சொந்த அனுமானம் (இதை உண்மையாகக் காட்டாமல், குறைந்த நம்பிக்கை கொண்டதாகக் குறிப்பிட வேண்டும்). அந்த நடுப்பகுதி, ஏஜென்ட் இணையத்தை அணுக முடிந்தால் மட்டுமே செயல்படும்; பாதுகாக்கப்பட்ட VPS-ல் இதற்கு JSON search tool-ஆகச் செயல்படும் self-hosted SearXNG instance போன்ற ஒரு தேடல் வசதியை வழங்க வேண்டும்.

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

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

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

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

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

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

இந்த repository இதற்கான பதிலை நேரடியாக 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 மரபு அந்த கோப்பு எங்கு இருக்க வேண்டும், யார் அதைப் படிக்க வேண்டும் என்பதை விளக்குகிறது.

இரண்டு பகுதிகள் எளிதாக மாற்றத்தக்கவை (port). இந்த முறையின் உரை, மாடல் சார்ந்த குறியீடுகள் இல்லாத வரிசைப்படுத்தப்பட்ட prompt ஆகும். எனவே, அறிவுறுத்தல்களைப் பின்பற்றும் எந்தவொரு மாடலும் இதைப் பின்பற்ற முடியும். மாடலின் தரம் உயர உயர, இந்த முறையின் செயல்திறன் அதிகரிக்கும் என்பதே இந்த repository-ன் அடிப்படை வாதம். 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) மதிப்பிட நேரிடும்.

--bare-ஐப் பயன்படுத்தி control arm-ஐ இயக்கவும், இது 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 addition-ஆக ஏற்றும்:

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 system-prompt arm-லிருந்து மாறுபடும் என்பதை எதிர்பார்க்கலாம்.

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

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

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/-க்கு கீழ் உள்ள அமர்வு டிரான்ஸ்கிரிப்ட்களில் இருந்து output_tokens-ஐக் கூட்டி அதை மொத்தமாகக் கருத வேண்டாம்: அந்தந்த செய்தி வாரியான பயன்பாட்டுத் தொகுதிகள் ஸ்ட்ரீமிங்கின் போது எடுக்கப்பட்ட ஸ்னாப்ஷாட்கள், அவை குறைவாகக் கணக்கிடப்படுவதாகப் புகார்கள் உள்ளன. result வரியே நம்பகமான எண்ணாகும். இரண்டாவதாக, ஒரு பணிக்கு ஒரு இயக்கம் என்பது ஒரு தனிப்பட்ட அனுபவம் மட்டுமே, எனவே ஒரு இடைவெளியை நம்புவதற்கு முன், ஒவ்வொரு முறையையும் ஒரே பணியில் மூன்று அல்லது நான்கு முறை இயக்குங்கள், ஏனெனில் ஒரே ஏஜென்ட் ஒரே பணியைச் செய்தாலும் இரண்டு இயக்கங்கள் ஒன்றுக்கொன்று மாறுபடும். செலவு குறித்த நீண்டகாலப் பார்வைக்கு, Claude Code செலவைக் கண்காணிக்கும் கருவிகள் மற்றும் Claude Code டோக்கன்களை எவ்வாறு கணக்கிடுகிறது ஆகியவை, ஏன் cache வரிகள் மூல எண்ணிக்கையை விட முக்கியத்துவம் பெறுகின்றன என்பதை விளக்குகின்றன.

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

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

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

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

இந்த முறை எங்கு பலனளிக்காது என்பது குறித்தும் README தெளிவாக உள்ளது, அதுவே அதன் மிக பயனுள்ள பத்தியாகும். திறன்மிக்க model-களில் சாதாரண சிறிய பணிகளுக்கு இது எந்த முன்னேற்றத்தையும் தருவதில்லை. "இந்த முறையால் ஒரு model-ன் தகவல்களைப் புதுப்பிக்க முடியாது; அறிவு சார்ந்த ஆராய்ச்சிகளில் bare frontier model-களே வெற்றி பெறும்" என்று அது கூறுகிறது. மேலும், இதன் மதிப்பு "பொறிகள் (அதிகார முரண்பாடுகள், தவறான completion கோரிக்கைகள், பலவீனமான executors, கவனிக்கப்படாத runs) போன்ற இடங்களில் மட்டுமே உள்ளது, எல்லா இடங்களிலும் அல்ல" என்று அது சுட்டிக்காட்டுகிறது. நீங்கள் கவனித்துக்கொண்டிருக்கும்போது ஒரு வலுவான model-ல் சிறிய மாற்றங்களைச் செய்யும் agent பணியில் ஈடுபட்டால், எந்த மாற்றத்தையும் நீங்கள் காண முடியாது. ஆனால், ஒரு மலிவான model-ஐக் கவனிக்காமல் இயக்கும்போதுதான் வித்தியாசம் தெரியும், இதுவே Opus, Sonnet மற்றும் Haiku ஆகியவற்றுக்கு இடையேயான தேர்வு என்பதையும் அதே முடிவின் ஒரு பகுதியாக மாற்றுகிறது.

பேக்கேஜிங் எங்கே 'cargo cult'-ஆக மாறுகிறது

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

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

நான்கு திறன்கள் (skills) என்பது உள்ளடக்கத்திற்குத் தேவையானதை விட மேலோட்டமானது. fable-loop, fable-method-ன் பெரும்பகுதியை மீண்டும் கூறுகிறது, அதைச் சுற்றி orchestration மட்டுமே உள்ளது. subagents இல்லாத ஒரு harness-ல், இது மீண்டும் 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 மூலம் நீங்கள் சரிபார்க்கலாம். இதிலிருந்து தொடங்குங்கள், மேலே உள்ள கட்டமைப்பைக் கொண்டு அளவிடுங்கள், அதன் பிறகு மீதமுள்ள repo உங்கள் context budget-க்குத் தகுதியானதா என்பதை முடிவு செய்யுங்கள். ஒரு ஏஜென்ட்டிற்குச் செயல்பாட்டு முறையை விட, திட்டத்தின் சூழலை (project context) வழங்க விரும்பினால், ஏஜென்ட்கள் திருத்துவதற்கு முன் படிக்கும் ஒரு DESIGN.md கோப்பை உருவாக்குவதே அதற்கு இணையான சிறந்த வழியாகும்.

FAQ

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

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

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

ஆம், நீங்கள் அவற்றை எவ்வாறு ஏற்றுகிறீர்கள் என்பதைப் பொறுத்து செலவு மாறுபடும். திறன்களாக நிறுவப்படும்போது, பணியின் விவரணையும் (description) கோரிக்கையும் பொருந்தும்போது மட்டுமே அதன் உள்ளடக்கம் ஏற்றப்படும், எனவே தொடர்பில்லாத கோரிக்கைகளுக்குச் செலவு கிட்டத்தட்ட ஏதுமில்லை. 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) சோதனை ஓட்டமும் வெவ்வேறு வழிமுறைகளைப் படிக்கக்கூடும், இது ஒப்பீட்டைப் பயனற்றதாக்கும். உங்கள் முடிவுகளுடன் அந்த tag-ஐயும் பதிவு செய்யுங்கள்.

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

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