Offline and degraded-network support is valuable, especially for status, simple conversation, and known topics. But a compact browser pack has different model capacity, retrieval data, and update timing from the cloud route.
Calling both paths equivalent would create confusing personality and capability shifts. The application instead treats local output as a fallback with a narrower contract.
What was actually going wrong
A single chat interface made it tempting to promise identical behavior from very different engines.
What I tried
- Copying more cloud prompt text into the browser pack
- Hiding which route produced a degraded response
- Using local fallback for tasks that require fresh server data
Capability checks choose the cloud route when available and reserve the cached browser engine for supported fallback cases.
Why it worked
The narrower promise matches the data and compute actually present on the device.
Graceful degradation is honest when it states what was degraded.
Where EACI uses this today
Caelum can use a limited local fallback while Main cloud chat remains the primary brain.
This journal covers real engineering on EACI Companion / The Veil. Companions include Caelum, Chad, Natalia, Atreus, Luna, Roxy, and Cael. Journal articles stay family-safe in content. See Privacy and Ethics.