Class ChatThermalOptions

Namespace

Qavren.Edge.Chat

Assembly

Qavren.Edge.Chat.Onnx.dll

How thermal pressure paces or stops a turn.

public sealed class ChatThermalOptions

Inheritance

object

ChatThermalOptions

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.ReferenceEquals(object, object)

object.ToString()

Properties

AbortAt

At or above this, terminate the turn. Default Critical.

RefuseNewTurnsInLowPowerMode

Refuse to START a turn in low-power mode. Default false: that is a product decision, not a safety one.

RefuseWhenThermalUnknown

Refuse to start a turn when EdgeResourceSnapshot.Thermal is Unknown. Default false, and that is a decision rather than an accident of enum ordering.

Sub-project 2 numbers Unknown = 0, below Nominal, and its own doc says "the platform reports nothing usable. Never treat this as "fine"." A bare state >= ThrottleAt would treat it as better than fine - never throttling, never aborting - on every desktop, every hosted runner, and every Android device below API 29 where the thermal API is unavailable. So the comparisons in the decode loop are written explicitly as thermal != Unknown && thermal >= threshold, with the intent in the code rather than in the enum's numbering.

Having made it explicit, the default is still "do not refuse", for the same reason the memory gate skips an unreadable AvailableMemoryBytes rather than refusing on it: a reading nobody can make is never a refusal, and refusing here would make chat unusable on every desktop. What sub-project 4 owes instead is visibility - Unknown is published verbatim in the thermalState diagnostics key and in ChatTurnStatus.Thermal, never normalised to Nominal - and this switch, for a caller who has measured their hardware and wants the opposite.

ThrottleHeadroom gets the same treatment for free: Android returns NaN when it is polled faster than about once a second or when the device does not support it, and NaN >= 1.0f is false, so an unreadable headroom never throttles. That is the same rule reached by a different route, and it is stated so nobody "fixes" it.

SampleInterval

How often the monitor is re-read mid-decode. Default 1 s, which is also sub-project 2's monitor cache window and Android's GetThermalHeadroom rate limit - so sampling costs nothing beyond the cached read.

ThrottleAt

At or above this, pace the decode to ThrottledTokensPerSecond. Default Serious.

ThrottleHeadroom

Android's headroom, where 1.0 is the documented SEVERE threshold. Null disables.

ThrottledTokensPerSecond

The paced rate. Default 8 tok/s - readable, and a visibly slow answer beats a dead one.