Fix broken links: CLAUDE.md references to .claude/*.md

CLAUDE.md

@@ -1,21 +1,21 @@
 # CLAUDE.md
 
 This file provides guidance to Claude Code when working with this repository.
 
 ## Project Overview
 
 This is the Runpod documentation site, built with [Mintlify](https://mintlify.com/). The documentation covers Runpod's cloud GPU platform: Serverless endpoints, Pods, Flash SDK, storage, and APIs.
 
 ## Quick Reference
 
 | Topic | File |
 |-------|------|
-| Directory structure, navigation, snippets, tooltips | [.claude/architecture.md](.claude/architecture.md) |
-| Writing style, capitalization, terminology | [.claude/style-guide.md](.claude/style-guide.md) |
-| Running and writing documentation tests | [.claude/testing.md](.claude/testing.md) |
-| Local dev, linting, publishing workflow | [.claude/development.md](.claude/development.md) |
+| Directory structure, navigation, snippets, tooltips | `.claude/architecture.md` |
+| Writing style, capitalization, terminology | `.claude/style-guide.md` |
+| Running and writing documentation tests | `.claude/testing.md` |
+| Local dev, linting, publishing workflow | `.claude/development.md` |
 
 ## Key Commands
 
 ```bash
 mintlify dev                    # Start local dev server
@@ -27,17 +27,17 @@
 
 **Claude should continuously learn and improve these docs.**
 
 If you discover something that would be useful for future sessions, ask me:
 > "I noticed [insight]. Would you like me to add this to `.claude/[appropriate-file].md`?"
 
 Examples of things worth capturing:
 - Patterns that work well (or don't) in this codebase
 - Common mistakes to avoid
 - Useful commands or workflows discovered during tasks
 - Clarifications about how Runpod products work
 
 ## Terminology Quick Reference
 
 **Capitalize:** Runpod, Pods, Serverless, Hub, Instant Clusters, Flash, Secure Cloud, Community Cloud, Public Endpoint
 
 **Lowercase:** endpoint, worker, template, handler, network volume, data center, cluster, fine-tune, repo

instant-clusters/ray-vllm.mdx

@@ -1,13 +1,13 @@
 ---
 title: "Deploy an Instant Cluster with Ray and vLLM"
 sidebarTitle: "Ray + vLLM"
 description: "Run distributed inference across multiple nodes using Ray and vLLM on an Instant Cluster."
 tag: BETA
 ---
 
 This tutorial shows how to use Instant Clusters with Ray to run distributed inference on large language models. By combining Ray's cluster management with vLLM's tensor and pipeline parallelism, you can serve models that exceed the memory of a single node — for example, a 70B parameter model across multiple 8×H100 pods.
 
 Ray handles the cluster topology; vLLM uses it to split the model across GPUs both within each node (tensor parallelism) and across nodes (pipeline parallelism).
 
 <Note>
   Distributed inference with Ray and vLLM on Instant Clusters is currently in beta. Join our [Discord](https://discord.gg/runpod) to provide feedback and get support.
@@ -22,23 +22,23 @@
 
 ---
 
 ## Step 1: Deploy an Instant Cluster
 
 1. Open the [Instant Clusters page](https://console.runpod.io/instant-clusters).
 2. Click **Create Cluster**.
 3. Name your cluster and configure it. For this walkthrough, set **Pod Count** to **2** and select **8× H100 SXM GPUs** per pod. Use the **Runpod PyTorch** template as your base image.
 
    <Note>
    Increase `/dev/shm` when configuring your pod. The default (64 MB) is too small for large tensor-parallel workloads. Set it to at least 8 GB. In the pod configuration, add the environment variable `MALLOC_ARENA_MAX=1` and set `--shm-size` to `8g` in your Docker run options.
    </Note>
 
 4. Click **Deploy Cluster**. You are redirected to the Instant Clusters page.
 
 ---
 
 ## Step 2: Start the Ray head on pod-0
 
 The first pod (`CLUSTERNAME-pod-0`) runs the Ray head node. All other pods connect to it as workers.
 
 1. Click your cluster to expand the pod list.
 2. Click **CLUSTERNAME-pod-0**, then click **Connect → Web Terminal**.
@@ -55,7 +55,7 @@
    bash ray-vllm-cluster/head.sh
    ```
 
    The script sets the correct NIC address and starts Ray:
 
    ```bash
    # head.sh (excerpt — see full script in the repo)
@@ -76,7 +76,7 @@
 
 ## Step 3: Join the worker pods to the cluster
 
 Repeat this for each remaining pod in the cluster (`pod-1`, `pod-2`, …).
 
 1. In the Instant Clusters page, click the next pod and open its **Web Terminal**.
 2. Clone the same scripts:
@@ -111,7 +111,7 @@
      --num-gpus=$NUM_TRAINERS
    ```
 
    `$MASTER_ADDR` is injected automatically by Runpod into all pods in the cluster — it resolves to `pod-0`.
 
 ---
 
@@ -137,9 +137,9 @@
 
 ---
 
 ## Step 5: Launch distributed inference with vLLM
 
 Run this on `pod-0` only. vLLM uses the Ray cluster that is already running.
 
 ```bash
 bash ray-vllm-cluster/serve.sh
@@ -167,7 +167,7 @@
 
 ## Step 6: Test the endpoint
 
 Once vLLM reports that it is ready, validate from `pod-0`:
 
 ```bash
 # Check the server is healthy
@@ -190,9 +190,9 @@
 
 ---
 
 ## Step 7: Clean up
 
 When you are done, return to the [Instant Clusters page](https://console.runpod.io/instant-clusters) and delete your cluster. Leaving it running continues to incur charges.
 
 ---
 
@@ -213,22 +213,23 @@
 ## Common issues
 
 **Ray workers don't join**
 Confirm `$MASTER_ADDR` resolves from each worker pod. Run `ping $MASTER_ADDR` in a worker terminal. If it fails, the cluster network may still be initializing — wait 30 seconds and try again.
 
 **vLLM OOM during model load**
 Check that `/dev/shm` is large enough (at least 8 GB for 70B models). Also verify that `--tensor-parallel-size` matches the number of GPUs per node — a mismatch causes uneven shard sizes.
 
 **`VLLM_HOST_IP` binding error**
 This error occurs when vLLM tries to bind to `0.0.0.0` on a pod with multiple network interfaces. Make sure `VLLM_HOST_IP` is set to the internal IP (`hostname -I | awk '{print $1}'`) before starting the server.
 
 **Stale Ray cluster after restart**
 If you restart a pod, Ray does not automatically rejoin the cluster. Rerun `head.sh` on `pod-0` first, then `worker.sh` on all other pods.
 
 ---
 
 ## Next steps
 
-- Adapt the serve script to load your own model from a [GlobalStore](/storage/globalstore) or [Network Volume](/storage/network-volumes) mount.
+{/* TODO: The link target /storage/globalstore does not exist. Restore the link once a GlobalStore docs page is published, or replace "GlobalStore" with the correct product name. */}
+- Adapt the serve script to load your own model from a GlobalStore or [Network Volume](/storage/network-volumes) mount.
 - Scale up by increasing the pod count and adjusting `--pipeline-parallel-size` accordingly.
 - Try [Axolotl on an Instant Cluster](/instant-clusters/axolotl) for distributed fine-tuning.
 - Review the [Instant Cluster configuration reference](/instant-clusters/configuration) for full details on environment variables and networking.

