Sonilo Task Recovery

Every Sonilo generation that runs asynchronously on the backend (SFX, ducking, video-to-video, video-to-sound, dubbing, proofread, video-analysis, and video_to_music(preserve_speech=true)) is already charged the moment it's accepted — a client-side timeout does not stop it or refund it. This tool checks a task's status and, once finished, downloads its result. It never itself charges anything.

Setup: See the setup-api-key skill.

This tool is a safety net, not something to call speculatively. Only use it when you actually have a task_id — from a timeout error message, or from the [sonilo-mcp] task submitted: <id> line a host prints to stderr the moment a task is submitted (this survives even a cancelled call).

Transport: MCP or CLI

Pick one at the start of the session and stay on it. Do not mix the two inside a single job, and do not announce the choice.

1. Sonilo MCP tools visible in this session (get_sfx_task and friends) — use them. This is the preferred path: it needs no shell, and it is the only one that survives a very long generation. If a call fails to authenticate — rather than failing on its inputs — this transport is not usable in this session: go to 2 instead of retrying it.
2. No usable Sonilo MCP tools, but sonilo account exits 0 — use the CLI commands below. Same API, same account, same credential file. Probe with sonilo account, not sonilo whoami: whoami exits 0 even when signed out, so it cannot tell the two states apart.
3. Neither — stop and run the setup-api-key skill. Do not call api.sonilo.com with curl to work around it; both transports handle uploads, polling and retries that a bare request does not.

Quick Start

MCP tool call (recommended)

get_sfx_task(task_id="a1b2c3d4-...")

The tool has two names. The local sonilo-mcp server calls it get_sfx_task; the hosted OAuth server (the sonilo-claude-plugin path) calls it get_generation_task(task_id). Same job, same arguments — call whichever one the connected server actually exposes rather than assuming, since only one of the two exists in any given session.

Python (pip install sonilo)

from sonilo import Sonilo

client = Sonilo()  # reads SONILO_API_KEY

status = client.tasks.get("a1b2c3d4-...")   # single check, never raises on failure
result = client.tasks.wait("a1b2c3d4-...")  # polls until terminal; raises TaskFailedError/TaskTimeoutError
result.save("recovered.wav")

tasks.get/tasks.wait default to parsing an SFX-shaped result. For a task from dubbing, video_to_sound/video_to_video_sound, analyze_video, or async video_to_music, pass the matching parser explicitly (from sonilo.resources.tasks import parse_music_result, parse_sound_result, parse_dubbing_result, parse_video_analysis_result) — see sonilo-python's README for the exact call shape per task type.

JavaScript / TypeScript (npm install sonilo)

import { SoniloClient } from "sonilo";

const client = new SoniloClient(); // reads SONILO_API_KEY

const status = await client.tasks.get("a1b2c3d4-...");   // single check
const result = await client.tasks.wait("a1b2c3d4-...", { pollInterval: 2000 }); // waits up to 45 min by default

Same caveat as Python: pass the task's actual result type as wait<T>()'s generic (e.g. wait<MusicTaskResult>(...)) for a non-SFX task — see sonilo-js's README.

CLI (npm install -g sonilo-cli or pip install sonilo-cli)

sonilo tasks get a1b2c3d4-...

# npm's sonilo-cli: --poll-interval/--timeout are milliseconds
sonilo tasks wait a1b2c3d4-... --poll-interval 2000 --timeout 2700000

# pip's sonilo-cli: the same flags are seconds
sonilo tasks wait a1b2c3d4-... --poll-interval 2 --timeout 2700

The two sonilo-cli packages (npm and pip) aren't the same codebase — double-check which one is installed before assuming a flag's units.

cURL (raw REST API, no MCP host)

curl "https://api.sonilo.com/v1/tasks/a1b2c3d4-..." \
  -H "Authorization: Bearer $SONILO_API_KEY"

The MCP tool does one status check and, if status is terminal, downloads and saves the resulting file(s) for you — it does not poll in a loop.

Tool

Behavior by Status

Workflow Tips

• Safe to call repeatedly. If a result was already downloaded to disk, a later call reports "Already downloaded" instead of re-fetching a duplicate copy — you won't accumulate -1/-2 suffixed files from checking twice.
• Don't confuse this with get_account_services/get_usage (the account skill) — this tool is about recovering one specific generation's output, not account-level info.
• If a failed task shows refunded: false, point the user at get_usage to reconcile billing, and note the charge stands.
• output_directory defaults to SONILO_MCP_BASE_PATH, same as every generation tool — pass the same directory you'd have used for the original call if you want the recovered file alongside other output.

Error Handling

A transient failure while checking (e.g. backend 5xx) does not mean the result is lost — re-run get_sfx_task(task_id) shortly after. A 401/402 here means the check failed (key rotated, account suspended) — the task itself was already charged and its result is still on the backend; resolve the auth/billing issue, then call get_sfx_task again.