Claude Code அமர்வு வேகம் மற்றும் செலவைக் குறைப்பது எப்படி?

நீண்ட Claude Code அமர்வு மெதுவாவதையும் செலவு அதிகரிப்பதையும் தடுப்பது எப்படி

ஒவ்வொரு முறையும் முழு context-ம் மீண்டும் அனுப்பப்படுவதாலும், அந்த context தொடர்ந்து வளர்ந்து கொண்டே இருப்பதாலும் நீண்ட Claude Code அமர்வு மெதுவாகவும் செலவு மிகுந்ததாகவும் மாறுகிறது. இதற்கான தீர்வு, ஒரு குறிப்பிட்ட வரிசையில் பராமரிப்புப் பணிகளைச் செய்வதாகும். எவை context window-வை நிரப்புகின்றன என்பதைப் பார்க்க /context கட்டளையை இயக்கவும். ஒவ்வொரு கோரிக்கையிலும் நீங்கள் கட்டணம் செலுத்தும் தேவையற்ற தரவுகளை நீக்கவும். தொடர்பில்லாத பணிகளுக்கு இடையே /clear கட்டளையைப் பயன்படுத்தவும். ஒரே நீண்ட பணிக்குள் வெவ்வேறு கட்டளைகளுக்கு /compact பயன்படுத்தவும். தொடர்ச்சியான இடைவெளிகளில் வேலை செய்யுங்கள், ஏனெனில் prompt cache காலியாக இருந்தால், மலிவான read செயல்பாடு, நீங்கள் இதுவரை சொன்ன அனைத்தையும் மீண்டும் எழுதும் முழுமையான செயலாக மாறிவிடும்.

ஏஜென்ட் அமர்வின் போது கட்டணம் ஏன் வசூலிக்கப்படுகிறது என்பதற்கான விளக்கம் ஏஜென்ட் அமர்வின் பின்னணியில் உள்ள டோக்கன் மீட்டர் பகுதியில் உள்ளது.

எந்த மாற்றத்தையும் செய்வதற்கு முன் /context-ஐப் படிக்கவும்

சாளரத்தில் என்ன உள்ளது என்பதை ஊகிக்க வேண்டாம். Claude Code உங்களுக்குத் தெரிவிக்கும்.

/context [all] தற்போதைய context பயன்பாட்டை வண்ணக் கட்டங்களாகக் காட்டுகிறது, மேலும் context அதிகம் தேவைப்படும் கருவிகள் மற்றும் நினைவகப் பயன்பாட்டைக் குறைப்பதற்கான ஆலோசனைகளை வழங்குகிறது; all ஒவ்வொரு உருப்படியின் விரிவான தகவலை முழுத்திரை பயன்முறையில் விரிவுபடுத்தும். முடிவை ஐந்து பிரிவுகளாகப் பார்க்கவும்.

• System prompt. Claude Code-ன் சொந்தக் கட்டுப்பாட்டு வழிமுறைகள். அமர்வு முழுவதும் இது மாறாது.
• Tool definitions. முகவர் (agent) அழைக்கக்கூடிய ஒவ்வொரு கருவியின் schema, இதில் இணைக்கப்பட்டுள்ள அனைத்து MCP (Model Context Protocol) servers-ம் அடங்கும்.
• Memory files. CLAUDE.md மற்றும் தானியங்கி நினைவகம், அமர்வு தொடங்கும்போதே ஏற்றப்படும்.
• Files and tool results. நீங்கள் வாசித்த ஒவ்வொரு கோப்பு மற்றும் உங்கள் கட்டளைகள் வெளியிட்ட அனைத்துத் தகவல்களும்.
• Message history. உங்கள் உரையாடல்கள் மற்றும் அதன் பதில்கள்.

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

சாளரம் நிரம்பிவிட்டது என்பதை இரண்டு சரங்கள் (strings) உங்களுக்குத் தெரிவிக்கும்:

Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue.
Context is 94k tokens past the 200k-token compaction window — run /compact to reduce usage.

முதலாவது ஒரு கடினமான வரம்பு (hard limit), இந்த நிலையில் கோரிக்கை நிராகரிக்கப்படும்; இதற்கான API (application programming interface) பிழை Prompt is too long என்று காட்டும். இரண்டாவது ஒரு சுருக்கச் சாளரம் (compaction window), இது 1 மில்லியன் token கொண்ட மாதிரியின் உண்மையான context சாளரத்திற்குக் கீழே இருக்கலாம். இந்த வரம்பைத் தாண்டியும் கோரிக்கைகள் வெற்றிபெறும், எனவே இது ஒரு எச்சரிக்கை மட்டுமே, நிராகரிப்பு அல்ல.