serverless/advanced-workflows/batch-jobs.mdx

@@ -1,7 +1,7 @@
 ---
 title: "Batch jobs"
 description: "Submit large collections of inference requests as a single named batch, processed asynchronously."
 tag: BETA
 ---
 
 Use batch jobs to run large volumes of inference requests against a serverless endpoint without waiting for each result in real time. Batch jobs run asynchronously on dedicated workers that are separate from your endpoint's standard `/run` traffic, so submitting a batch never delays your interactive requests.
@@ -17,7 +17,7 @@
 | **Traffic isolation** | Dedicated batch workers | Standard serverless workers |
 | **Result delivery** | Poll or subscribe to notifications | Synchronous or async poll |
 
 Choose batch when your workload can tolerate multi-hour latency — for example, nightly dataset processing, pre-computing embeddings, or running evaluations.
 
 ## Batch lifecycle
 
@@ -28,12 +28,12 @@
                   → CANCELLED
 ```
 
 - **DRAFT** — The batch is a draft. You can add, update, or remove individual requests. Batch workers have not started any work.
 - **FINALIZED** — The batch is locked; no further requests can be added or removed. Batch workers process the requests while the batch stays in this state, and there is no separate `RUNNING` or `COMPLETED` batch status. Track progress through the `requestTotal`, `requestInProgress`, `requestCompleted`, and `requestFailed` counts — all requests have finished when `requestCompleted + requestFailed` equals `requestTotal`.
 - **FAILED** — The batch itself failed before or during execution (distinct from individual request failures in a batch whose other requests finished successfully).
 - **CANCELLED** — You cancelled the batch. See [Cancellation](#cancellation) for details.
 
 You must call `/finalize` before the batch begins processing. A DRAFT batch will not be executed.
 
 ## API walkthrough
 
@@ -45,7 +45,7 @@
 Content-Type: application/json
 ```
 
 The request body is a top-level JSON array. Send an empty array `[]` to create a batch and add requests later, or send a populated array to include an initial list of requests. Each element uses the same shape as a standard `/run` call — a JSON object with an `input` field.
 
 ```json
 [
@@ -65,7 +65,7 @@
 
 ### 2. Add more requests
 
 While the batch is DRAFT, append additional requests:
 
 ```bash
 POST /v2/{endpoint_id}/batch/{batch_id}/requests
