runpod · mintlify · Aug 31, 2026 · Aug 31, 2026
diff --git a/get-started/agent-skills.mdx b/get-started/agent-skills.mdx
@@ -1,14 +1,18 @@
 ---
 title: "Agent skills for AI coding tools"
 sidebarTitle: "Agent skills"
 description: "Manage GPU workloads on Runpod with coding agents like Claude Code, Codex, and Cursor. Review setup steps and core concepts for building on Runpod."
 tag: "NEW"
 ---

 The Runpod skills plugin teaches your coding agent how to run GPU workloads on Runpod. Once installed, you can ask your agent to create Pods, deploy Serverless endpoints, transfer files, or deploy your own code with Flash, all in natural language. A built-in router sends each request to the right skill, so you don't need to know which tool applies.
 
 It works with [Claude Code](https://code.claude.com/docs), [Codex](https://github.com/openai/codex), [Cursor](https://cursor.com/), [GitHub Copilot](https://github.com/features/copilot), [Windsurf](https://codeium.com/windsurf), [Cline](https://github.com/cline/cline), and [many other AI agents](https://www.skills.sh/).
 
+<Note>
+The skills plugin requires a coding agent with terminal access and Node.js installed (the install command uses `npx`). You can't install it in chat apps like the ChatGPT or Claude mobile apps, which don't provide a shell.
+</Note>
+
 ## Quick start
 
 Install the skills with a single command that works with every agent:
@@ -17,7 +21,7 @@
 npx skills add runpod/runpod-plugins-official
 ```

 Next, install the Runpod CLI that the skills rely on (skip this if you already have it):

 ```bash
 curl -sSL https://cli.runpod.net | bash
@@ -25,7 +29,7 @@
 brew install runpod/runpodctl/runpodctl
 ```

 Then authenticate with your [Runpod API key](/get-started/api-keys). The same key works for the CLI, Flash, and the bundled MCP server:

 ```bash
 # Set the key for the current shell (add to ~/.zshrc or ~/.bashrc to persist):
@@ -35,15 +39,15 @@
 runpodctl doctor
 ```

 That's it — restart your agent and [get started](#getting-started).

 ## Getting started

 There are no commands to memorize: describe what you want, and the router picks the right skill (prompting you if something like an API key is still missing). Confirm it's wired up by asking:

 - "List my Runpod endpoints"

 If your endpoints come back, you're set — see [What you can do](#what-you-can-do) for more examples.

 ## What's included

@@ -52,12 +56,12 @@
 | Skill | Description |
 |-------|-------------|
 | **runpod** | Router and entry point. Reads your task and hands it to the right skill. |
 | **runpod-mcp** | Manages Pods, endpoints, templates, network volumes, registries, and billing through the Runpod MCP server. |
 | **runpodctl** | Manages the same resources from the [Runpod CLI](/runpodctl/overview), plus Hub deployments, file transfers, SSH keys, and model caching. |
 | **flash** | Writes and deploys your own Python code to Runpod Serverless using the [runpod-flash](/flash/overview) SDK. |
 | **companion-clis** | Uses supporting CLIs such as Hugging Face, Docker, and the AWS CLI when a task needs them. |
 | **runpod-usage** | Provides conceptual knowledge about Pods, Serverless, storage, and GPU selection. |
 | **runpod-migrate** | Migrates a codebase from the GraphQL API or REST v1 to REST v2. It inventories which API each call site uses, rewrites the call sites, and verifies the result. |

 The plugin also includes a collection of worked, end-to-end reference tasks, such as deploying a Whisper endpoint or running a model on a Pod, that guide your agent through common workflows.

@@ -67,18 +71,18 @@

 | Category | Example prompt |
 |----------|----------------|
 | Create resources | "Create a Pod with an RTX 4090" |
 | List resources | "List my Pods" or "Show my Serverless endpoints" |
 | GPU availability | "What GPUs are available?" |
 | Account info | "Show my account balance" |
 | Deploy endpoints | "Deploy a Serverless endpoint using my template" |
 | Manage Pods | "Stop my Pod" or "SSH into my Pod" |
 | Deploy with Flash | "Deploy this function to a remote GPU with Flash" |
 | Local development | "Start a local dev server with Flash" |

 ## Migrate an existing integration

 If you already have an integration built on the GraphQL API or REST v1, the `/runpod:migrate` command moves it to REST v2. It inventories which API version each part of your code uses, then rewrites the call sites, flags breaking changes, and verifies the result. It migrates one file at a time, with one commit per file.

 Because it edits and commits your code as it goes, run it on a feature branch and review each commit before you merge or deploy.

@@ -88,19 +92,19 @@
 /runpod:migrate [scope: all | rest | graphql] [path]
 ```

 `scope` defaults to `all`, which covers both REST v1 and GraphQL. Use `rest` to target REST v1 only, or `graphql` to target GraphQL only. `path` defaults to the current directory. For example, to migrate only the REST v1 code under `src/`:

 ```bash
 /runpod:migrate rest src/
 ```

 Running the command requires the Runpod skills plugin installed in your coding agent (see [Quick start](#quick-start)). For a manual walkthrough of the API changes, see the [migration guide](/api-reference-v2/migrate-from-v1).

 ## Native install options

 The `npx skills add` command above works everywhere. If you'd rather install the plugin through your agent's native marketplace, use the route for your agent below. Each route installs the same router and skills.

 ### Claude Code

 Add the marketplace, install the plugin, then reload:

@@ -110,7 +114,7 @@
 /reload-plugins
 ```

 Installing the plugin also wires up the hosted Runpod MCP server. To authenticate it, run `/mcp`, select **runpod**, and choose **Sign in with Runpod**.

 ### Codex

@@ -118,7 +122,7 @@
 codex plugin marketplace add https://github.com/runpod/runpod-plugins-official.git
 ```

 Run `codex /plugins`, open the **Runpod** tab, and install (reload if prompted). If the Runpod MCP tools don't appear, add the hosted server manually:

 ```bash
 codex mcp add runpod --transport http https://mcp.getrunpod.io/
@@ -128,15 +132,15 @@

 Gemini can install the plugin natively through the bundled `gemini-extension.json`. Follow your client's extension documentation to add it.

 ## Connecting the MCP server on other agents

 The hosted Runpod MCP server gives your agent structured control-plane tools for managing Pods, endpoints, and other resources. Claude Code sets it up automatically during a native install. On other agents, run the guided installer, which detects your agent and configures the connection:

 ```bash
 npx @runpod/mcp-server@latest add
 ```

 The installer authenticates the MCP server for you. To reuse the API key you already set instead, pass it as a bearer header when you add the server. For example, in Claude Code:

 ```bash
 claude mcp add --transport http runpod -s user https://mcp.getrunpod.io/ \
@@ -145,7 +149,7 @@

 ## Update and uninstall

 To update the plugin to the latest version:

 ```bash
 # Claude Code:
@@ -173,7 +177,7 @@
 npx skills remove runpod
 ```

 If a command reports a name mismatch, list what's installed first with `/plugin marketplace list` (Claude Code), `codex plugin marketplace list` (Codex), or `npx skills list` (skills.sh), then use the name shown.

 ## Learn more


diff --git a/pods/pricing.mdx b/pods/pricing.mdx
@@ -1,4 +1,4 @@
 ---
 title: "Pricing"
 sidebarTitle: "Pricing"
 description: "Explore pricing options for Pods, including on-demand and savings plans. Review setup, configuration, and operations guidance for Runpod Pods."
@@ -13,19 +13,21 @@
 Runpod offers custom pricing plans for large scale and enterprise workloads. [Contact our sales team](https://ecykq.share.hsforms.com/2MZdZATC3Rb62Dgci7knjbA) to learn more.
 </Tip>
 
-Pods are billed by the second for compute and storage, with no fees for data ingress or egress. Find the latest GPU pricing on the [Runpod console](https://www.console.runpod.io/pods) during Pod deployment.
+Pods are billed by the second for compute and storage, with no fees for data ingress or egress.
+
+The documentation doesn't list per-GPU hourly rates or savings plan discounts because they vary by GPU type and cloud type (Secure or Community) and change over time. Find current rates on the [Runpod pricing page](https://www.runpod.io/pricing) or in the [Runpod console](https://www.console.runpod.io/pods) during Pod deployment.
 
 ## Pricing options
 
 | | On-demand | Savings plan |
 |---|-----------|--------------|
 | **Pricing** | Standard hourly rate | Discounted (prepaid) |
 | **Commitment** | None | 3 or 6 months upfront |
 | **Best for** | Development, testing, variable workloads | Long-running production workloads |

 ### On-demand

 Pay-as-you-go pricing. Resources are dedicated to your Pod and cannot be displaced by other users.

 <Warning>
 You must have at least one hour's worth of credits for your selected configuration to deploy an on-demand instance.
@@ -43,12 +45,12 @@

 | Storage type | Running Pod | Stopped Pod | Notes |
 |--------------|-------------|-------------|-------|
 | **Container disk** | \$0.10/GB/month | Not charged | Temporary; erased when Pod stops |
 | **Volume disk** | \$0.10/GB/month | \$0.20/GB/month | Persistent; retained until Pod deleted |
 | **Network volume** | \$0.07/GB/month (< 1TB) | \$0.07/GB/month | Permanent; portable between Pods |
 | | \$0.05/GB/month (> 1TB) | \$0.05/GB/month | |

 Storage is billed per-second for container and volume disks, and hourly for network volumes. You are not charged if the host <MachineTooltip /> is unavailable.

 <Note>
 Runpod is not designed for long-term cloud storage. Back up critical data to your local machine or a dedicated storage provider.
@@ -56,7 +58,7 @@

 ## Account limits

 - **Minimum balance**: Pods are automatically stopped when your account balance reaches \$0. Pods with a network volume are stopped and their data is preserved, while Pods without a network volume are terminated and their data cannot be recovered. To avoid interruptions, enable [low balance notifications](/accounts-billing/billing#low-balance-notifications) or set up [auto-pay](https://www.console.runpod.io/user/billing).
 - **Spend limit**: Default limit of \$80/hour across all resources. [Contact support](https://www.runpod.io/contact) to increase.

 ## Track your costs

diff --git a/serverless/endpoints/endpoint-configurations.mdx b/serverless/endpoints/endpoint-configurations.mdx
@@ -1,4 +1,4 @@
 ---
 title: "Endpoint settings"
 sidebarTitle: "Endpoint settings"
 description: "Reference guide for all Serverless endpoint settings and parameters. Review configuration and operations guidance for Runpod Serverless."
@@ -17,27 +17,27 @@

 | Setting | Default | Description |
 |---------|---------|-------------|
 | **Active workers** | 0 | Always-on workers (eliminates cold starts) |
 | **Max workers** | 3 | Maximum concurrent workers |
 | **GPUs per worker** | 1 | GPU count per worker instance |
 | **Idle timeout** | 5s | Time before idle worker shuts down |
 | **Execution timeout** | 600s (10 min) | Max job duration |
 | **Job TTL** | 24h | Total job lifespan in system |
 | **FlashBoot** | Enabled | Faster cold starts via state retention |

 ## General configuration

 ### Endpoint name

 Display name for identifying your endpoint in the console. Does not affect the endpoint ID used for API requests.

 ### Endpoint type

 **Queue-based endpoints** use a built-in queueing system with guaranteed execution and automatic retries. Ideal for async tasks, batch processing, and long-running jobs. Implemented using [handler functions](/serverless/workers/handler-functions).

 **Load balancing endpoints** route traffic directly to workers, bypassing the queue. Designed for low-latency applications like real-time <InferenceTooltip /> or custom REST APIs. See [Load balancing endpoints](/serverless/load-balancing/overview).

 ### GPU configuration

 Determines the hardware tier for your workers. Select multiple GPU categories to create a prioritized fallback list. If your first choice is unavailable, Runpod automatically uses the next option. Selecting multiple types improves availability during high demand.

@@ -47,7 +47,7 @@

 Specify up to three GPU types in priority order when configuring an endpoint. Runpod uses this ranking to distribute workers across available GPUs, improving availability during high demand.

 For endpoints with five or more workers, Runpod distributes workers across your selected GPU priorities. Most workers run on your primary GPU type, with fewer assigned to secondary and tertiary selections. This reduces throttling when your primary GPU is constrained.

 For endpoints with fewer than five workers, all workers use the highest-priority GPU type available.

@@ -61,15 +61,15 @@

 Maximum concurrent instances your endpoint can scale to. Acts as a cost safety limit and concurrency cap. Set ~20% higher than expected max concurrency to handle traffic spikes smoothly.

 ### GPUs per worker

 Number of GPUs assigned to each worker instance. Default is 1. Generally prioritize fewer high-end GPUs over multiple lower-tier GPUs.

 ### Auto-scaling type

 **Queue delay**: Adds workers when requests wait longer than the threshold (default: 4 seconds). Best when slight delays are acceptable for higher utilization.

 **Request count**: More aggressive scaling based on pending + active work. Formula: `Math.ceil((requestsInQueue + requestsInProgress) / scalerValue)`. Use scaler value of 1 for max responsiveness. Recommended for LLM workloads or frequent short requests.

 ## Lifecycle and timeouts

@@ -80,24 +80,24 @@
 ### Idle endpoint scale-down

 Runpod automatically scales down endpoints that go a long time without any requests, so unused endpoints don't keep consuming your account balance. 
 * After 3 days with no requests, the endpoint's max workers is reduced to 2 and Runpod sends you an email notification. 
 * After 7 days with no requests, max workers is set to 0. 

 This scale-down is automatic and system-driven, and the timer is based on request activity, so any incoming request resets it.

 Once an endpoint has been scaled down this way, it stays at its reduced max workers until you raise the value yourself. To use the endpoint again, increase its max workers in the Runpod console. To prevent an endpoint from scaling down in the first place, make sure it continues to receive requests.

 ### Execution timeout

 Maximum duration for a single job. When exceeded, the job fails and the worker stops. Keep enabled to prevent runaway jobs. Default: 600s (10 min). Range: 5s to 7 days.

 Configure in **Advanced** settings, or override per-request via `executionTimeout` in the [job policy](/serverless/endpoints/send-requests#execution-policies).

 ### Job TTL (time-to-live)

 Total lifespan of a job in the system. When TTL expires, job data is deleted regardless of state (queued, running, or completed). Default: 24 hours. Range: 10s to 7 days.

 The timer starts at submission, not execution. If a job queues for 45 minutes with a 1-hour TTL, only 15 minutes remain for execution.

 <Warning>
 TTL is a hard limit. If it expires while a job is running, the job is immediately removed and status checks return 404. Set TTL to cover both expected queue time and execution time.
@@ -110,16 +110,20 @@
 | Request type | Retention | Notes |
 |--------------|-----------|-------|
 | Async (`/run`) | 30 min | Retrieve via `/status/{job_id}` |
 | Sync (`/runsync`) | 1 min | Returned in response; also available via `/status/{job_id}` |

 Results are permanently deleted after retention expires.

 ## Performance features

 ### FlashBoot
 
 Reduces cold starts by retaining worker state after spin-down, allowing faster "revival" than fresh boots. Most effective on endpoints with consistent traffic where workers frequently cycle between active and idle.
-Both new GPU and CPU endpoints will have FlashBoot enabled by default, and you can edit existing endpoints to enable or disable FlashBoot.
+New GPU and CPU endpoints have FlashBoot enabled by default, and you can edit existing endpoints to enable or disable it.
+
+State retention is best-effort, not guaranteed. If a worker's retained state is no longer available, for example after a long period without traffic, the worker starts with a standard cold start instead. To guarantee low latency, set [active workers](#active-workers) above zero.
+
+When managing endpoints through the [REST API](/api-reference-v2/serverless/create-a-serverless-endpoint), the `flashboot` field accepts three modes: `OFF`, `FLASHBOOT`, and `PRIORITY_FLASHBOOT` (FlashBoot with priority capacity).
 
 ### Model
 
@@ -135,10 +139,10 @@

 [Network volumes](/storage/network-volumes) provide persistent storage across worker restarts. Tradeoffs: adds network latency and restricts your endpoint to the volume's data center. Use only when you need shared persistence or datasets exceeding container limits.

 ### CUDA version selection

 Ensures workers run on <MachinesTooltip /> with compatible drivers. Select your required version plus all newer versions, since CUDA is backward compatible and a wider range increases available hardware.

 ### Expose HTTP/TCP ports

 Exposes the worker's public IP and port for direct external communication. Required for persistent connections like WebSockets.
diff --git a/serverless/endpoints/send-requests.mdx b/serverless/endpoints/send-requests.mdx
@@ -1,4 +1,4 @@
 ---
 title: "Send API requests"
 sidebarTitle: "Send API requests"
 description: "Submit and manage jobs for your queue-based endpoints by sending HTTP requests. Review configuration and operations guidance for Runpod Serverless."
@@ -21,13 +21,13 @@

 ## How requests work

 A **job** is a unit of work containing the input data from the request, packaged for processing by your [workers](/serverless/workers/overview). If no worker is immediately available, the job is queued. Once a worker is available, the job is processed using your worker's [handler function](/serverless/workers/handler-functions).

 ## Sync vs. async

 - `/runsync` submits a **synchronous** job.
  - Client waits for the job to complete before returning the result.
  - Results are available for 1 minute (5 minutes max).
  - Ideal for quick responses and interactive applications.
 - `/run` submits an **asynchronous** job.
  - The job processes in the background; retrieve results via `/status`.
@@ -71,7 +71,7 @@
 | `/cancel`         | POST   | Stop a job in progress or waiting in the queue.                            |
 | `/retry`          | POST   | Requeue a failed or timed-out job with the same job ID and input.          |
 | `/purge-queue`    | POST   | Clear all pending jobs from the queue.                                     |
 | `/health`         | GET    | Monitor endpoint status, including worker and job statistics.              |

 See the [operation reference](/serverless/endpoints/operation-reference) for detailed examples using cURL and the Runpod SDK.

@@ -81,7 +81,7 @@

 ## Advanced options

 Beyond the required `input` object, you can include optional top-level parameters for additional functionality.

 ### Webhook notifications

@@ -94,7 +94,21 @@
 }
 ```
 
-Your webhook should return a `200` status code. If the call fails, Runpod retries up to 2 more times with a 10-second delay.
+When your job completes, Runpod sends a `POST` request to your webhook URL. The request body contains the same information as the [`/status` operation](/serverless/endpoints/operation-reference#status), including the job `id`, `status`, and `output`:
+
+```json
+{
+  "delayTime": 31618,
+  "executionTime": 1437,
+  "id": "60902e6c-08a1-426e-9cb9-9eaec90f5e2b-u1",
+  "output": {
+    "text": ["Your job results here"]
+  },
+  "status": "COMPLETED"
+}
+```
+
+Your webhook should return a `200` status code to acknowledge receipt. If the call fails, Runpod retries up to 2 more times with a 10-second delay between attempts.
 
 ### Execution policies
 
@@ -113,17 +127,17 @@

 | Option             | Description                                              | Default              | Constraints             |
 |--------------------|----------------------------------------------------------|----------------------|-------------------------|
 | `executionTimeout` | Maximum time a job can run while being processed         | 600000 (10 minutes)  | Min 5 sec, max 7 days   |
 | `lowPriority`      | When true, job won't trigger worker scaling              | false                | -                       |
 | `ttl`              | Total lifespan of the job before deletion                | 86400000 (24 hours)  | Min 10 sec, max 7 days  |

 <Info>
 Setting `executionTimeout` in a request overrides the default endpoint setting for that specific job only.
 </Info>

 #### TTL vs. execution timeout

 - **`ttl`**: Total lifespan of the job. Timer starts when submitted and covers queue time, execution time, and everything in between. When TTL expires, the job is deleted regardless of state.
 - **`executionTimeout`**: Maximum time the job can actively run once a worker picks it up. Only enforced during execution.

 <Warning>
@@ -132,7 +146,7 @@

 #### Long-running jobs

 For jobs that need to run longer than the default 24-hour TTL:

 1. Set `executionTimeout` to your desired maximum runtime.
 2. Set `ttl` to cover **both expected queue time and execution time**.
@@ -147,7 +161,7 @@
 }
 ```

 This allows up to 48 hours of active runtime with 72 hours total lifespan (24 hours headroom for queue time).

 <Warning>
 Both `ttl` and `executionTimeout` have a maximum of 7 days. A job with 7-day TTL that queues for 2 days only has 5 days remaining for execution.
@@ -155,12 +169,12 @@

 #### Result retention

 After completion, results are retained for a fixed period separate from TTL:

 | Request type       | Retention period |
 |--------------------|------------------|
 | `/run` (async)     | 30 minutes       |
 | `/runsync` (sync)  | 1 minute         |

 ### S3-compatible storage

@@ -199,7 +213,7 @@

 Rate limits scale with your endpoint's worker count. The system uses whichever is higher between:

 1. **Base limit**: Fixed rate limit per user per endpoint (shown above)
 2. **Worker-based limit**: `number_of_running_workers × requests_per_worker`

 Requests exceeding the effective limit return `429 (Too Many Requests)`. Implement retry logic with exponential backoff to handle rate limiting gracefully.
@@ -214,13 +228,13 @@
 | 401         | Unauthorized          | Verify your API key is correct and has permission |
 | 404         | Not Found             | Check your endpoint ID                            |
 | 429         | Too Many Requests     | Implement backoff and retry logic                 |
 | 500         | Internal Server Error | Check endpoint logs; worker may have crashed      |

 | Issue              | Possible Causes                          | Solutions                                                           |
 |--------------------|------------------------------------------|---------------------------------------------------------------------|
 | Job stuck in queue | No available workers, max workers reached | Increase max workers, check endpoint health                        |
 | Timeout errors     | Job takes longer than execution timeout  | Increase timeout in job policy, optimize processing                |
 | Failed jobs        | Worker errors, input validation issues   | Check [endpoint logs](/serverless/development/logs), verify input  |
 | Missing results    | Results expired                          | Retrieve within expiration window (30 min async, 1 min sync)       |

 See [error handling](/serverless/workers/handler-functions#error-handling) for implementation details.
diff --git a/serverless/pricing.mdx b/serverless/pricing.mdx
@@ -1,4 +1,4 @@
 ---
 title: "Pricing"
 sidebarTitle: "Pricing"
 description: "Learn how Serverless billing works to optimize your costs. Review setup, configuration, deployment, and operations guidance for Runpod Serverless."
@@ -13,13 +13,15 @@
 
 Serverless offers pay-per-second pricing with no upfront costs. You're billed from when a worker starts until it fully stops, rounded up to the nearest second.
 
+The documentation doesn't list per-GPU rates because they vary by GPU type and change over time. Find current rates on the [Runpod pricing page](https://www.runpod.io/pricing) or in the Runpod console when creating an endpoint. To estimate a job's cost, multiply the listed hourly rate by your expected worker runtime.
+
 ## Worker types
 
 | | Flex workers | Active workers |
 |---|--------------|----------------|
 | **Behavior** | Scale to zero when idle | Always running (24/7) |
 | **Pricing** | Standard per-second rate | Discounts available through sales inquiry |
 | **Best for** | Variable workloads, cost optimization | Consistent traffic, low-latency requirements |

 ## What you're billed for

@@ -28,8 +30,8 @@
 | Cost component | Description | Rate |
 |----------------|-------------|------|
 | **Compute** | GPU time while workers run | See the [Runpod pricing page](https://www.runpod.io/pricing) |
 | **Container disk** | Worker storage (5-min intervals) | ~\$0.10/GB/month |
 | **Network volume** | Shared persistent storage | \$0.07/GB/month (< 1TB), \$0.05/GB/month (> 1TB) |

 ### Compute cost breakdown

@@ -39,7 +41,7 @@

 2. **Execution time**: Processing requests. Set [execution timeouts](/serverless/endpoints/endpoint-configurations#execution-timeout) to prevent runaway jobs.

 3. **Idle timeout duration**: The time a worker remains active (running) after completing a request, waiting for additional requests before scaling down (default: 5 seconds). Configure in [endpoint settings](/serverless/endpoints/endpoint-configurations#idle-timeout).

 <Tip>
 For high-volume workloads with significant storage needs, use [network volumes](/storage/network-volumes) to share data across workers and reduce per-worker storage costs.
@@ -47,12 +49,12 @@

 ## Account limits

 **Spend limit**: Default limit of \$80/hour across all resources. [Contact support](https://www.runpod.io/contact) to increase.

 ## Billing support

 If you believe you've been billed incorrectly, [contact support](https://www.runpod.io/contact), including the following information in your ticket:

 - Endpoint ID
 - Request ID (if applicable)
 - Approximate time of the issue