கட்டணத் திட்டத்தில் (paid plan), /usage மற்ற பாதியைக் கூட்டுகிறது, இது நீண்ட context அல்லது cache misses போன்ற செயல்பாடுகளைக் குறிக்கும் மற்றும் சமீபத்திய பயன்பாட்டை அந்தந்த திறன்கள், துணை முகவர்கள் மற்றும் MCP servers-க்கு ஒதுக்கும். ஒதுக்கீடு ஏற்கனவே முடிந்துவிட்டது என்று அது தெரிவித்தால், நீங்கள் எந்த வரம்பு சாளரத்திற்காகக் காத்திருக்கிறீர்கள் என்பதைப் பொறுத்து, context-ஐக் குறைப்பது இப்போது உதவுமா அல்லது வேறு வழியில் பணியைத் தொடர வேண்டுமா என்பதை முடிவு செய்யவும்.

CLAUDE.md ஒரு நிரந்தர வரி, எனவே அதைச் சுருக்கமாக வைத்திருங்கள்

உங்கள் CLAUDE.md அமர்வு தொடங்கும்போதே context-ல் ஏற்றப்பட்டு அங்கேயே தங்கிவிடும். இதில் விரிவான deployment நடைமுறைகள் இருந்தால், ஒரு test file-ல் உள்ள பிழையைத் திருத்தும்போது கூட அந்த tokens பயன்பாட்டில் இருக்கும். Anthropic-ன் வழிகாட்டுதல் என்னவென்றால், அத்தியாவசியமானவற்றை மட்டும் வைத்துக்கொண்டு, கோப்பை 200 வரிகளுக்குள் வைத்திருக்க வேண்டும்.

நடைமுறைகளை skills-க்கு மாற்றவும். ஒரு skill அழைக்கப்படும்போது மட்டுமே ஏற்றப்படும், எனவே வாரத்திற்கு இருமுறை இயக்கும் ஒரு workflow மற்ற நாட்களில் எவ்வித token செலவையும் ஏற்படுத்தாது. Compaction-க்குப் பிறகு skills-க்கு எனத் தனி பட்ஜெட் உண்டு: உடல்கள் (bodies) மீண்டும் சேர்க்கப்படும், ஒரு skill-க்கு அதிகபட்சம் 5,000 tokens மற்றும் மொத்தம் 25,000 tokens என வரம்பு நிர்ணயிக்கப்படும், பழையவை முதலில் நீக்கப்படும். Truncation கோப்பின் தொடக்கப் பகுதியை அப்படியே வைத்திருக்கும், எனவே மிக முக்கியமான அறிவுறுத்தல்களை SKILL.md-ன் தொடக்கத்தில் வைக்கவும்.

எது compaction-க்குப் பிறகு எஞ்சியிருக்கிறது என்பது ஒரு அறிவுறுத்தல் எங்கு இருக்க வேண்டும் என்பதைத் தீர்மானிக்கிறது.

• System prompt மற்றும் output style மாறாது, ஏனெனில் அவை message history-ன் பகுதியல்ல.
• Project-root CLAUDE.md, unscoped விதிகள் மற்றும் auto memory ஆகியவை disk-லிருந்து மீண்டும் சேர்க்கப்படும்.
• paths: frontmatter கொண்ட ஒரு விதி, மீண்டும் ஒரு பொருத்தமான கோப்பு வாசிக்கப்படும் வரை இழக்கப்படும்.
• ஒரு subdirectory-ல் உள்ள nested CLAUDE.md, அந்த subdirectory-ல் உள்ள ஒரு கோப்பு மீண்டும் வாசிக்கப்படும் வரை இழக்கப்படும்.
• Hooks பாதிக்கப்படாது, ஏனெனில் ஒரு hook குறியீடாக (code) இயங்குகிறது மற்றும் அது ஒருபோதும் context-க்குள் நுழைவதில்லை.

எனவே, நீங்கள் சார்ந்திருக்கும் ஒரு விதி project-root CLAUDE.md-ல் இருக்க வேண்டும்: Claude Code பழைய tool outputs-ஐ முதலில் நீக்கிவிட்டுச் சுருக்கத்தைச் செய்யும், எனவே உரையாடலின் தொடக்கத்தில் உள்ள அறிவுறுத்தல்கள் இழக்கப்படலாம். /memory மூலம் நினைவகத்தைத் திருத்தவும். Claude Code அமர்வு தொடக்கத்தில் ஏற்றப்பட்ட நகலை வைத்திருக்கிறது, எனவே அமர்வின் நடுவில் செய்யப்படும் trim, prompt cache-ஐ வைத்திருக்கும் மற்றும் அடுத்த /clear, /compact அல்லது restart வரை அது நடைமுறைக்கு வராது. ஒரு விதி பின்பற்றப்படாமல் போவதற்கு context இழப்பு மட்டுமே ஒரு காரணம்; எனவே, அந்த விதி இன்னும் window-க்குள் தெளிவாகத் தெரிந்தும் புறக்கணிக்கப்பட்டால், அதை மீண்டும் எழுதுவதற்கு முன் பிற காரணங்களைச் சரிபார்க்கவும்.

பணிகளுக்கு இடையே /clear, ஒரு பணிக்குள் /compact