@@ -83,7 +83,7 @@
 }
 ```
 
 Request body size is limited to 10 MiB per call. You can call this endpoint multiple times to build up large batches incrementally.
 
 ### 3. Finalize the batch
 
@@ -94,7 +94,7 @@
 Authorization: Bearer {api_key}
 ```
 
 After finalization, the batch status transitions to `FINALIZED` and requests are locked. You can no longer add or remove individual requests.
 
 ### 4. Poll batch status
 
@@ -120,7 +120,7 @@
 }
 ```
 
 Poll this endpoint at whatever interval suits your workflow. A batch that is still processing reports `status: FINALIZED`; there is no `RUNNING` or `COMPLETED` status. All requests have finished when `requestCompleted + requestFailed` equals `requestTotal`. The batch reaches a terminal state only when `status` is `FAILED` or `CANCELLED`. The `createdAt` field is a Unix epoch timestamp in milliseconds.
 
 ### 5. Retrieve results
 
@@ -158,23 +158,24 @@
 }
 ```
 
 The results are paginated. Pass the `offset` and `limit` query parameters to page through results. The `hasMore` field indicates whether more pages remain.
 
 ## Full API reference
 
 | Method | Path | Description |
 |--------|------|-------------|
 | `POST` | `/v2/{endpoint_id}/batch` | Create a new batch, optionally with initial requests |
 | `POST` | `/v2/{endpoint_id}/batch/{id}/requests` | Append requests to a DRAFT batch |
 | `POST` | `/v2/{endpoint_id}/batch/{id}/finalize` | Lock the batch and make it eligible for execution |
 | `PUT` | `/v2/{endpoint_id}/batch/{id}` | Update batch attributes (e.g. display name) |
 | `DELETE` | `/v2/{endpoint_id}/batch/{id}/requests/{requestId}` | Remove a single request from a DRAFT batch |
 | `GET` | `/v2/{endpoint_id}/batch` | List all batches for an endpoint, newest first |
 | `GET` | `/v2/{endpoint_id}/batch/{id}` | Batch summary with request counts |
 | `POST` | `/v2/{endpoint_id}/batch/{id}/cancel` | Cancel a batch |
 | `GET` | `/v2/{endpoint_id}/batch/{id}/requests` | Paginated child request list |
 
-For full request and response schemas, see the [API reference](/api-reference/endpoint/batch).
+{/* TODO: Restore the link once a batch endpoint reference page is published. */}
+For full request and response schemas, refer to the batch endpoint API reference.
 
 ## Monitoring batches in the console
 
@@ -186,16 +187,16 @@
 - Per-request rows with status, timestamps, and error messages for failed requests
 - Links to the full request detail view for each child request
 
 The child request list is sorted by failures first, then in-progress, then queued, then completed.
 
 ## Notifications
 
 When a batch reaches a terminal state (`FAILED` or `CANCELLED`), Runpod sends:
 
 - **Console Inbox notification** — includes batch ID, endpoint name, terminal status, and item counts (completed / failed / total)
 - **Webhook event** — if your account has a webhook subscription configured for batch events
 
 Notifications are sent once per terminal state transition and are not fired for intermediate progress.
 
 ## Cancellation
 
@@ -208,8 +209,8 @@
 
 Cancellation behavior:
 
 - **Queued requests** are cancelled immediately and are not billed.
 - **In-progress requests** are allowed to finish and are billed normally.
 
 The batch status transitions to `CANCELLED` once all in-progress work has drained.
 
@@ -225,19 +226,19 @@
 
 ## Billing
 
 Batch jobs are billed at the same rate as standard serverless requests on your endpoint. For enterprise customers, flex worker discounts apply to batch jobs. Billing is based on the compute time used by each child request, regardless of whether the batch was later cancelled (in-progress requests that completed before cancellation are billed normally).
 
 ## Error handling
 
 **Individual request failures** — A failed child request does not fail the entire batch. The batch stays `FINALIZED` and continues processing the remaining requests; overall completion is inferred from the request counts (all requests are done when `requestCompleted + requestFailed` equals `requestTotal`). Inspect failed requests via the console or the `GET .../requests` endpoint; each failed request includes an error message from the handler.
 
 **Batch-level failure** — If the batch itself fails (status `FAILED`), it indicates a systemic problem rather than individual handler errors. Contact support if you see this state and cannot explain it from request-level errors.
 
 **Redis durability** — Batch jobs use the same Redis-backed queue as standard serverless requests. In the event of a Redis failure, queued batch requests may be lost. This is an MVP limitation that applies equally to `/run` traffic.
 
 ## Known limitations
 
 - Batch jobs inherit the GPU type configured on your endpoint. You cannot specify a different GPU per batch or per request.
 - There is no per-request scheduling or ordering. Requests within a batch are processed in an unspecified order.
 - Cost estimation before finalization is not available at launch.
 - Runpod schedules batch workers based on global queue urgency and off-peak capacity, so start times aren't guaranteed.