Anyone else having Kimi sessions drop with a 'network error' at exactly 1 hour?

Alright, let's cut through the predictable cloud of vague user reports. I've been observing a pattern so consistent it's practically a feature, not a bug. I'm willing to bet a significant portion of your monthly Kimi spend that the "network error" you're seeing at the 60-minute mark is a deliberate, hard session timeout.

Why am I so confident? Because from an infrastructure cost perspective, it's the most obvious lever to pull. Let's do the math they don't want you to see.

Assume a session holds some compute/memory allocation, even for an idle-ish chat. Let's model it conservatively:
* **Hypothetical VM cost per hour:** $0.10 (simplified)
* **Session lifespan:** Indefinite (if no timeout) vs. 1 hour (with timeout)
* **User behavior:** User leaves tab open, goes to lunch, forgets about it.

Without a timeout, that forgotten session could hold resources for 8 hours. Cost: $0.80.
With a 1-hour hard kill, cost is capped at: $0.10.

That's an **88% reduction** in potential waste for idle resources. Multiply that by thousands of concurrent "forgotten" sessions, and you're talking about real money saved off the infra bill. They've just externalized that cost-saving measure as a "network error" to the end-user.

I've been simulating this. The behavior is clockwork. Not 59 minutes. Not 61 minutes. 3600 seconds on the dot. Here's a crude script to log the lifecycle (you'd need to adapt it to your actual client-side monitoring):

```javascript
// Conceptual timer to track session longevity
let sessionStart = new Date();
let lastActivity = sessionStart;

setInterval(() => {
let now = new Date();
let sessionDuration = (now - sessionStart) / 1000;
let idleTime = (now - lastActivity) / 1000;

console.log(`Session alive: ${sessionDuration}s | Idle: ${idleTime}s`);

// Watch for the discontinuity around 3600s
if (sessionDuration >= 3580 && sessionDuration <= 3620) {
console.warn('CRITICAL WINDOW: 1-hour mark approaching.');
}
}, 30000); // Log every 30 seconds
```

The key questions for the community aren't about "if" this is happening, but:
* Can anyone confirm this is **universal**, or does it vary by subscription tier? (Free vs. Paid is the first place to look for differential treatment).
* Is the timeout purely duration-based, or is it tied to **inactivity**? My preliminary data suggests it's total session duration, regardless of activity bursts.
* What's the **reconnection behavior**? Does it dump context entirely, forcing a new session and doubling the effective cost for a long conversation, or can you resume? The latter would be more expensive for them to implement.

This is a classic FinOps trade-off: reliability for the user versus resource utilization for the provider. They've chosen their side of the equation. The real discussion should be about transparency. Calling it a "network error" is frankly insulting to anyone who's ever seen a real one. They should just return a `429 Too Many Minutes` with a clear "Session expired to manage costs, please start a new one."

So, who's got data? Let's compile evidence. Timestamps, error messages, subscription plans. Let's reverse-engineer their cost-saving algorithm.