Hermes reasoning effort: session, global और per-model सेटिंग्स

Hermes को हमेशा सबसे ऊँचे reasoning level पर रखना हर task को बेहतर नहीं बनाता। Screen पर thinking दिखना भी यह साबित नहीं करता कि request ने वही effort इस्तेमाल किया जो आपने चुना था। बेहतर तरीका है कि रोज़मर्रा के लिए एक व्यावहारिक global default रखें, कठिन task पर session level बढ़ाएँ, बार-बार उपयोग होने वाले model के लिए evidence मिलने के बाद per-model default बनाएँ, और result को एक जाँचे जा सकने वाले task तथा provider के request records से verify करें।

व्यावहारिक default: medium से शुरू करें

Hermes none, minimal, low, medium, high, xhigh, max और ultra स्वीकार करता है। Value unset हो तो medium लागू होता है। हर model या route पूरी ladder support नहीं करता; level clamp, translate, ignore या reject हो सकता है। इसलिए label को performance guarantee न मानें। Current behavior के लिए Hermes configuration documentation और अपने provider का request record देखें।

Task	शुरुआत का level	कब बदलें
Formatting, field extraction या deterministic rewrite	low; support confirm होने पर ही minimal या none	Field छूटे या format टूटे तो medium
छोटा code change, routine question या साफ scope वाला debugging	medium	लगातार सही result मिले तो low; constraints छूटें तो high
कई constraints वाला review, cross-file diagnosis या trade-off analysis	high	Quality gain दोहराए और delay स्वीकार्य हो तभी xhigh या max
बहुत कठिन planning या लंबी reasoning chain	पहले high और xhigh compare करें	Controlled test में स्पष्ट लाभ हो तभी max या ultra रखें

ultra Hermes की internal rung है। Route इसे उस सबसे ऊँचे value में map करता है जिसे वह वास्तव में भेज सकता है। सिर्फ नाम देखकर इसे global default बनाना ठीक नहीं है।

Thinking दिखाना और effort बदलना अलग controls हैं

ये commands current session का reasoning effort बदलते हैं:

/reasoning high
/reasoning none

ये commands केवल interface में thinking दिखाने या छिपाने का काम करते हैं:

/reasoning show
/reasoning hide

Thinking hidden होने पर request फिर भी high पर चल सकती है। Thinking visible होने से high effort साबित नहीं होता। बिना argument के /reasoning चलाएँ और current effort तथा display state दोनों अलग-अलग देखें।

Session, global और per-model scope कब उपयोग करें

Session scope: सामने मौजूद कठिन task के लिए

Active session में चलाएँ:

/reasoning high

Default रूप से यह बदलाव केवल उसी session में रहता है। किसी एक कठिन debugging या architecture task को अधिक effort देने का यह सबसे सुरक्षित तरीका है, क्योंकि future conversations नहीं बदलतीं।

Current session में reasoning off माँगने के लिए:

/reasoning none

यह तभी वास्तव में off होगा जब model और route इसकी अनुमति दें। Provider reasoning को mandatory कर सकता है, value को दूसरी तरह map कर सकता है या reject कर सकता है, इसलिए actual request record देखना जरूरी है।

Global scope: रोज़मर्रा का default

नई sessions के लिए value save करने हेतु --global जोड़ें:

/reasoning medium --global

Hermes इसे agent.reasoning_effort के रूप में persist करता है। Mixed workload में medium maximum से सुरक्षित baseline है; केवल कठिन tasks के लिए session override बढ़ाएँ।

Terminal से saved configuration पढ़ें:

hermes config path
hermes config get agent.reasoning_effort
hermes config check

config get का सफल output यह दिखाता है कि Hermes ने configuration value resolve की। इससे अकेले यह साबित नहीं होता कि provider ने वही value स्वीकार और लागू की।

Per-model scope: बार-बार switch होने वाले models के लिए

यदि आप fast model और deeper reasoning model के बीच नियमित switch करते हैं, तो config.yaml edit करें:

agent:
  reasoning_effort: "medium"
  reasoning_overrides:
    "custom/example-fast-model": "low"
    "custom/example-deep-model": "high"

Matching per-model override global agent.reasoning_effort से ऊपर priority लेता है। Hermes में configured exact model ID उपयोग करना बेहतर है। File edit करने के बाद नया session शुरू करें, target model चुनें और /reasoning फिर चलाएँ।

Override map देखने के लिए:

