Reasoning on Demand: AdaHome’s Case for Tiered Local Assistants

TL;DR for operators

A household assistant should not spend the same computational effort on “turn on the light” as on “make the room comfortable.” It also should not treat one unusual request as a permanent preference change.

AdaHome applies that principle through tiered local processing. Explicit commands take a short planning path, while requests that need interpretation or personal context receive additional reasoning, validation, and—where appropriate—user confirmation. Under a common Llama 3.2-3B setup, it achieved 86.7% success on both direct and indirect commands while recording the lowest latency and token use in every command category among the compared systems.

The results suggest that heavier processing is not automatically better. AdaHome’s lighter routing often outperformed more elaborate pipelines, although the most expressive comparator retained an advantage on ambiguous commands. Its preference layer also favors past interactions that are relevant to the current request and recent enough to remain informative, allowing temporary deviations to fade while persistent changes reshape future behavior.

For product teams, the design question is therefore not whether every request should receive maximum reasoning. It is where extra interpretation justifies its latency and compute cost, how preference memory should learn and forget, and which proposed actions must still pass schema checks or explicit confirmation. The evidence supports further testing of this architecture, not immediate generalization to real homes or safety-critical automation.

Routine commands should not pay the ambiguity tax

A household assistant receives fundamentally different kinds of instructions. “Turn on the bedroom light” names both the target and action. “The room is too hot” requires contextual interpretation. “I want to relax” may depend on a preference learned from prior interactions.

Running all three through the same elaborate reasoning pipeline imposes unnecessary latency on the first command and may still fail to resolve the third without user-specific evidence. Local deployment makes this allocation problem more visible because inference time, memory, token volume, and energy use are constrained.

AdaHome divides requests into direct, indirect, and ambiguous categories. Direct commands go to a simple planner. The other two categories use a compact, single-pass reasoning process called Chain-of-Draft, which produces a concise intent representation and structured device actions rather than a long reasoning trace.

The resulting actions are checked against a fixed device schema. Outputs containing invalid device names or attributes can be constrained and regenerated. Ambiguous or sensitive actions can also be presented for confirmation before execution. The language model therefore does not receive unrestricted authority over the home: its output must pass through an executable contract.

The lighter route led on direct and indirect commands

The paper compares AdaHome with reproduced implementations of Sasha, SAGE, and Harmony. All four systems use Llama 3.2-3B, greedy decoding, the same local hardware, the same 12-device schema, and disabled memory during the single-turn benchmark. Each system-category experiment was repeated three times.

For direct commands, AdaHome also recorded no false positives and a 13.3% false-negative rate. Harmony, by comparison, had a 37.8% false-positive rate in that category.

These results are not evidence that compact reasoning dominates every alternative. Harmony’s ambiguous-command advantage suggests that a more expressive pipeline can explore a wider range of interpretations. It paid heavily for that coverage: 32.93 seconds of latency, 819 input tokens, and 195 output tokens for ambiguous commands, compared with AdaHome’s 14.47 seconds, 463 input tokens, and 65 output tokens.

The result therefore concerns allocation rather than universal model superiority. AdaHome performed best where requests were explicit or could be resolved through limited contextual inference. The most computationally elaborate system retained an edge where the intended action depended most heavily on interpretation.

Indirect and ambiguous success was assessed by a Qwen2.5-14B judge using majority voting rather than exact match. The researchers validated the judge against human annotations on 48 stratified examples and reported Cohen’s kappa of 0.834. This strengthens confidence in the within-benchmark comparison, although it does not remove the measurement dependence on another language model.

Personalization becomes a weighted estimate, not a longer prompt

A retrieval-based assistant commonly searches prior interactions and appends them to the current prompt. This can expose the model to relevant history, but it also expands the context and leaves the model to reconcile repeated, conflicting, or temporary behaviors.

AdaHome instead converts confirmed or corrected interactions into normalized preference records. It retrieves semantically related records and assigns each one a weight:

Here, semantic similarity determines whether the old interaction concerns the same underlying intent, while temporal decay reduces the influence of older behavior. The implementation uses $\gamma=3$ to emphasize close semantic matches and $\lambda=0.1$ for recency decay.

For each binary device state, AdaHome calculates a weighted estimate:

Frequent, recent, semantically similar outcomes therefore dominate isolated deviations. A sustained sequence of different outcomes can still move the estimate. This is the personalization problem the design is solving: remaining stable when a user behaves unusually once, but adapting when the change persists.

In 30 constructed sequences of eight interactions, AdaHome achieved 87.5% preference consistency, 80.0% recovery after temporary deviations, and 100.0% adaptation success after persistent shifts. The retrieval-augmented prompt baseline achieved 52.5%, 10.0%, and 30.0%, respectively.

AdaHome required 2.6 turns to adapt, compared with 2.0 for the baseline. Faster movement is not necessarily better here. A system that changes its stored preference after limited contradictory evidence may be responsive, but it is also more vulnerable to temporary exceptions.

The ablation identifies two separate personalization jobs

The component tests clarify what produces the longitudinal result.

Removing memory reduced stable preference accuracy to 7.5% and eliminated successful adaptation. This is main mechanism evidence: without persistent interaction history, the assistant cannot display the tested form of continual personalization.

Retaining memory but removing the preference extractor produced 90.0% recovery and 70.0% adaptation success, with a 3.1-turn adaptation delay. Raw interaction memory could preserve behavior, but paraphrases and surface variation introduced semantic noise. Normalizing commands into preference-oriented intent representations improved consistency and adaptation success while reducing the delay.

For product teams, this separates two engineering functions that are often combined under “memory.” Storage preserves interaction history. Representation determines whether different utterances are treated as evidence about the same preference.

Product architecture should separate routing, memory, and authority

What the paper directly shows: under one controlled local setup, selective planning achieved a stronger accuracy-efficiency balance than the reproduced alternatives. A semantic-and-time-weighted preference layer also outperformed prompt augmentation in constructed longitudinal scenarios.

What Cognaptus infers: an edge assistant can be organized as a tiered system rather than a single general reasoning loop. Routine commands can remain local and cheap. Underspecified requests can invoke additional interpretation. Preference learning can operate as a separate estimation service rather than consuming an expanding context window. Cloud or larger-model escalation can then be reserved for requests that exceed local confidence, device scope, or risk thresholds.

This separation also improves governance. The planner proposes an action; the schema determines whether it is valid; the preference layer supplies user-specific evidence; and the confirmation gate determines whether execution requires explicit approval. Each component can be evaluated and restricted independently.

The evidence stops before real household deployment

The evaluation uses 90 constructed commands, simulated eight-turn preference sequences, one small model, one hardware configuration, and a fixed 12-device environment. Baseline systems were reproduced rather than evaluated from their original implementations.

The preference formulation also covers binary device states. It does not yet demonstrate reliable learning of continuous values such as preferred temperature or brightness. Cold-start behavior still depends on language-model interpretation and early user feedback. Speech, gesture, multiple household members, conflicting preferences, adversarial commands, device failures, and long-term behavioral drift were not evaluated.

Local execution can reduce external transmission of commands and preference records, but locality alone does not establish privacy or security. Device compromise, insecure storage, excessive retention, and unsafe execution permissions remain implementation risks.

AdaHome is therefore best read as architectural evidence. It shows that local assistants need not choose between minimal automation and uniform heavy reasoning. Selective computation, explicit preference estimation, schema validation, and confirmation can be assembled into a more disciplined control pipeline. Whether that pipeline remains accurate, acceptable, and safe in occupied homes still requires longitudinal user testing.

Cognaptus: Automate the Present, Incubate the Future.