இவை இரண்டும் ஒன்றுக்கொன்று மாற்றாகத் தோன்றினாலும், இவற்றின் செலவு பெருமளவு வேறுபடுகிறது.

/clear [name] காலியான சூழலுடன் புதிய உரையாடலைத் தொடங்குகிறது. இது எந்தக் கோரிக்கையையும் அனுப்பாததால், இதற்குச் செலவு ஏதுமில்லை. /resume தேர்வியில் முந்தைய உரையாடலுக்குப் பெயரிட ஒரு பெயரை வழங்கவும்; /reset மற்றும் /new ஆகியவை இதற்கான மாற்றுப் பெயர்கள் (aliases). நீங்கள் தொடர்பில்லாத ஒரு பணிக்கு மாறும்போது இதைப் பயன்படுத்தவும், இல்லையெனில் பழைய பணி ஒவ்வொரு புதிய செய்தியிலும் மீண்டும் அனுப்பப்பட்டு, மீண்டும் கட்டணம் வசூலிக்கப்படும்.

/compact [instructions] ஒரே உரையாடலைத் தொடரும்போது சூழலை (context) விடுவிக்கிறது: இது இதுவரை நடந்த உரையாடலைச் சுருக்கி, அதற்குப் பதிலாக அந்தச் சுருக்கத்தை வைக்கிறது. தொடர்ச்சி தேவைப்படும் ஒரு நீண்ட பணிக்குள் இதைப் பயன்படுத்தவும்.

எப்போதும் /compact-க்கு ஒரு அறிவுறுத்தலை வழங்கவும். வெறும் /compact என்பது, உங்களுக்குத் தேவையான பணியின் எந்தப் பகுதி முக்கியமானது என்று தெரியாத ஒரு பொதுவான தூண்டுதலின் (prompt) அடிப்படையில் சுருக்கத்தை உருவாக்கும். அறிவுறுத்தலுடன் கூடிய சுருக்கம், உங்களுக்குத் தேவையான தகவலைத் தக்கவைக்கும்:

/compact focus on the auth bug fix
/compact keep only the plan and the diff

ஒரே காரணத்திற்காக நீங்கள் அடிக்கடி சுருக்கம் (compact) செய்கிறீர்கள் என்றால், உங்கள் திட்டத்தின் CLAUDE.md-ல் # Compact instructions தலைப்பின் கீழ் ஒரு நிரந்தர அறிவுறுத்தலைச் சேர்க்கவும். புதிய அமர்வில் /compact கட்டளையிட்டால் Not enough messages to compact. என்று அச்சிடும், அதாவது இன்னும் உரையாடல் வரலாறு தொடங்கவில்லை என்று பொருள்.

இங்கே இரண்டு வகையான செலவுகள் குழப்பத்தை ஏற்படுத்தலாம். சுருக்கக் கோரிக்கை உங்கள் முன்னொட்டைப் (prefix) பகிர்ந்துகொள்வதால், அது வரலாற்றை மீண்டும் செயலாக்குவதற்குப் பதிலாக ஏற்கனவே உள்ள cache-ஐப் படிக்கிறது, மேலும் அதன் பெரும்பாலான நேரம் சுருக்கத்தை உருவாக்குவதற்கே செலவாகிறது. ஒரு பெரிய சூழலைச் சுருக்குவது இன்னும் பெரிய கோரிக்கையாகவே இருக்கும், ஏனெனில் சுருக்கப்படும் உரையாடலே உள்ளீடாகச் செயல்படுகிறது. சுருக்கத்திற்குப் பிந்தைய உரையாடல் பகுதி மெதுவானது அல்ல: அது மிகக் குறுகிய தூண்டுதலுக்காக cache-ஐ மீண்டும் உருவாக்குகிறது.

இதைவிட மலிவான இரண்டு கட்டளைகள் உள்ளன. /rewind [description] குறியீட்டையும் உரையாடலையும் ஒரு checkpoint-க்குத் திருப்புகிறது; நீங்கள் முழுமையாகக் கைவிட விரும்பும் ஒரு பாதைக்கு, சுருக்குவதை விட இது சிறந்தது, ஏனெனில் இது ஏற்கனவே cache செய்யப்பட்ட முன்னொட்டு வரை உரையாடலை வெட்டிவிடுகிறது. /recap வரலாற்றை மாற்றுவதற்குப் பதிலாக, ஒரு சுருக்கத்தை கட்டளை வெளியீடாக (command output) இணைக்கிறது, எனவே cache செய்யப்பட்ட முன்னொட்டு அப்படியே இருக்கும்.

தானியங்கி சுருக்கம் மீண்டும் மீண்டும் நிகழும்போது இது அச்சிடப்படும்:

Autocompact is thrashing: the context refilled to the limit...

