A DeepSeek API request that has not started inference can remain connected for up to 10 minutes before the server closes the connection. That is a documented provider boundary, not proof that DeepSeek Harness is still making progress. (api-docs.deepseek.com)

Symptom → The interface keeps waiting, but no new request evidence appears.

Fastest fix → Verify persisted retry events, process activity, and tool state. If no retry has started and the wait has no controlled boundary, stop the task and preserve the scene.

This guide is for:

  • Local users who see a task waiting without knowing whether it is still running.
  • Remote Agent operators who need clear stop and recovery rules for unattended work.
  • Platform engineers building joint diagnostics for retry logs, timeouts, network health, and provider availability.

Do not begin by refreshing the Web UI. Refreshing changes what you see, not what the process is doing.

Start With The Evidence, Not The Spinner

A DeepSeek Harness session can look frozen for several different reasons:

  1. The provider request is waiting for scheduling or a response.
  2. A retry was scheduled but the next attempt never started.
  3. The model returned successfully and the Agent is waiting for a tool, approval, Hook, or shell process.
  4. The remote process died while the client connection stayed open.
  5. The task is alive, but its workspace, credentials, or network path changed.

These states have different recovery actions. More retries help only with selected transient failures. They do not repair a wrong API key, invalid request body, incorrect model name, broken Base URL, blocked approval, or a dead shell process.

The DeepSeek API documents distinct response classes for invalid format, authentication failure, insufficient balance, invalid parameters, rate limits, server errors, and overload. Treating all of them as the same LLM retry problem hides the actual fault. (api-docs.deepseek.com)

A useful rule is simple:

A loading indicator is a display state. A persisted event, process change, provider response, or tool result is operational evidence.

The public DeepSeek Harness repository describes session persistence, SQLite-backed state, streaming events, a batch engine, approval receipts, and cost controls. Those records are more useful during an incident than a screenshot of an unchanged interface. (github.com)

First Step: Prove Whether A Retry Is Happening

Scenario: The page still says “running”

Suppose you submitted a long coding task. The page remains open. The status does not change. You suspect the request is retrying, but there is no visible error and no new network activity.

Do not answer the question from the screen alone. Check four signals:

  • The task or session status in the persistent store.
  • The event sequence around the last provider request.
  • The operating system process and child processes.
  • Workspace activity, such as changed files, updated checkpoints, or new result records.

For retry diagnosis, look for a pair:

  1. A retry scheduled event.
  2. A later retry start event.

The first proves that the Harness decided to wait or retry. The second proves that another provider attempt actually began. If the first exists without the second, inspect cancellation state, process lifetime, and the scheduler or worker that owns the task.

Record the following before you interrupt anything:

  • Harness version and commit or release identifier.
  • Session ID, run ID, and task creation time.
  • Last persisted event and its timestamp.
  • Model, Provider, Base URL, and request mode.
  • Process ID, parent process, and child processes.
  • Current working directory and workspace identity.
  • Last provider response or transport error.
  • Whether an approval, Hook, or tool call is pending.

Reminder: A disconnected SSH, terminal, or browser session does not prove that the remote task stopped. It also does not prove that the task is still safe to resume. Check the host and process state separately.

Stop the task when all three conditions are true:

  • No new retry-start or task-progress evidence appears.
  • The owning process is gone, blocked, or cannot be inspected.
  • The expected wait has no documented or configured upper bound.

Recovery is acceptable only after a small verification run completes and the original workspace is still identifiable.

Second Step: Separate Scheduled Retries From A Missing Next Attempt

A common failure pattern is not “the model keeps retrying.” It is “the Harness scheduled a retry, then the next request never began.”

This can happen when:

  • The task was cancelled during the wait.
  • The worker process exited.
  • The host restarted or entered sleep.
  • A remote connection dropped and the supervisor did not reconnect.
  • The retry scheduler lost access to its state directory.
  • The task hit a process-level timeout before the next request.

Use the event sequence as your timeline. Compare the time of the scheduled retry with:

  • The process start and exit records.
  • The last heartbeat or progress event.
  • The network connection state.
  • The task cancellation flag.
  • The existence and modification time of the persistent state directory.

Do not invent a retry count or backoff duration. The task may have no fixed retry budget in the version you are running, or the policy may vary by failure class. Verify the current source, configuration directory, and release notes before documenting a number.

DeepSeek documents keep-alive behavior while a request is waiting. Non-streaming calls may return empty lines, while streaming calls may send SSE keep-alive comments. If your client parser mishandles those records, it can appear inactive even when the connection is alive. DeepSeek also documents that a request not started within 10 minutes may be closed by the server. (api-docs.deepseek.com)

