autodl

AutoDL

Purpose

Use this skill to answer AutoDL questions and operate AutoDL resources through the companion MCP server. Prefer official API output over assumptions. Never claim a resource exists, a price is current, a GPU is available, or an action succeeded unless the corresponding API returned it.

Resource loading

• Read references/api-reference.md before choosing or calling an AutoDL MCP tool.
• Read references/operations-guide.md for lifecycle, billing, storage, networking, environment, and safety decisions.
• Read the relevant row in references/docs-index.md when the request concerns a help topic outside the API reference or requires a current official rule.
• Use references/docs-manifest.json only for documentation coverage audits or drift checks.
• Run node scripts/refresh-docs.mjs when the user asks for current documentation, the saved index is older than 30 days, or a documented field conflicts with a live API response. This refreshes metadata and links, not a verbatim copy of the site.

Operating workflow

1. Classify the request as read-only, state-changing, destructive, or documentation-only.
2. For API work, identify the exact typed MCP tool from references/api-reference.md. Do not substitute Pro instance IDs, deployment UUIDs, container UUIDs, image UUIDs, machine IDs, or GPU specification IDs for one another.
3. Run read-only discovery first when an identifier or current state is missing.
4. Before any state-changing call, summarize the target, requested change, billing effect, and data impact. Obtain explicit user confirmation, then call the tool with confirm=true.
5. After a state-changing call, inspect code, msg, request_id, and returned data. Query status again when the operation is asynchronous.
6. Report partial permissions honestly. Container Instance Pro requires personal or enterprise real-name verification; elastic deployment and performance monitoring require enterprise verification.

Safety rules

• Never use AutoDL resources for virtual-currency mining. The official anti-mining policy prohibits it and violations can cause account action and financial liability.
• Treat release instance and delete deployment as destructive. Require the exact target ID and explicit confirmation in the current conversation. For Pro instances, power off before release.
• Treat create, power-on, replica increase, and elastic deployment creation as billable. Do not infer a budget or acceptable price ceiling.
• Treat power-off, stop container, stop deployment, replica decrease, NFS switching, image saving, blacklist changes, and WeChat messages as state-changing.
• Never place the developer Token in prompts, logs, source files, output, examples, or Git. Load it from AUTODL_TOKEN.
• Instance detail can contain root_password and jupyter_token. Keep them redacted unless the user explicitly needs credentials and understands the exposure.
• Do not expose custom-service URLs to third parties or use them outside the permitted research context described by AutoDL's service agreement.
• Do not promise data durability. Local system/data disks have no redundancy guarantee. Back up important data to durable storage.