சுருக்கம் வெற்றிகரமாக முடிந்தது, ஆனால் ஒரு கோப்பு அல்லது கருவியின் வெளியீடு சாளரத்தை (window) பலமுறை நிரப்பியதால், Claude Code மீண்டும் முயற்சிப்பதை நிறுத்திவிட்டது. பெரிய கோப்பை வரி வரம்புகளாகப் (line ranges) படிப்பதன் மூலமோ, பெரிய வெளியீட்டைத் தவிர்க்கும் கவனத்துடன் /compact-ஐ இயக்குவதன் மூலமோ, அந்தப் பணியை ஒரு subagent-க்கு மாற்றுவதன் மூலமோ அல்லது முந்தைய உரையாடல் முடிந்துவிட்டால் /clear-ஐப் பயன்படுத்துவதன் மூலமோ இதைச் சரிசெய்யலாம்.

MCP servers நிலையான overhead-ஐக் கொண்டுள்ளன

நீங்கள் இணைக்கும் ஒவ்வொரு MCP server-ம் முழு session-ன் ஒவ்வொரு கோரிக்கைக்கும் (request) கூடுதல் சுமையைச் சேர்க்கிறது. நீங்கள் அந்த server-ஐப் பயன்படுத்தினாலும் சரி, பயன்படுத்தாவிட்டாலும் சரி, அதற்கான செலவை நீங்கள் ஏற்கிறீர்கள்.

Claude Code இந்தச் சுமையைக் குறைக்கிறது. MCP tool வரையறைகள் இயல்பாகவே தள்ளிவைக்கப்படுகின்றன (deferred). எனவே, Claude ஒரு குறிப்பிட்ட tool-ஐப் பயன்படுத்தும் வரை, அதன் பெயர் மட்டுமே context-க்குள் நுழையும். உங்கள் servers உண்மையில் எவ்வளவு செலவை ஏற்படுத்துகின்றன என்பதைப் பார்க்க /context-ஐ இயக்கவும். இன்று நீங்கள் பயன்படுத்தப்போகாத ஒன்றை நீக்க /mcp disable <name>-ஐப் பயன்படுத்தவும். நீங்கள் உங்கள் சொந்த MCP servers-ஐ ஒரு VPS-ல் இயக்கினால், ஒரே server எத்தனை tool-களை வெளிப்படுத்த வேண்டும் என்பதை இதே கணக்கீடு தீர்மானிக்கிறது.

இதை ஒரு session-ன் தொடக்கத்திலேயே செய்யவும். வரையறைகள் தள்ளிவைக்கப்பட்டிருக்கும்போது, ஒரு server-ஐ இணைப்பது அல்லது துண்டிப்பது உரையாடலில் புதிய பதிவை மட்டுமே சேர்க்கும், மேலும் cache அப்படியே இருக்கும். tool search முடக்கப்பட்டிருப்பதாலோ அல்லது ஒரு server தள்ளிவைப்பிலிருந்து விலக்கு அளிக்கப்பட்டிருப்பதாலோ வரையறைகள் prefix-ல் ஏற்றப்படும் இடங்களில், இதே மாற்றம் அடுத்த கோரிக்கையின்போது அனைத்தையும் மீண்டும் படிக்கச் செய்யும்.

Context-க்குள் செல்வதற்கு முன் verbose tool output-ஐ வடிகட்டுதல்

ஒரு tool-ன் முடிவு input-ஆக மாறுகிறது, மேலும் ஒவ்வொரு அடுத்தடுத்த turn-லும் அந்த input மீண்டும் அனுப்பப்படுகிறது. 20,000 tokens அளவு output-ஐத் தரும் ஒரு test run என்பது ஒருமுறை மட்டும் நடக்கும் செலவு அல்ல: அது context window-வை விட்டு வெளியேறும் வரை ஒவ்வொரு turn-லும் அதற்கான கட்டணத்தை நீங்கள் செலுத்த வேண்டியிருக்கும்.

மூலத்திலேயே வடிகட்டுங்கள். Claude பார்ப்பதற்கு முன்பே test run-ன் முடிவுகளை அதன் தோல்விகள் (failures) மட்டும் இருக்குமாறு குறைக்கும் ஒரு hook, அந்தப் பெரிய output-ஐச் சில நூறு tokens-ஆக மாற்றுகிறது; இது தற்போதைய turn-லும், அதை மீண்டும் அனுப்பும் ஒவ்வொரு முறையும் பொருந்தும்:

npm test 2>&1 | grep -E "FAIL|Error:" | head -40

Hooks தாமாகவே context-க்குள் நுழைவதில்லை, ஏனெனில் அவை code-ஆக இயங்குகின்றன. ஒரு திரையைத் தாண்டிச் செல்லும் output-ஐக் கொண்ட எந்தவொரு tool-க்கும் இதைச் செய்யுங்கள். 3,000 வரிகள் கொண்ட file-க்கும் இதே தர்க்கம் பொருந்தும்: உங்களுக்குத் தேவையான வரிகளை மட்டும் கேளுங்கள், ஏனெனில் ஒருமுறை வந்த பிறகு முழு file-ம் window-விலேயே தங்கிவிடும்.