hermes config get agent.reasoning_overrides --json

Model ID में अक्सर dots और slashes होते हैं। Direct YAML editing आसान है; hermes config set से dotted key बनाते समय CLI command reference में literal dot escaping rules follow करें।

Priority: global value बदलने पर भी result क्यों नहीं बदलता

Selected model के लिए effective order को ऐसे समझें:

1. Current session का temporary /reasoning choice;
2. Matching agent.reasoning_overrides entry;
3. Global agent.reasoning_effort;
4. Model या provider का default।

Global value low होने के बाद भी /reasoning high दिखाए, तो पहले live session override या per-model entry जाँचें। /model switch के बाद भी level दोबारा देखें, क्योंकि नया model दूसरी override entry से match कर सकता है।

एक ही जाँचे जा सकने वाला task उपयोग करें

एक level को trivial rewrite और दूसरे को कठिन bug पर test न करें। इससे task difference मापा जाएगा, effort नहीं। नीचे का छोटा task हाथ से verify किया जा सकता है और tools की जरूरत नहीं है:

यह function overlapping या touching closed integer ranges को merge करे, लेकिन पहले से covered range को छोटा न करे।
एक minimal counterexample खोजें, expected और actual output दें, सबसे छोटा code fix बताएँ और तीन regression tests जोड़ें।
Tools उपयोग न करें। केवल JSON लौटाएँ, जिसकी keys counterexample, expected, actual, fix और tests हों।

def merge_ranges(ranges):
    ranges = sorted(ranges)
    merged = []
    for start, end in ranges:
        if not merged or start > merged[-1][1] + 1:
            merged.append([start, end])
        else:
            merged[-1][1] = end
    return merged

मुख्य failure तब आता है जब बाद वाला range पहले से merged range के अंदर पूरा contained हो: छोटे end को assign करने से coverage घट जाती है। Style के बजाय पाँच objective checks पर score दें:

1. Valid JSON, कोई extra prose नहीं;
2. Contained-range counterexample जो bug trigger करे;
3. सही expected और actual;
4. ऐसा minimal fix जो बड़ा end preserve करे;
5. Contained, touching और disjoint ranges के tests।

Manual comparison: lasting default चुनने का तेज तरीका

हर candidate level के लिए fresh session उपयोग करें। Model ID, provider, working directory, context, tool settings, task text और output format समान रखें। Screening के लिए एक run काफी है; यदि decision frequent default बदलेगा, तो finalist levels को कम से कम तीन clean runs दें ताकि random variation को stable gain न समझा जाए।

इन fields को record करें:

Field	कैसे record करें
Effort	Task से पहले /reasoning चलाकर reported value save करें
Quality	ऊपर के 0–5 checklist से score करें
Latency	Submit से final answer तक wall-clock time
Model और provider	Hermes status और provider request record दोनों से confirm करें
Actual usage	Provider/API request record या billing detail उपयोग करें
Anomalies	Timeout, retry, fallback, error या model switch mark करें

Retry या fallback वाले run को clean runs के average में न मिलाएँ। उससे model, call count, latency और Token usage एक साथ बदल सकते हैं, इसलिए वह reasoning effort का प्रभाव isolate नहीं करता।

--usage-file से local Hermes report save करें

Machine-readable comparison के लिए global level अस्थायी रूप से बदलकर वही one-shot task चलाएँ:

hermes config set agent.reasoning_effort low
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-low-usage.json > ./hermes-low-output.txt

hermes config set agent.reasoning_effort medium
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-medium-usage.json > ./hermes-medium-output.txt

hermes config set agent.reasoning_effort high
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-high-usage.json > ./hermes-high-output.txt

Real comparison में shortened line की जगह हर run को वही complete task दें। पहले confirm करें कि selected model पर per-model override global value को shadow नहीं कर रही। Test के बाद original setting restore करें। यदि पहले unset थी:

hermes config unset agent.reasoning_effort

यदि explicit value थी, तो recorded original value वापस set करें।

Hermes JSON report में input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, reasoning_tokens, total_tokens, api_calls, model, provider और estimated_cost_usd हो सकते हैं। Top-level counters main agent loop के लिए हैं। Title generation, vision या compression जैसी auxiliary calls auxiliary में अलग आती हैं; local combined total total_including_auxiliary में होता है।

तीन boundaries साफ रखें:

