Claude's AskUserQuestion: "No response after 60s – continued without ...

At 2:13 p.m., a coding agent asked a perfectly reasonable question: “Should I delete the generated migration and recreate it?” Nobody answered. Sixty seconds later, it kept going anyway.

That small behavior — AskUserQuestion: No response after 60s – continued without an answer — looks like a minor Claude Code edge case. In practice, it is a much bigger signal for anyone building agentic developer tools on top of Claude, GPT, Gemini, or any multi-model API stack: interactive AI workflows need a timeout policy, and that policy quietly decides whether your agent is helpful, blocked, or dangerous.

This article breaks down what happened, why the 60-second continuation matters, how it compares with today’s model landscape — Claude Opus 4.8, Sonnet 4.6, Haiku 4.5, Fable 5 with 1M context, GPT-5.5, and Gemini 3 — and what I would change if I were shipping an AI coding assistant this week.

What Happened

Claude Code includes an interaction pattern where the assistant can ask the human a question before continuing. That question may be simple:

Do you want me to run the full test suite?

Or it may be consequential:

This migration will drop the legacy_users table. Continue?

The recent behavior under discussion is that Claude’s AskUserQuestion path can time out after 60 seconds and continue without receiving a user answer. The visible message is essentially:

No response after 60s – continued without an answer

The important part is not the exact wording. The important part is the policy:

1. The model or agent requested human input.
2. The system waited for a fixed timeout.
3. No answer arrived.
4. The agent resumed execution anyway.

That is not automatically wrong. In many workflows, continuing is exactly what you want. If an agent asks “Should I inspect the neighboring file too?” and the user is away, continuing with a conservative default is better than hanging forever.

But it becomes risky when the question was acting as a safety gate.

There is a big difference between:

Should I keep searching for usages?

And:

Should I apply this destructive database migration?

Both are “questions” from the interface’s perspective. They are not the same kind of question from a product safety perspective.

Why This Matters More Than It Looks

The first generation of AI coding assistants mostly worked like autocomplete: suggest code, maybe explain code, maybe generate a function. Modern agents do something more operational. They read files, edit files, run commands, inspect errors, retry, and make judgment calls.

That changes the failure mode.

A bad autocomplete suggestion is annoying. A bad autonomous continuation can:

• Modify the wrong file.
• Delete generated but important artifacts.
• Run an expensive command.
• Continue with a false assumption.
• Mask the fact that user input was missing.
• Turn a reversible choice into an irreversible one.

In practice, the agent loop is where small interface choices become engineering policy. A timeout is not just a UX decision. It is a control-flow decision.

Here is the simplest version of the pattern:

answer = ask_user("Delete stale migration file?", timeout_seconds=60)

if answer is None:
    # The dangerous part is not the timeout.
    # The dangerous part is the default.
    proceed_with_default()

The real design question is: what should proceed_with_default() mean?

For low-risk questions, it can mean “continue with the least surprising option.” For high-risk questions, it should usually mean “stop and wait for explicit approval.”

The Hidden Taxonomy of Agent Questions

When I build or evaluate agentic workflows, I do not treat all questions equally. I use a rough taxonomy like this:

The AskUserQuestion timeout issue matters because it reminds us that an agent needs to know which category it is in. A one-size-fits-all 60-second timeout is fine only if the continuation behavior is conservative.

A common gotcha: developers often classify risk by the wording of the question, but the system should classify it by the tool call that follows. “Should I clean up?” sounds harmless until “clean up” means rm -rf ./generated.

What Actually Happens in Developer Workflows

Let’s make it concrete.

Imagine an agent working in a monorepo. It discovers that tests are failing because a generated API client is stale. It asks:

The generated client is out of date. Should I regenerate it?

No one answers in 60 seconds. The agent continues. What happens next depends on your environment.

A safe continuation might be:

npm run generate:client
git diff --stat

That is usually acceptable. The agent regenerated local files and showed the diff.

A riskier continuation might be:

npm run generate:client && npm test -- --updateSnapshot

Now the agent may have changed snapshots as well as generated code. Still possibly fine, but harder to review.

A dangerous continuation might be:

npm run db:reset
npm run generate:client

That should not happen without explicit consent in a real project environment.