Agent எதை வாசிக்க வேண்டும் என்பதை வரையறுத்து, அதிகப்படியான வேலைகளைப் பகிர்தல்

ஒரு கோப்பின் பெயரையும் அதன் சிக்கலையும் குறிப்பிடும் prompt, அந்தக் கோப்பை மட்டுமே வாசிக்கும். திட்டத்தைச் சீரமைக்கச் சொல்லும் பொதுவான கோரிக்கை, agent எதை முக்கியம் என்று கருதுகிறதோ அதை வாசிக்கும்; அவ்வாறு வாசிக்கப்படும் ஒவ்வொரு தகவலும் window-ல் தங்கிவிடும்.

அதிகப்படியான வேலைகளை ஒரு subagent-க்கு ஒதுக்குங்கள். Test runs மற்றும் log processing ஆகிய இரண்டுமே அதிக context-ஐப் பயன்படுத்தும்; ஒரு subagent அந்த வெளியீட்டைத் தனது சொந்த window-ல் வைத்துக்கொண்டு, சுருக்கத்தை மட்டுமே திருப்பி அனுப்பும். இதில் உள்ள சமரசம் என்னவென்றால், subagent தனது சொந்த cache-ஐ உருவாக்கும், முதல் அழைப்பில் எந்த cache hits-ம் இருக்காது, மேலும் subscription-ல் இருந்தாலும் ஐந்து நிமிட cache ஆயுட்காலத்தையே பயன்படுத்தும். வேலைகளைப் பகிர்ந்தளிப்பது உங்கள் முதன்மை context-ஐப் பாதுகாப்பாக வைத்திருக்கும். இது எப்போதும் மொத்த token பயன்பாட்டைக் குறைப்பதில்லை.

Cache clock: இடைவிடாத வேலை முறைகள்

Prompt caching-ஆல் மட்டுமே resend மலிவானதாகிறது: prefix-ஐ வாசிக்க அடிப்படை input கட்டணத்தில் 0.1x, அதை எழுத 1.25x, அல்லது ஒரு மணிநேர காலாவதிக்குள் எழுத 2x கட்டணம் வசூலிக்கப்படுகிறது. ஒவ்வொரு பயன்பாடும் அந்த entry-ன் காலாவதி நேரத்தை மீண்டும் புதுப்பிக்கும், எனவே clock கடைசி பயன்பாட்டிலிருந்து கணக்கிடப்படும். இந்த multipliers கட்டணத்தின் விகிதத்தை மட்டுமே காட்டும், அதன் மொத்த அளவை அல்ல. எனவே, முழு context window-ன் டாலர் மதிப்பைக் கணக்கிட ஒரு மில்லியன் tokens-ன் உண்மையான விலை என்பதைப் பார்க்கவும்.

எந்த காலாவதி காலம் உங்களுக்குக் கிடைக்கும் என்பது நீங்கள் எவ்வாறு authenticate செய்கிறீர்கள் என்பதைப் பொறுத்தது. "உங்கள் cache ஐந்து நிமிடங்களில் காலாவதியாகும்" என்ற பொதுவான கூற்று இங்குதான் தவறாகிறது.

• Claude subscription-ல், Claude Code தானாகவே ஒரு மணிநேர காலாவதி காலத்தைப் பெறுகிறது.
• உங்கள் plan-ன் வரம்பைத் தாண்டி usage credits-ஐப் பயன்படுத்தும்போது, அந்த பயன்பாட்டிற்கு நீங்கள் கட்டணம் செலுத்த வேண்டியிருப்பதால், அது ஐந்து நிமிடங்களாகக் குறைகிறது.
• API key அல்லது cloud provider-ஐப் பயன்படுத்தும்போது, அது ஐந்து நிமிடங்களாகவே இருக்கும். ENABLE_PROMPT_CACHING_1H=1 ஒரு மணிநேர காலாவதி காலத்தைத் தேர்வு செய்ய அனுமதிக்கிறது, FORCE_PROMPT_CACHING_5M=1 அதை மீண்டும் ஐந்து நிமிடங்களாகக் குறைக்கிறது.

எந்த நிலையிலும் வேலை செய்யும் முறை ஒன்றுதான்: இடைவிடாமல் தொடர்ந்து வேலை செய்யுங்கள். ஏனெனில், காலாவதி காலத்திற்கு மேல் நீங்கள் செயலற்று இருந்தால், அடுத்த முறை கோரிக்கை அனுப்பும்போது முழு prefix-ம் மீண்டும் எழுதப்படும். tmux-ல் இயங்கும் detached Claude Code session செயலற்ற நிலையில் இருக்கும்போது எந்தக் கட்டணமும் வசூலிக்காது, ஆனால் அந்த இடைவெளியால் cache-ன் வெப்பம் (warm cache) இழக்கப்படும்.

