ChatGPT Thinking for 910 Minutes Non-Stop? The Truth Behind Stuck Long Tasks and How to Handle Them

ChatGPT appeared to think for 910+ minutes, but the task had silently frozen after 90 minutes.
A Reddit user discovered ChatGPT's thinking indicator ran for over 1,660 minutes while the actual task had been frozen since the 90-minute mark. This article analyzes the technical causes behind AI Agent long-task failures — including frontend-backend state desynchronization, tool call deadlocks, and missing timeout mechanisms — and offers practical advice for users and product design insights for building more reliable AI systems.
A "Thinking" Session That Lasted 910 Minutes
Recently, a Reddit user shared a striking phenomenon: they assigned ChatGPT a task, and the model's "thinking" status persisted for 910 minutes and counting. By comparison, this user's previous personal record was only about 40 minutes. The anomaly quickly sparked heated discussion across the community.

However, the story took an unexpected turn. According to the user's follow-up comments, the task had actually gotten "stuck" after about 90 minutes. From that point on, the model entered a bizarre state — the interface showed it was still "thinking," but in reality, it was neither producing any output nor consuming any usage quota. Eventually, the user manually terminated the task when the timer had accumulated to 1,660 minutes (over 27 hours).
This case may seem like an isolated software bug, but it reflects the very real challenges AI Agents face when handling long-running tasks.
The Illusion and Reality of the "Thinking" State
Long Thinking Doesn't Mean Actually Working
As OpenAI has rolled out models with deep reasoning and autonomous execution capabilities (such as the o1 and o3 series and Agent mode), "long thinking times" have gradually become a hallmark of advanced functionality. It's worth understanding the technical background of these models: the o1 and o3 series are model families specifically designed by OpenAI for complex reasoning tasks. Unlike traditional conversational models like GPT-4, they introduce an explicit Chain-of-Thought reasoning process — the model generates a series of intermediate reasoning steps internally before producing a final answer. This leads to significantly improved performance on tasks like mathematical proofs, code debugging, and multi-step logical reasoning. Agent mode goes even further, allowing the model not only to reason but also to autonomously invoke external tools (such as browsers, code interpreters, and file systems), breaking down complex tasks into multiple sub-steps and executing them sequentially. Essentially, it evolves from a "conversational assistant" to an "autonomous executor."
In theory, the longer a model thinks, the more complex the reasoning, tool invocation, or multi-step planning it's performing.
But this case reveals a critical issue: the "thinking" status displayed on the interface doesn't always reflect actual computational activity on the backend. When the task got stuck after 90 minutes, the frontend UI continued showing the spinning thinking animation, creating the illusion that "the AI is still hard at work." This frontend-backend state desynchronization is especially common in long-running sessions.
From a web architecture perspective, this desynchronization has clear technical roots: in modern web applications, the frontend (the interface users see) and the backend (the server performing actual computations) maintain state synchronization through API communication. For short tasks, this synchronization is usually not an issue. But for long-running tasks, a persistent connection (such as WebSocket or Server-Sent Events) needs to be maintained between the frontend and backend. Once this connection is broken due to network fluctuations, server restarts, or load balancer timeouts, the frontend can lose its ability to sense the backend's state. If the application lacks reconnection and state polling mechanisms, the frontend will "freeze" on the last known state — in this case, the "thinking" animation spinning endlessly.
Why Does ChatGPT "Pretend" to Think?
From a technical perspective, ChatGPT's prolonged unresponsive frozen state is typically caused by the following:
- Session timeout and residual state: Backend computation processes may have already terminated due to timeouts, memory overflow, or exceptions, but the frontend never received a clear termination or error signal, causing the UI to remain stuck on the old state.
- Tool invocation deadlocks or blocking: In Agent mode, the model may get stuck waiting on an external tool call (such as a network request with no response), neither progressing nor reporting an error. Specifically, Agent architectures typically follow the "ReAct" (Reasoning + Acting) paradigm: the model first reasons about what to do next, then calls the appropriate tool to execute, and then reasons again based on the tool's returned results. The problem is that external tool calls introduce uncontrollable factors — an HTTP request might hang indefinitely because the target server is unresponsive, a code execution might enter an infinite loop, or the model's reasoning logic itself might create circular dependencies, repeatedly jumping between steps without converging to a final result. If the system doesn't set independent timeout thresholds and retry limits for each tool call, the entire task chain can be completely blocked by a single chokepoint.
- Billing lag: The user specifically noted "no usage was consumed," which strongly suggests the backend reasoning engine wasn't actually running — real computation incurs charges. This further confirms the model was simply "idling."
Lessons for AI Agent Product Design
Long Tasks Need More Robust State Management
This case exposes current AI products' shortcomings in long task lifecycle management. When a task is designed to potentially run for tens of minutes or even hours, the product must have comprehensive health checks and timeout circuit-breaking mechanisms.
An ideal design should include:
- Heartbeat detection: Periodically confirming whether the backend process is truly alive, rather than relying solely on frontend animations. Heartbeat detection is a classic mechanism in distributed systems for monitoring process liveness. The principle is to have worker processes periodically send an "I'm still alive" signal to a monitoring service. In AI long-task scenarios, this means the backend reasoning process needs to send a status update to the frontend or middleware at regular intervals (such as every 30 seconds or 1 minute), which can include information like the current execution stage, tokens consumed so far, and a summary of the most recent tool call result. If the monitor fails to receive signals for several consecutive heartbeat cycles, it can determine the task is abnormal and trigger an alert or automatic recovery process. Kubernetes' Liveness Probe and Readiness Probe are typical engineering implementations of this concept in the container orchestration domain.
- Automatic timeout termination: Setting a reasonable maximum execution time for tasks, actively reporting errors and releasing resources when the limit is exceeded, rather than leaving users to wait hundreds of minutes manually. The circuit breaker mechanism involved here borrows from the circuit breaker concept in electrical protection. Its core idea is: when the system detects that a component is continuously failing or timing out, it proactively "breaks" calls to that component rather than letting requests pile up indefinitely. In AI Agent scenarios, the system needs to set timeout thresholds for both the overall task and each sub-step individually, enabling fast failure, graceful degradation, and automatic recovery.
- Progress transparency: Showing users real intermediate progress (such as "Executing step 3") rather than a vague "thinking."
User Trust Is at Stake
For ordinary users, an interface that displays "working" while producing no output severely damages trust in the product. Users might mistakenly believe the AI is processing an extremely complex problem and wait patiently, when in reality they're just wasting their time. This Reddit user's journey from initial amazement ("broke my 40-minute record") to finally giving up and manually stopping the task perfectly illustrates this experience gap.
Long Tasks Are the Trend, but Reliability Is the Prerequisite
AI's ability to handle complex tasks that require extended execution times is itself a direction of technological progress. From simple Q&A to Agents that can autonomously complete multi-step research, coding, and data analysis, AI's autonomy is continuously increasing. Companies like OpenAI are actively pushing the boundaries of this capability.
From an industry perspective, the evolution of AI Agents is undergoing a paradigm shift from "tool" to "assistant" to "autonomous agent." Beyond OpenAI, products like Google DeepMind's Gemini, Anthropic's Claude, and Microsoft's Copilot are all actively expanding Agent capabilities. The industry generally categorizes Agent capabilities into multiple levels: Level 1 is simple instruction execution, Level 2 features multi-turn dialogue and context understanding, Level 3 enables autonomous planning and tool use, and Level 4 can handle complex projects spanning hours or even days. Most products currently sit at the transition stage between Level 2 and Level 3, and the long-task scenarios discussed in this article represent exactly the engineering challenges that must be overcome in the evolution toward Level 4. Reliability, observability, and recoverability are widely regarded in the industry as the three critical thresholds for Agents to transition from "demo-grade" to "production-grade."
But this 910-minute (actually 1,660-minute) case reminds us: capability expansion must be built on a foundation of reliability. When tasks extend from seconds and minutes to hours, the system's fault tolerance, monitoring, and recovery capabilities become crucial. Otherwise, so-called "long-task capability" may be nothing more than a frozen progress bar.
For regular users, here's a practical tip: if a ChatGPT task has been unresponsive for a long time, check whether your usage quota is increasing. If the quota hasn't budged at all, the task has most likely gotten stuck, and manually restarting would be a wiser choice than waiting it out.
Conclusion
This share from the Reddit community, though just an isolated product anomaly, vividly illustrates a core challenge of the AI Agent era: how to make long-running AI tasks both powerful and reliable. As more and more AI products move toward autonomously executing complex tasks, frontend-backend state consistency, timeout management, and progress transparency will become important benchmarks for measuring product maturity. For users, maintaining rational judgment and making good use of monitoring signals are also essential skills for effective collaboration with AI.
Related articles

AI Agent Development in Practice: A Complete Breakdown from Framework Selection to Production Deployment
A systematic breakdown of the complete AI Agent development workflow covering framework selection, tool invocation, data processing, and deployment to help developers build production-ready agents.

DeepSeek Harness and the Codis Architecture Explained: Agent Development Enters the Plugin Era
DeepSeek Harness broke GitHub Star velocity records on launch. Its Codis architecture turns Agent development from reinventing the wheel into plugin-based assembly, drastically lowering the barrier for vertical domain Agents.

WorkBuddy Hands-On Guide: How This Domestic Codex Alternative Can Actually Do Your Work
WorkBuddy is a domestic AI Agent tool, often called the Chinese alternative to Codex. This article compares it with Doubao, covering file ops, office integrations, and plugin deployment.