Save the scene before stopping if:

  • The persistent store is readable.
  • The task has a known run ID.
  • The workspace is mounted and unchanged.
  • The process is alive but clearly waiting without a new attempt.
  • You may need to compare the failed run with a clean reproduction.

Do not continue waiting just because the connection remains open. A live socket is not the same as a progressing Agent.

Third Step: Fix Deterministic Model Errors Before Retrying

If every attempt returns the same model error, stop increasing the retry budget. Inspect the model path.

Check these fields in order:

Check What to verify Decision
Provider The selected Provider matches the intended DeepSeek route Correct it before another long task
API key The key is present, active, and loaded by the running process Replace or reload credentials safely
Base URL The URL matches the API format required by the selected integration Test the endpoint directly
Model The model identifier is supported by the current API documentation Use a currently supported model
Request body Messages, tools, thinking settings, and response format are valid Reduce to a minimal request
Balance and limits The account can accept the request and is not rate limited Check the account and status pages

The current DeepSeek API documentation lists deepseek-v4-flash and deepseek-v4-pro as model identifiers in the Chat Completions reference. The official change log also records the retirement timeline for legacy names, so an old configuration should not be assumed to remain valid forever. (api-docs.deepseek.com)

Use a minimal text request after making a configuration change:

  • One short user message.
  • No tools.
  • No JSON output.
  • No long conversation history.
  • No custom proxy unless the production path requires it.
  • The same Provider, Base URL, and model as the failing task.

Only return to the original task after the minimal request succeeds. If the minimal request fails with the same deterministic response, the Agent loop is not the right place to troubleshoot.

DeepSeek’s documented error categories show why this matters. A 401 points to authentication. A 402 points to insufficient balance. A 422 points to invalid parameters. A 429 points to rate limiting. A 500 or 503 may justify a later retry, subject to your own stop policy. (api-docs.deepseek.com)

The API also documents account-level concurrency limits. The current page lists 500 concurrent connections for deepseek-v4-pro and 2,500 for deepseek-v4-flash; exceeding the applicable limit produces HTTP 429. Treat those figures as current provider documentation, not as a universal Harness retry policy. (api-docs.deepseek.com)

Fourth Step: Check Whether The Model Finished And A Tool Did Not

A successful model response does not necessarily mean the Agent task completed.

DeepSeek tool calling is a multi-stage exchange:

  1. The model returns a tool call.
  2. Your application executes the function.
  3. Your application sends the tool result back.
  4. The model produces the next response.

DeepSeek explicitly states that the model generates the tool call but does not execute the external function itself. (api-docs.deepseek.com)

That creates a different diagnostic path. If the last event shows a completed LLM response or a tool call, inspect:

  • Approval queues.
  • Hook handlers.
  • Bash or shell child processes.
  • External command timeouts.
  • File locks.
  • Network calls made by the tool.
  • Tool-result serialization.
  • Whether the tool result was appended to the next model request.

Do not classify a blocked Bash process as a model retry. Do not grant every permission to “see if it works.” That can destroy the evidence and create a security incident.

Use a reduced tool test instead:

  • Select one harmless read-only tool.
  • Use a known workspace path.
  • Run a command that returns quickly.
  • Capture tool-start, tool-end, exit status, and returned content.
  • Confirm that the Agent receives the tool result.

The recovery standard is not “the tool process exists.” The tool must start, finish, return a result, and allow the Agent loop to advance.

If the API returns a tool call but no tool-start event follows, inspect the Harness execution pipeline. If tool-start exists but tool-end does not, inspect the tool process and its dependencies. If both exist but no follow-up model request begins, inspect message assembly and Provider routing.

Fifth Step: Test The Remote Environment Before Resuming

Remote tasks add failure modes that local users often miss:

  • The host entered sleep or restarted.
  • The network egress changed.
  • DNS or firewall rules changed.
  • The API key was loaded only in an interactive shell.
  • The working directory points to a new mount.
  • The process is running under a different user.
  • The machine identity changed after reprovisioning.
  • The client disconnected while the worker continued.

Start with process inspection on the remote Mac:

ps aux | grep -i deepseek
pgrep -af node
pwd
ls -la

Then inspect the actual workspace, not only the directory shown in the client. Confirm that expected files, state databases, logs, and checkpoints are present.

For the network path, compare:

  • DNS resolution.
  • HTTPS reachability to the configured endpoint.
  • Proxy environment variables.
  • TLS or certificate errors.
  • Egress restrictions.
  • Whether the same host can complete the minimal text request.