சில செயல்கள் நீங்கள் வேலை செய்துகொண்டிருக்கும்போதே cache-ஐ நீக்கிவிடும்: model-களை மாற்றுவது, effort level-ஐ மாற்றுவது, fast mode-ஐ இயக்குவது, MCP server-ஐ இணைப்பது அல்லது துண்டிப்பது, plugin-ஐ இயக்குவது அல்லது முடக்குவது, ஒரு கருவியை முழுமையாக மறுப்பது, compacting செய்வது மற்றும் Claude Code-ஐ upgrade செய்வது போன்றவை இதில் அடங்கும். /model பெரும்பாலும் ஆச்சரியத்தை ஏற்படுத்தும், ஏனெனில் ஒவ்வொரு model-க்கும் தனித்தனி cache உண்டு. எனவே, உள்ளடக்கம் ஒன்றாக இருந்தாலும், அடுத்த கோரிக்கையின்போது cache hits இருக்காது. அந்த மறுவாசிப்பு (re-read) புதிய model-ன் கட்டணத்தில் வசூலிக்கப்படும். உதாரணமாக, session-ன் இடையில் Fable-க்கு மாறினால், உங்கள் முழு வரலாறும் Fable 5-ன் நிர்ணயிக்கப்பட்ட input கட்டணத்தில் வசூலிக்கப்படும்.

கோப்புகளைத் திருத்துவது, CLAUDE.md-ஐத் திருத்துவது, skills மற்றும் commands-ஐப் பயன்படுத்துவது, /recap-ஐ இயக்குவது, rewinding செய்வது மற்றும் subagent-ஐ உருவாக்குவது போன்றவை cache-ஐத் தக்கவைக்கும். இது ஒரு machine மற்றும் ஒரு directory-க்கு மட்டுமே உட்பட்டது, எனவே வெவ்வேறு directory-களில் உள்ள இரண்டு sessions-க்கு cache பகிரப்படாது. இந்த வரம்பு உங்கள் கணக்கை விட CLI-ஐப் பின்பற்றுவதால், இது Claude desktop app-க்கு மாறாது. Linux-ல் Claude desktop app என்பது CLI-க்கு இணையாக நிறுவப்படும் ஒரு தனிப்பட்ட beta பதிப்பாகும்.

Caching வேலை செய்கிறதா என்று பார்க்க, current_usage-ஐ வாசிக்கவும். cache_creation_input_tokens cache write கட்டணத்தில் எழுதப்பட்டது; cache_read_input_tokens சாதாரண input கட்டணத்தில் பத்தில் ஒரு பங்கு விலையில் வழங்கப்பட்டது. அதிக read-to-creation விகிதம் ஆரோக்கியமானது. ஒவ்வொரு முறையும் creation கட்டணம் அதிகமாக இருந்தால், உங்கள் prefix-ல் ஏதோ ஒன்று தொடர்ந்து மாறிக்கொண்டிருக்கிறது என்று அர்த்தம்.

பெரிய context window இந்தச் சிக்கலைத் தீர்க்குமா?

பகுதியளவு தீர்க்கும். தற்போதுள்ள பல மாதிரிகள் 1 மில்லியன் token context window-வை ஆதரிக்கின்றன, மேலும் இந்த அதிகபட்ச எல்லையிலும் compaction அதே முறையில் செயல்படுகிறது. ஆனால், பொருளாதார ரீதியாக எந்த மாற்றமும் இல்லை, ஏனெனில் ஒவ்வொரு முறையும் முழு prompt-ம் மீண்டும் அனுப்பப்பட்டு, அதற்கான கட்டணம் வசூலிக்கப்படுகிறது. ஒரு பெரிய window, நீங்கள் எப்போது செயல்பட வேண்டும் என்பதை மட்டுமே தீர்மானிக்கிறது; ஆனால், செலவை நிர்ணயிப்பது உங்கள் தரவு மேலாண்மை (hygiene) தான். வரம்பை விட, கட்டணமே சிக்கலாக இருந்தால், உங்கள் பணிக்கு எந்த Claude திட்டம் பொருத்தமானது என்பதைப் பொறுத்து, நீங்கள் டாலர்களில் செலவு செய்கிறீர்களா அல்லது திட்டத்தின் ஒதுக்கீட்டைப் பயன்படுத்துகிறீர்களா என்பது முடிவாகும்.

API-ல் context editing மற்றும் compaction ஆகிய இரண்டும் வெவ்வேறு செயல்பாடுகள்