The timeout did not create the danger by itself. The problem is when the timeout unlocks a chain of tool calls that should have required an answer.

A Better Policy: Defaults by Risk Level

If you are building an AI API wrapper, coding agent, DevOps bot, or internal assistant, implement explicit timeout semantics. Do not leave this buried inside generic “ask user” logic.

A practical JSON schema might look like this:

{
  "question": "Apply the database migration?",
  "risk_level": "high",
  "timeout_seconds": 60,
  "on_timeout": "pause",
  "allowed_without_response": false
}

For a low-risk question:

{
  "question": "Should I search test files too?",
  "risk_level": "low",
  "timeout_seconds": 30,
  "on_timeout": "continue_with_default",
  "default_answer": "yes"
}

The key is that on_timeout should be explicit. If your agent framework does not support this natively, add it in your orchestration layer.

A simple Python version:

from enum import Enum

class RiskLevel(str, Enum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"

def handle_timeout(question: str, risk: RiskLevel):
    if risk == RiskLevel.LOW:
        return {"action": "continue", "assumption": "safe default"}
    if risk == RiskLevel.MEDIUM:
        return {"action": "continue_limited", "assumption": "no side effects"}
    return {"action": "pause", "reason": "explicit user approval required"}

print(handle_timeout("Drop legacy table?", RiskLevel.HIGH))

Output:

{
  "action": "pause",
  "reason": "explicit user approval required"
}

That looks boring. Boring is good here. Agent safety is mostly boring control flow done consistently.

How This Compares Across Current Models

The timeout behavior is not really about Claude’s raw intelligence. Claude Opus 4.8, Sonnet 4.6, Haiku 4.5, Fable 5, GPT-5.5, and Gemini 3 can all participate in agent workflows where user input is missing. The difference is in how the surrounding product or framework handles uncertainty, tools, permissions, and state.

Here is the comparison I care about as a developer advocate, not as a leaderboard watcher:

The main point: no current frontier model removes the need for deterministic guardrails.

A smarter model may ask better questions. It may identify risk more accurately. It may explain its assumptions more clearly. But if the orchestration layer says “after 60 seconds, keep going,” the model is still bound by that policy.

Token and Cost Implications

Timeout behavior also has a cost dimension. If an agent asks a question, waits, then continues down the wrong path, it may burn tokens and tool time before the human returns.

Consider a coding task with this rough shape:

• Initial repo scan: 18,000 input tokens
• Model plan and reasoning output: 2,000 output tokens
• Tool results after continuing: 40,000 input tokens
• Patch explanation and retries: 6,000 output tokens

That is:

Input: 58,000 tokens
Output: 8,000 tokens

Using example rates of $3 per 1M input tokens and $15 per 1M output tokens, the math is:

Input cost  = 58,000 / 1,000,000 * $3  = $0.174
Output cost =  8,000 / 1,000,000 * $15 = $0.120
Total       = $0.294

That seems tiny for one run. At team scale, it adds up.

If 40 engineers each trigger 20 agent runs per day:

40 engineers * 20 runs * $0.294 = $235.20/day

If 15% of those runs continue after unanswered questions and require rework:

$235.20 * 15% = $35.28/day potentially wasted

Over a 22-workday month:

$35.28 * 22 = $776.16/month

These numbers are illustrative, not a claim about any specific vendor’s current pricing. Replace the rates with your actual provider costs. The lesson holds: bad continuation policy wastes both developer attention and API spend.

This is also where multi-model routing matters. In AI Prime Tech deployments, I’ve seen teams reduce cost by routing cheap classification and policy decisions to lighter models, while reserving Claude, GPT, or Gemini frontier calls for the work that actually needs them. The timeout decision is a good candidate for that kind of routing.

A Practical Pattern: “Ask, Assume, Announce”

If an agent does continue after a timeout, it should make the assumption visible.

Bad:

No response after 60s – continued without an answer

Better:

No response after 60s. Continuing with safe default: inspect files only, no edits or commands with side effects.

Best:

No response after 60s.

Assumption:
- You want me to continue investigation.
- I will not edit files.
- I will not run destructive commands.
- I will stop before applying changes.

That message gives the user something reviewable. It also constrains the agent’s next actions.

For implementation, I like an “ask, assume, announce” wrapper:

def ask_with_policy(prompt, risk_level, timeout_seconds=60):
    answer = ask_user(prompt, timeout_seconds=timeout_seconds)

    if answer:
        return {"mode": "answered", "answer": answer}

    policy = handle_timeout(prompt, risk_level)

    if policy["action"] == "pause":
        raise RuntimeError("User approval required before continuing")

    announce_timeout_policy(prompt, policy)
    return {"mode": "timeout", "policy": policy}

This makes the timeout path a first-class path, not an accidental fallback.

What I Would Change in Agent Interfaces

If I were designing the next iteration of an AI coding CLI, I would add four things.

1. Typed Questions

The agent should not just ask a string. It should ask a typed question:

{
  "type": "permission",
  "message": "Apply this patch?",
  "risk": "medium",
  "default": "no"
}

This lets the runtime enforce policy.

2. Tool-Aware Risk Detection

Risk should be inferred from the next tool call, not just the question text.

For example:

git diff -- src/

Low risk.

rm -rf dist/

Medium risk, depending on project.

terraform apply

High risk.

psql "$DATABASE_URL" -c "DROP TABLE users;"

Stop. Always stop.

3. Timeout Modes

Give users or organizations a config file:

{
  "askUserQuestion": {
    "defaultTimeoutSeconds": 60,
    "lowRiskTimeout": "continue",
    "mediumRiskTimeout": "continue_read_only",
    "highRiskTimeout": "pause"
  }
}

This is better than making every developer rediscover the behavior by surprise.

4. Transcript-Level Accountability

The final transcript should include every unanswered question and the assumption used.

Example:

Unanswered question:
- "Regenerate API client?"
- Timed out after 60s
- Continued with assumption: yes
- Actions taken: npm run generate:client, git diff --stat

That makes review possible. Without this, the user may only see the final patch and miss the fact that the agent made a decision for them.

The Trade-Off: Blocking vs. Autonomy

There is a real trade-off here. If an agent pauses every time the user misses a question, it becomes brittle. Developers step away. CI logs take time. Lunch happens. A useful agent should keep making progress where it can.

But autonomy is not binary. The better framing is:

Continue doing reversible, observable, low-risk work.
Pause before irreversible, external, or expensive work.

In practice, this means an agent can keep reading files, running safe local inspections, preparing patches, and summarizing options. It should pause before applying destructive changes, deploying, mutating remote state, or spending significant money.

The 60-second timeout is not inherently bad. The unsafe version is “no response, so I guessed and acted.” The safer version is “no response, so I narrowed my scope and continued only where reversible.”

Why Developers Using AI APIs Should Care

If you only use hosted chat interfaces, this may feel like a product quirk. If you build with AI APIs, it is your problem.

The model API usually does not know your organization’s risk tolerance. It does not know whether npm run reset is harmless or catastrophic. It does not know whether a generated file is disposable or manually edited. Your wrapper, agent runtime, or product has to encode that.

This is especially important for teams mixing models. You might use Haiku 4.5 for fast repo classification, Sonnet 4.6 for edits, Opus 4.8 for architecture decisions, GPT-5.5 for a second opinion, Gemini 3 for multimodal inputs, and Fable 5 when the full 1M context window is useful. That architecture can be powerful and cost-effective, especially through providers like AI Prime Tech that offer cheaper Claude/GPT/Gemini API access in one place.

But multi-model setups also increase the need for consistent policy. If each model path handles timeouts differently, your safety story becomes unpredictable.

Practical Takeaways

• Treat unanswered agent questions as a control-flow state, not a UI footnote.
• Use explicit timeout policies: continue, continue_read_only, pause, or abort.
• Never allow silent continuation before destructive, external, or expensive actions.
• Classify risk based on the next tool call, not just the natural-language question.
• Log every timed-out question, assumed answer, and action taken afterward.
• Use smaller models for cheap risk classification, but enforce final policy in deterministic code.
• Prefer “continue with bounded, reversible work” over both extremes: hanging forever or acting blindly.
• If your coding agent says No response after 60s – continued without an answer, review what it did next. The timeout is not the whole story; the post-timeout action is.