Check the DeepSeek service status page before treating a broad provider incident as a local configuration failure. The page separates API service status from web chat status and provides incident history. (status.deepseek.com)

A remote disconnect alone is ambiguous. A changed environment identity is not. If the host rebooted, the workspace was recreated, or credentials came from a different secret store, create a new verification task. Do not force an old task to continue across an unknown environment boundary.

Use This Stop And Recovery Checklist

Run this checklist before deciding whether to wait, cancel, or migrate:

  • [ ] Capture the Harness version, release, session ID, run ID, and workspace path.
  • [ ] Confirm whether a retry scheduled event exists.
  • [ ] Confirm whether a matching retry start event exists afterward.
  • [ ] Record the latest provider response, status code, and error text from the official response or local log.
  • [ ] Check whether the process and its child processes are still alive.
  • [ ] Check for a pending approval, Hook, Bash command, or external tool.
  • [ ] Verify the Provider, API key source, Base URL, and model identifier.
  • [ ] Run a minimal text-only DeepSeek API request.
  • [ ] Run one harmless tool call if the text request succeeds.
  • [ ] Check the remote host for restart, sleep, network, and workspace changes.
  • [ ] Stop when progress evidence is absent and the wait has no controlled boundary.
  • [ ] Create a new verification task if the environment identity has changed.
  • [ ] Preserve the failed run before deleting state or reinstalling components.

This separates three outcomes:

Continue waiting when new retry-start events, process activity, or workspace progress are visible.

Cancel and rerun when the request fails deterministically, no next retry begins, or the tool pipeline is blocked.

Migrate the environment when the host identity, workspace, credentials, or network path can no longer be trusted.

FAQ: Long Waits, LLM Retry, And Remote Recovery

Is DeepSeek Harness always waiting because it is retrying?

No. Waiting may represent provider scheduling, an open keep-alive connection, a blocked approval, a running tool, or a dead process. A retry requires durable evidence. Look for a scheduled retry followed by a retry start, then confirm that the new request changes the event or response timeline.

How many times will a failed model request retry?

Do not rely on a universal number. The current retry budget may depend on the Harness release, operation type, Provider configuration, and error classification. Confirm the implementation and configuration you are running. Never use a larger retry count to hide a 401, 402, 422, wrong model, or wrong Base URL.

Should you keep waiting during repeated retries?

Wait only while the process is alive and new attempts are demonstrably beginning. Cancel when the event stream stops advancing, the wait becomes unbounded, or the same configuration error returns. Keep-alive traffic can show that a connection remains open, but it does not prove that inference or the Agent loop is progressing.

How do you restore a remote background task after a retry failure?

Preserve the state directory, logs, process details, workspace path, and credentials route first. Then verify the host identity and run a minimal request. If the machine restarted or the workspace changed, start a new verification task instead of blindly resuming the old background task.

Choose The Next Action

A reliable incident decision tree is:

  1. Do you have a retry scheduled event?
    - No: inspect the last model, tool, approval, or process event.
    - Yes: continue to the next question.

  2. Do you have a later retry start event?
    - No: inspect cancellation, worker lifetime, and persistent state access. Stop if the process cannot be verified.
    - Yes: continue only if the failure appears transient and the wait remains bounded.

  3. Does the same error repeat without configuration changes?
    - Yes: stop retrying. Validate Provider, credentials, Base URL, model, request body, balance, and limits.
    - No: compare the provider response and network evidence across attempts.

  4. Did the model finish and emit a tool call?
    - Yes: switch to tool, approval, Hook, Bash, and external dependency diagnosis.
    - No: remain on the model or transport path.

  5. Did the remote environment change?
    - Yes: create a new verification task.
    - No: resume only after the minimal text and tool tests pass.

If the problem appears only after a remote disconnect or during a long unattended run, review your DeepSeek Harness background task acceptance process and define recovery evidence before launching the next job. For a remote Mac, also document the cloud Mac delivery and environment acceptance path so a restarted host is not mistaken for the original execution environment.

Repeated retries on a local setup often cost more than API tokens. They consume operator time, leave partial files, hold remote processes, and make it harder to identify the first failure. A Mac rental from MACCOME can be the cleaner option when you need a temporary, inspectable environment for a long Agent run, remote validation, or recovery test. It avoids committing to new hardware, but it does not remove the need to validate credentials, network access, workspace persistence, and process supervision.

That is the practical boundary: use your current environment when it is stable and identifiable. Move the task to a managed Mac environment when local sleep, unstable remote access, changing workspaces, or repeated reprovisioning are the real source of failure—not the model itself.