நீங்கள் Messages API-ல் சொந்தமாக agent உருவாக்குகிறீர்கள் என்றால், அங்கு slash commands கிடையாது; நீங்களே இதைச் செயல்படுத்த வேண்டும். இதற்கான பணிகளைத் தொடக்கத்திலிருந்தே திட்டமிடுங்கள், ஏனெனில் சிறிய signup credit-க்கு மேல் API-ல் இலவச அடுக்கு (free tier) இல்லை. எனவே, சுருக்கப்படாத ஒவ்வொரு உரையாடல் சுற்றும் முழுமையாகக் கட்டணம் வசூலிக்கப்படும். எந்த provider-ஐத் தேர்ந்தெடுக்கிறீர்கள் என்பது, சுருக்குவதற்கு முன்பே கணக்கீட்டைத் தீர்மானிக்கிறது. எனவே, இன்னும் தேர்வு செய்யவில்லை என்றால், ஒவ்வொரு token-க்கும் உள்ள விலையை மட்டும் பார்க்காமல், இரண்டு API-களிலும் ஒரே பணிச்சுமைக்கு எவ்வளவு செலவாகும் என்று கணக்கிடுங்கள். இதைச் செய்ய server-side-ல் இரண்டு வசதிகள் உள்ளன, ஆனால் அவை ஒன்றல்ல.

Context editing என்பது உரையாடல் வரலாறு வளரும்போது குறிப்பிட்ட உள்ளடக்கத்தை மட்டும் தேர்ந்தெடுத்து நீக்குகிறது. நீக்கப்பட்ட ஒவ்வொரு இடத்திலும் placeholder text-ஐ வைப்பதன் மூலம், ஏதோ ஒன்று நீக்கப்பட்டதை Claude அறிந்துகொள்ளும். இது ஒரு beta வசதி: anthropic-beta: context-management-2025-06-27-ஐ அனுப்பி, context_management.edits-ன் கீழ் உத்திகளை (strategies) அமைக்கவும். clear_tool_uses_20250919 tool முடிவுகளை நீக்குகிறது, clear_thinking_20251015 thinking blocks-ஐ நிர்வகிக்கிறது. இதன் trigger இயல்பாக (default) 100,000 input tokens-ஆகவும், keep கடைசி 3 tool பயன்பாடுகளாகவும், clear_tool_inputs என்பது false-ஆகவும் உள்ளது. இதனால் உள்ளீடுகள் அப்படியே இருக்கும், முடிவுகள் மட்டுமே நீக்கப்படும்.

Compaction என்பது ஒரு சுருக்கத்தை உருவாக்கி, முழு உரையாடல் வரலாற்றையும் அதற்குப் பதிலாக மாற்றுகிறது. இதுவும் ஒரு beta வசதி: anthropic-beta: compact-2026-01-12-ஐ அனுப்பி, compact_20260112 edit type-ஐப் பயன்படுத்தவும். இதன் trigger இயல்பாக {"type": "input_tokens", "value": 150000}-ல் அமையும், இதன் மதிப்பு குறைந்தபட்சம் 50,000 ஆக இருக்க வேண்டும்.

Compaction-ல் agents-ஐச் செயலிழக்கச் செய்யும் ஒரு handoff விதி உள்ளது. பதில் ஒரு compaction content block-உடன் தொடங்கும், அதில் சுருக்கம் இருக்கும்; அதைத் தொடர்ந்து சாதாரண text block இருக்கும். பிற்காலக் கோரிக்கைகளில் (requests) அந்த block-ஐ நீங்கள் மீண்டும் அனுப்ப வேண்டும்; அப்போது API அதற்கு முன்னால் உள்ள அனைத்து content block-களையும் நீக்கிவிடும். நடைமுறையில்: text-ஐ மட்டும் அனுப்பாமல், response.content முழுவதையும் இணைக்கவும்.

நீண்டகால உரையாடல்களில் context-ஐ நிர்வகிக்க server-side compaction-ஐ முதன்மை உத்தியாகவும், எதை நீக்க வேண்டும் என்பதில் நுணுக்கமான கட்டுப்பாடு தேவைப்படும்போது context editing-ஐப் பயன்படுத்தவும் என்று Anthropic ஆவணங்கள் கூறுகின்றன. முதலில் model support-ஐச் சரிபார்க்கவும். தற்போதைய Opus, Sonnet மற்றும் Fable மாதிரிகள் compaction-ஐ ஆதரிக்கின்றன; claude-haiku-4-5 ஆதரிக்காது. நேரடிப் பட்டியலை compaction பக்கத்தில் காணலாம். இந்த இரண்டு beta வசதிகளும் Claude Code-ன் சொந்த /compact-ஐ இயக்குவதில்லை; அது client அனுப்பும் ஒருமுறை மட்டுமே பயன்படுத்தப்படும் சுருக்கக் கோரிக்கை (one-off summarization request) என்று அதன் ஆவணங்கள் குறிப்பிடுகின்றன.

FAQ

Claude Code session நீண்ட நேரம் இயங்கும்போது ஏன் மெதுவாகவும் அதிக செலவு வைப்பதாகவும் மாறுகிறது?