• estimated_cost_usd local estimate है, provider invoice नहीं;
• Provider कोई Token category न लौटाए तो missing field zero usage का प्रमाण नहीं है;
• Retry या fallback होने पर provider request list से actual calls और models confirm करें।

चार तरह के evidence को अलग-अलग जाँचें

एक उपयोगी verification चार अलग बातें record करती है:

1. Configuration readback: hermes config get और config.yaml में intended value है। इससे केवल यह साबित होता है कि Hermes ने क्या store और resolve किया, provider ने क्या accept किया नहीं।
2. असल में भेजा या mapped effort: target model चुनने के बाद /reasoning चलाएँ। जहाँ status sends ... on this route दिखाता है या route outbound request trace देता है, वहाँ API को भेजे गए value को expected mapping से मिलाएँ। Thinking visibility अलग display setting है।
3. Provider-side receipt, acceptance या execution: server-side request record, echoed value या explicit acceptance/execution confirmation को तभी evidence मानें जब route या Provider वास्तव में उसे expose करता हो। Success signal यह है कि server-side parameter sent/mapped value से match करे और rejection, retry, fallback या further downgrade record न हो। Payload trace receipt साबित करता है, execution नहीं; Provider जो field expose नहीं करता, उसे अनिवार्य न मानें।
4. Usage और outcome: actual model, output quality, latency, Token categories, API calls और billed या estimated cost record करें। ये routing और real usage verify कर सकते हैं, accepted effort नहीं; reasoning Token की संख्या से tier reverse-infer नहीं किया जा सकता।

ये evidence types एक-दूसरे की जगह नहीं लेते। यदि Provider log केवल model, Token, call count या spend दिखाता है और effort expose नहीं करता, तो सही conclusion यह है कि recorded configurations के तहत output, latency और real usage compare हुए, लेकिन Provider ने कौन-सा effort accept किया यह confirm नहीं हुआ।

none save न होता दिखे तो क्या करें

5 October 2026 के public GitHub issue में reporter ने बताया कि उसके बताए specific main commits पर hermes config set agent.reasoning_effort none YAML null save कर सकता था, जबकि /reasoning none --global string none save करता था। यह version-bounded user report है। इससे यह साबित नहीं होता कि current version में behavior मौजूद है या किसी बाद के version में fix हो चुका है।

इस क्रम में जाँचें:

1. /reasoning none --global चलाएँ;
2. hermes config get agent.reasoning_effort चलाएँ;
3. hermes config path से मिली file खोलें और confirm करें कि value string none है, empty या null नहीं;
4. नया session शुरू करके /reasoning फिर चलाएँ;
5. यदि route या Provider server-side request record, echoed value या explicit confirmation expose करता है, तो sent/mapped value को received या accepted value से मिलाएँ; यदि log में केवल model, Token या spend है, तो accepted effort confirm न हो पाने की सीमा record करें, उसे infer न करें।

यदि model reasoning mandatory करता है, पूरी तरह off करना संभव नहीं होगा। Display toggle बदलने के बजाय route का lowest supported level चुनें।

OpenAI-compatible custom provider उपयोग करते समय

Effective behavior Hermes, model और provider तीनों पर निर्भर है। उदाहरण के लिए, current BetterToken Hermes setup guide अपनी API Key, https://www.bettertoken.ai/v1 Base URL और catalog का exact model ID configure करने तथा पहले short request से connection verify करने को कहती है। BetterToken यह guarantee नहीं करता कि हर model सभी reasoning levels support करेगा या higher level हर task को बेहतर बनाएगा।

किसी भी provider पर model ID, request record और actual usage को एक ही comparison table में रखें। वरना अनजाने model, route या billing-path change को reasoning effort effect समझा जा सकता है।

Quality bar पार करने वाला सबसे कम level चुनें

medium को global baseline रखें, occasional कठिन task पर session setting उपयोग करें, और high, xhigh या उससे ऊँचा per-model override तभी बनाएँ जब repeated same-task comparison stable gain दिखाए। Mechanical work में model को low, minimal या none पर तभी घटाएँ जब quality threshold बनी रहे और measured latency या real usage expected improvement दिखाए। जहाँ route sends mapping या Provider acceptance/execution record देता है, उसे verify करें; जहाँ नहीं देता, evidence limit साफ लिखें और Token या cost को accepted tier का proof न मानें।

Useful default theoretical maximum नहीं है। वह सबसे कम effort है जो आपके model और route पर acceptable latency तथा वास्तविक usage के साथ लगातार quality target पूरा करता है।