ஒவ்வொரு முறையும் உரையாடல் முழுமையாக மீண்டும் அனுப்பப்படுவதே இதற்குக் காரணம். நாள் முழுவதும் திறந்திருக்கும் ஒரு session-ல், ஒரு வரி கேள்வியைக் கேட்டாலும், அந்த நாள் முழுவதுமான உரையாடலும் அதனுடன் சேர்ந்து அனுப்பப்படும். Prompt caching வசதியைப் பயன்படுத்தும்போது, cache warm ஆக இருக்கும் வரை, வாசிப்புக்கு (read) அடிப்படை input கட்டணத்தில் 0.1x மட்டுமே செலவாகும். ஒருமுறை cache miss ஏற்பட்டால், அதே prefix மீண்டும் எழுதப்படும்போது 1.25x கட்டணம் வசூலிக்கப்படும். Window-ல் என்னென்ன தரவுகள் நிரம்பியுள்ளன என்பதைப் பார்க்க /context கட்டளையை இயக்கவும். இதற்கான கட்டண முறை குறித்து அறிய Claude Code session கட்டண விவரங்கள் என்பதைப் படிக்கவும்.

Claude Code-ல் /clear மற்றும் /compact ஆகியவற்றுக்கு என்ன வித்தியாசம்?

/clear என்பது காலியான context-உடன் புதிய உரையாடலைத் தொடங்குகிறது. இது எந்த கோரிக்கையையும் அனுப்பாததால் கட்டணம் ஏதும் இல்லை; தொடர்பில்லாத பணிகளுக்கு இடையில் மாற இதுவே சரியான தேர்வு. /compact என்பது அதே உரையாடலைத் தக்கவைத்துக்கொண்டு, வரலாற்றை ஒரு சுருக்கத்தால் மாற்றுகிறது; எனவே, நீண்ட ஒரே பணியைச் செய்யும்போது இதுவே சிறந்தது. /compact keep only the plan and the diff-ல் குறிப்பிடுவது போல, ஒரு குறிப்பிட்ட இலக்கை வழங்கவும், ஏனெனில் அந்த அறிவுறுத்தலே எவை நீக்கப்பட வேண்டும் என்பதைத் தீர்மானிக்கிறது.

எனது Claude Code context window-ஐ எவை ஆக்கிரமித்துள்ளன என்பதை நான் எப்படிப் பார்ப்பது?

/context கட்டளையை இயக்கவும், அல்லது ஒவ்வொரு உருப்படியின் முழுமையான விவரங்களுக்கு /context all கட்டளையை இயக்கவும். இது system prompt, tool definitions, MCP servers, memory files மற்றும் வரலாற்றை வண்ணமயமான கட்டங்களாகக் காட்டும். மேலும், அதிக context-ஐப் பயன்படுத்தும் கருவிகள் மற்றும் memory bloat குறித்த பரிந்துரைகளையும் வழங்கும். கட்டணத் திட்டத்தில் (paid plan) இருந்தால், /usage கட்டளை மூலம் சமீபத்திய பயன்பாட்டை தனிப்பட்ட skills, subagents மற்றும் MCP servers வாரியாகப் பிரிக்க முடியும்.

நான் compacting செய்வதற்குப் பதிலாக 1 million token context window-ஐப் பயன்படுத்தலாமா?

பெரிய window-ஐப் பயன்படுத்துவது சிக்கலைத் தீர்க்காது, தள்ளிப்போடும் மட்டுமே. Opus 4.8 மற்றும் Sonnet 5 உள்ளிட்ட பல தற்போதைய மாதிரிகள் 1 million token context window-ஐ ஆதரிக்கின்றன, ஆனால் compaction அங்கும் அதே விதமாகவே செயல்படும். ஒவ்வொரு முறையும் முழு prompt-ம் மீண்டும் அனுப்பப்பட்டு அதற்கான கட்டணம் வசூலிக்கப்படும். எனவே, 400,000-token உரையாடல் என்பது window-க்குள் அடங்கினாலும் இல்லாவிட்டாலும் அதிக செலவு வைக்கக்கூடியதே.

Claude API-ல் context editing மற்றும் compaction ஆகியவற்றுக்கு என்ன வித்தியாசம்?

Context editing என்பது பழைய உள்ளடக்கங்களை, குறிப்பாக tool-ன் முடிவுகளைத் தேர்ந்தெடுத்து நீக்குகிறது. நீக்கப்பட்ட இடத்தில் ஒரு placeholder உரையை வைப்பதன் மூலம், அது நீக்கப்பட்டதை Claude அறிந்துகொள்கிறது. Compaction என்பது முழு வரலாற்றையும் சுருக்கி, அந்தச் சுருக்கத்தை வரலாற்றிற்குப் பதிலாக மாற்றுகிறது. Anthropic-ன் ஆவணங்கள், நீண்ட கால உரையாடல்களுக்கு compaction-ஐ முதன்மை உத்தியாகவும், context editing-ஐ நுணுக்கமான மாற்றங்களுக்கான விருப்பமாகவும் குறிப்பிடுகின்றன. இவை இரண்டுமே beta நிலையில் உள்ளவை மற்றும் தனித்தனி headers-ஐக் கொண்டவை. இவை இரண்டும் Claude Code-ன் /compact-லிருந்து மாறுபட்டவை.