@mastra/mcp-docs-server 1.1.32 → 1.1.33-alpha.3

package/.docs/docs/observability/tracing/bridges/datadog.md

@@ -0,0 +1,217 @@
+# Datadog bridge
+
+> **Warning:** The Datadog Bridge is currently **experimental**. APIs and configuration options may change in future releases.
+
+The Datadog Bridge enables bidirectional integration between Mastra's tracing system and Datadog. Unlike exporters that send trace data after execution completes, the bridge creates native dd-trace spans in real time so that auto-instrumented APM operations (HTTP calls, database queries, etc.) inside your tools and processors are correctly nested under their parent Mastra spans.
+
+> **Not using dd-trace APM?:** If you only need to send LLM Observability data and don't use `dd-trace` APM auto-instrumentation, the [Datadog Exporter](https://mastra.ai/docs/observability/tracing/exporters/datadog) is simpler — it supports agentless mode and sends spans directly to Datadog without a local agent.
+
+## When to use the bridge
+
+Use the DatadogBridge when you:
+
+- Use `dd-trace` auto-instrumentation in your application (HTTP servers, database clients, etc.)
+- Want APM service calls made by tools, MCP tools, or output processors to appear under their parent Mastra span instead of the request handler
+- Need both APM traces and LLM Observability data to share a consistent trace topology
+- Are building a distributed system where Datadog trace context must propagate across services
+
+## How it works
+
+The DatadogBridge participates in two parts of the dd-trace pipeline:
+
+**APM context propagation (real time):**
+
+- Creates a dd-trace APM span via `tracer.startSpan()` when each Mastra span is created
+- Activates the APM span in dd-trace's scope via `tracer.scope().activate()` during execution
+- Auto-instrumented operations inside the active scope are parented to the correct Mastra span
+- Inherits the active dd-trace context (e.g., an incoming request span) when no explicit Mastra parent exists
+
+**LLM Observability emission (on span end):**
+
+- Emits annotations (model info, token usage, input/output, errors) through `dd-trace`'s LLM Observability pipeline
+- Maintains parent-child relationships in Datadog LLM Observability using nested `llmobs.trace()` calls
+- Reuses the same data shape and span-kind mapping as the [Datadog Exporter](https://mastra.ai/docs/observability/tracing/exporters/datadog)
+
+## Why this matters
+
+Without the bridge, the Datadog Exporter only creates LLM Observability spans after a trace completes. During execution, no `dd-trace` span is active in scope, so any HTTP or database call made by a tool falls back to whatever `dd-trace` span is active at the time — typically the incoming request handler. The result is that service calls from MCP tools or output processors appear as children of the request span instead of the agent or processor span that actually made them.
+
+The bridge fixes this by creating real dd-trace spans up front, so the scope is correct when auto-instrumentation runs.
+
+## Installation
+
+**npm**:
+
+```bash
+npm install @mastra/datadog dd-trace
+```
+
+**pnpm**:
+
+```bash
+pnpm add @mastra/datadog dd-trace
+```
+
+**Yarn**:
+
+```bash
+yarn add @mastra/datadog dd-trace
+```
+
+**Bun**:
+
+```bash
+bun add @mastra/datadog dd-trace
+```
+
+The bridge requires `dd-trace` to be installed and a local Datadog Agent (or compatible OTLP receiver) to receive APM data. See the [APM prerequisites](https://mastra.ai/docs/observability/tracing/exporters/datadog) on the exporter page for agent setup details.
+
+## Configuration
+
+Using the DatadogBridge requires two steps:
+
+1. Initialize `dd-trace` so its auto-instrumentation patches HTTP, database, and framework libraries
+2. Add the DatadogBridge to your Mastra observability config
+
+### Step 1: Initialize dd-trace
+
+`dd-trace` must be initialized before any other imports so its auto-instrumentation can patch libraries at load time. The bridge will detect an already-initialized tracer and reuse it.
+
+```typescript
+import tracer from 'dd-trace'
+
+tracer.init({
+  service: process.env.DD_SERVICE || 'my-mastra-app',
+  env: process.env.DD_ENV || 'production',
+  version: process.env.DD_VERSION,
+})
+
+import { Mastra } from '@mastra/core'
+import { Observability } from '@mastra/observability'
+import { DatadogBridge } from '@mastra/datadog'
+
+// ...
+```
+
+> **Note:** Import and initialize `dd-trace` at the very top of your application's entry file, before any other imports.
+
+### Step 2: Mastra Configuration
+
+Add the DatadogBridge to your Mastra observability config:
+
+```typescript
+export const mastra = new Mastra({
+  observability: new Observability({
+    configs: {
+      default: {
+        serviceName: 'my-mastra-app',
+        bridge: new DatadogBridge({
+          mlApp: process.env.DD_LLMOBS_ML_APP!,
+        }),
+      },
+    },
+  }),
+  bundler: {
+    externals: [
+      'dd-trace',
+      '@datadog/native-metrics',
+      '@datadog/native-appsec',
+      '@datadog/native-iast-taint-tracking',
+      '@datadog/pprof',
+    ],
+  },
+})
+```
+
+```bash
+DD_SERVICE=my-mastra-app
+DD_ENV=production
+DD_VERSION=1.0.0
+DD_LLMOBS_ML_APP=my-llm-app
+```
+
+When `dd-trace` is initialized, it routes APM data to your local Datadog Agent on `localhost:8126`. The bridge enables LLM Observability on top of the same tracer, so both sets of data appear under the same service in Datadog.
+
+No Mastra exporters are required when using the bridge — both APM and LLM Observability data flow through `dd-trace`. You can still add Mastra exporters if you want to send traces to additional destinations.
+
+## Agent vs. agentless mode
+
+The bridge defaults to **agent mode** (`agentless: false`). This assumes a local Datadog Agent is running on `localhost:8126` to receive both APM and LLM Observability data. This is the typical setup when using `dd-trace` auto-instrumentation, since APM data always routes through the agent.
+
+If you don't have a local Datadog Agent and only need LLM Observability data (no APM auto-instrumentation), you can enable agentless mode to send data directly to Datadog. In this case, you must provide an API key.
+
+```typescript
+new DatadogBridge({
+  mlApp: process.env.DD_LLMOBS_ML_APP!,
+  apiKey: process.env.DD_API_KEY!,
+  agentless: true,
+})
+```
+
+> **Note:** For most bridge users, agent mode is the right choice. APM data cannot be sent in agentless mode, so enabling agentless splits LLM Observability traffic away from APM traffic. If you want LLM Observability only without an agent, use the [Datadog Exporter](https://mastra.ai/docs/observability/tracing/exporters/datadog) instead.
+
+## Trace hierarchy
+
+With the DatadogBridge, your traces maintain proper hierarchy across dd-trace and Mastra boundaries. Service calls made by tools and processors appear under the correct Mastra span:
+
+```text
+HTTP POST /api/chat (from web framework instrumentation)
+└── agent.orchestrator (from Mastra via DatadogBridge)
+    ├── chat gpt-5.4 (LLM call)
+    ├── tool.execute search (tool execution)
+    │   └── HTTP GET api.example.com (auto-instrumented from inside the tool)
+    └── processor.guardrail (output processor)
+        └── HTTP POST guardrail-service/check (auto-instrumented from inside the processor)
+```
+
+In Datadog, the APM trace shows this full topology, and the LLM Observability product shows the agent and LLM-specific spans with their inputs, outputs, and token metrics.
+
+## Span type mapping
+
+The bridge uses the same span-kind mapping as the Datadog Exporter for LLM Observability. See [span type mapping](https://mastra.ai/docs/observability/tracing/exporters/datadog) on the exporter page.
+
+## Using tags
+
+Tags help you categorize and filter traces in Datadog. Add tags when executing agents or workflows:
+
+```typescript
+const result = await agent.generate('Hello', {
+  tracingOptions: {
+    tags: ['production', 'experiment-v2', 'user-request'],
+  },
+})
+```
+
+Tags formatted as `key:value` (e.g., `instance_name:career-scout-api`) are split into structured tag entries; tags without a colon are set with a `true` value.
+
+## Promoting context keys to flat tags
+
+Use `requestContextKeys` to promote specific keys from the request context or span attributes into flat, indexable LLM Observability tags. This makes them filterable in the Datadog UI:
+
+```typescript
+new DatadogBridge({
+  mlApp: process.env.DD_LLMOBS_ML_APP!,
+  requestContextKeys: ['tenantId', 'agentId'],
+})
+```
+
+Promoted keys are removed from `annotations.metadata` and added as flat tags on each LLM Observability span.
+
+## Troubleshooting
+
+If APM spans aren't connecting to Mastra spans as expected:
+
+- Verify `dd-trace` is initialized **before** any other imports (it patches libraries at load time)
+- Verify a local Datadog Agent is running and reachable at `localhost:8126`
+- Ensure the DatadogBridge is set as `bridge` (not as an entry in `exporters`) in your observability config
+- Confirm you haven't also added the `DatadogExporter` to `exporters` — using both will double-emit LLM Observability data
+
+For native-module compatibility issues with `dd-trace` and bundler externals, see the [Datadog exporter troubleshooting](https://mastra.ai/docs/observability/tracing/exporters/datadog) section.
+
+## Related
+
+- [Tracing Overview](https://mastra.ai/docs/observability/tracing/overview)
+- [Datadog Exporter](https://mastra.ai/docs/observability/tracing/exporters/datadog) - LLM Observability only, no `dd-trace` APM
+- [DatadogBridge Reference](https://mastra.ai/reference/observability/tracing/bridges/datadog) - API documentation
+- [Datadog APM documentation](https://docs.datadoghq.com/tracing/)
+- [Datadog LLM Observability documentation](https://docs.datadoghq.com/llm_observability/)

package/.docs/docs/observability/tracing/exporters/datadog.md

@@ -2,6 +2,8 @@
 
 [Datadog](https://datadoghq.com/) is a comprehensive monitoring platform with dedicated LLM Observability features. The Datadog exporter sends your traces to Datadog's LLM Observability product, providing insights into model performance, token usage, and conversation flows.
 
+> **Also using dd-trace APM?:** If you also use `dd-trace` APM auto-instrumentation, consider the [Datadog Bridge](https://mastra.ai/docs/observability/tracing/bridges/datadog) instead. The bridge creates `dd-trace` spans in real time so HTTP and database calls inside tools and processors are correctly nested under their parent Mastra span. The exporter on its own sends LLM Observability data after execution completes, which means auto-instrumented APM spans fall back to the request handler.
+
 ## Installation
 
 **npm**:
@@ -130,7 +132,7 @@ Note: When using agent mode, the API key is read from the local agent's configur
 
 ## Span type mapping
 
-Mastra span types are automatically mapped to Datadog LLMObs span kinds:
+Mastra span types are automatically mapped to Datadog LLM Observability span kinds:
 
 | Mastra SpanType      | Datadog Kind |
 | -------------------- | ------------ |

package/.docs/docs/workflows/scheduled-workflows.md

@@ -0,0 +1,181 @@
+# Scheduled workflows
+
+Declare a `schedule` field on a workflow and Mastra will fire it on the cron you specify. The same workflow remains callable directly with `workflow.start()` — scheduled fires and manual runs share a single execution path.
+
+## Quickstart
+
+The following workflow runs every day at 9am New York time. Register it on `Mastra` as you would any other workflow — the scheduler picks it up automatically.
+
+```typescript
+import { createWorkflow, createStep } from '@mastra/core/workflows'
+import { z } from 'zod'
+
+const sendReport = createStep({
+  id: 'send-report',
+  inputSchema: z.object({ userId: z.string() }),
+  outputSchema: z.object({ ok: z.boolean() }),
+  execute: async ({ inputData }) => {
+    // ...send the report for inputData.userId
+    return { ok: true }
+  },
+})
+
+export const dailyReport = createWorkflow({
+  id: 'daily-report',
+  inputSchema: z.object({ userId: z.string() }),
+  outputSchema: z.object({ ok: z.boolean() }),
+  schedule: {
+    cron: '0 9 * * *',
+    timezone: 'America/New_York',
+    inputData: { userId: 'system' },
+  },
+})
+  .then(sendReport)
+  .commit()
+```
+
+There is no separate "register schedule" call. The scheduler reads `schedule` straight off the workflow when `Mastra` boots.
+
+## What `schedule` changes
+
+A workflow that declares `schedule` is auto-promoted to the **evented execution engine**. The public API (`workflow.start()`, `workflow.startAsync()`, `streamLegacy()`, `resume()`) is unchanged — `EventedWorkflow extends Workflow` and overrides each method with matching signatures. From your code, scheduled fires and manual runs are indistinguishable.
+
+The promotion has one practical implication: evented runs require a storage adapter that supports concurrent updates, for example `@mastra/libsql`. If your adapter does not, `createRun()` throws a clear error pointing at the `schedule` field. Switch adapters or remove the schedule.
+
+## Single schedule
+
+Pass an object to `schedule` for a workflow that fires on one cadence:
+
+```typescript
+const dailyReport = createWorkflow({
+  id: 'daily-report',
+  schedule: {
+    cron: '0 9 * * *',
+    timezone: 'America/New_York',
+    inputData: { userId: 'system' },
+  },
+  // ...
+})
+```
+
+Fields:
+
+- `cron` (required): a 5-, 6-, or 7-part cron expression. Validated at workflow construction time.
+- `timezone` (optional): IANA timezone, for example `America/New_York`. Defaults to the host's local timezone. Set this explicitly in production so fire times do not depend on server locale.
+- `inputData` (optional): payload passed as the workflow's input on every fire.
+- `initialState` (optional): initial state for the run.
+- `requestContext` (optional): request context attached to the run.
+- `metadata` (optional): arbitrary metadata persisted alongside the schedule row.
+
+## Multiple schedules
+
+Pass an array to fire the same workflow on multiple cadences. Each entry needs a unique stable `id`:
+
+```typescript
+const heartbeat = createWorkflow({
+  id: 'heartbeat',
+  schedule: [
+    { id: 'morning', cron: '0 9 * * *', inputData: { window: 'morning' } },
+    { id: 'evening', cron: '0 18 * * *', inputData: { window: 'evening' } },
+  ],
+  // ...
+})
+```
+
+Each entry creates an independent schedule row, fires on its own cron, and shows up separately in the Studio Schedules view.
+
+## Viewing schedules in Studio
+
+Studio surfaces schedules as a top-level area, not as a tab inside a workflow:
+
+- **All schedules**: open `/workflows/schedules` for a cross-workflow list. Each row shows the workflow id, cron, next fire, and the most recent run's status, so the list answers "is anything broken?" at a glance.
+- **Filtered by workflow**: append `?workflowId=<id>` to scope the list to a single workflow, for example `/workflows/schedules?workflowId=daily-report`.
+- **Schedule detail**: select any row to open `/workflows/schedules/:scheduleId`, which shows the schedule's metadata, **Pause** / **Resume** controls, and the full trigger history.
+
+A workflow's header includes a **Schedules** action when the workflow has at least one schedule:
+
+- One schedule: the action links straight to that schedule's detail page.
+- Multiple schedules: the action links to the workflow-filtered list at `/workflows/schedules?workflowId=<id>`.
+- No schedules: the action is hidden.
+
+### Trigger history
+
+Every fire records a trigger row with the run id, scheduled time, actual fire time, and publish status. The schedule detail page joins each trigger to the corresponding workflow run and shows:
+
+- The run's status (`running`, `success`, `failed`, `suspended`, `canceled`) as a badge.
+- The run's start time and duration.
+- A link to the run's full graph view at `/workflows/:workflowId/graph/:runId`.
+- A `pending` badge for triggers whose run record has not been written yet, due to a race between trigger publish and run snapshot.
+- A `publish failed` badge with the publish error when the scheduler could not enqueue the run at all.
+
+Triggers in a non-terminal state cause the panel to poll every five seconds until they reach a terminal state. The list paginates, so long-running schedules do not load thousands of rows up front.
+
+## Pausing a schedule at runtime
+
+When a scheduled workflow misfires in production, you do not have to redeploy or hand-edit the database. Pause it from the SDK:
+
+```typescript
+import { MastraClient } from '@mastra/client-js'
+
+const client = new MastraClient({ baseUrl: 'http://localhost:4111' })
+
+// Schedule ids are derived from the workflow id: `wf_<workflowId>` for a
+// single declarative schedule, or `wf_<workflowId>__<scheduleId>` when you
+// declare multiple schedules per workflow as an array.
+await client.pauseSchedule('wf_daily-report')
+// ...investigate, ship a fix, then:
+await client.resumeSchedule('wf_daily-report')
+```
+
+In Studio, open the schedule detail page and select **Pause** or **Resume** in the header.
+
+A few rules worth knowing:
+
+- Pause is durable. The status is written to the schedules table and survives process restarts and redeploys. The declarative-config upsert never overwrites a user-set status, even when you change `cron`, `timezone`, or other fields.
+- Resume recomputes `nextFireAt` from now. A schedule paused for a week does not fire seven backlogged runs the moment you resume it. It fires on the next regular cron tick.
+- The only way to unpause is `resumeSchedule` (or the **Resume** button in Studio). Editing the workflow's `schedule` config does not unpause a paused row.
+- Pause and resume are idempotent. Calling pause on an already-paused schedule is a no-op.
+- This is an operational override, not a way to author schedules. Creating, deleting, and editing schedules still happens in code via the `schedule` field on `createWorkflow`.
+
+The underlying HTTP routes are `POST /api/schedules/:scheduleId/pause` and `POST /api/schedules/:scheduleId/resume`. Both require the `schedules:write` permission.
+
+## Redeploying with changes
+
+When you change the `schedule` config and redeploy, Mastra diffs the existing schedule row against the new config:
+
+- If `cron` or `timezone` changed, `nextFireAt` is recomputed.
+- If only `inputData`, `initialState`, or `metadata` changed, the row is patched in place and the next fire time is preserved.
+- User-set status (for example, paused via `client.pauseSchedule`) and fire history are never overwritten.
+
+Removing a schedule entry from a workflow's `schedule` array deletes its row on the next boot.
+
+## Deployment topology
+
+The built-in scheduler is a `setInterval` tick loop that polls the schedules table, claims due rows, and dispatches workflow runs through the in-process pubsub. It assumes a long-lived host process.
+
+### Long-lived host (recommended)
+
+Deploy targets such as Fly Machines, Railway, Render, AWS ECS, GKE, or your own server keep the Mastra process alive between cron ticks. Schedules work without extra setup.
+
+### Serverless platforms
+
+Functions-as-a-service platforms such as Vercel, Netlify, AWS Lambda, and Cloudflare Workers shut the process down after each request. The tick loop never gets a second tick. Schedules declared in code do not fire on these platforms with the built-in scheduler today.
+
+On these platforms, use [`@mastra/inngest`](#inngest-workflows) instead. Inngest is serverless-native and holds the cron state for you.
+
+## Inngest workflows
+
+The `schedule` field documented on this page drives Mastra's built-in scheduler. If you use `@mastra/inngest`, scheduled workflows are configured through Inngest's own `cron` field on `createFunction` and fire on Inngest's scheduler instead.
+
+Practical implications:
+
+- Inngest schedules do not appear in Studio's `/workflows/schedules` view.
+- The workflow header **Schedules** action does not show for Inngest workflows.
+- `client.pauseSchedule` and `client.resumeSchedule` do not control Inngest schedules.
+
+Manage Inngest schedules from the [Inngest dashboard](https://www.inngest.com/docs/guides/scheduled-functions). Use Mastra schedules when you want Mastra to own scheduling end to end.
+
+## Related
+
+- [Workflow overview](https://mastra.ai/docs/workflows/overview)
+- [Suspend and resume](https://mastra.ai/docs/workflows/suspend-and-resume)

package/.docs/models/gateways/openrouter.md

@@ -1,6 +1,6 @@
 # ![OpenRouter logo](https://models.dev/logos/openrouter.svg)OpenRouter
 
-OpenRouter aggregates models from multiple providers with enhanced features like rate limiting and failover. Access 181 models through Mastra's model router.
+OpenRouter aggregates models from multiple providers with enhanced features like rate limiting and failover. Access 182 models through Mastra's model router.
 
 Learn more in the [OpenRouter documentation](https://openrouter.ai/models).
 
@@ -166,6 +166,7 @@ ANTHROPIC_API_KEY=ant-...
 | `openai/o4-mini`                                                |
 | `openrouter/elephant-alpha`                                     |
 | `openrouter/free`                                               |
+| `openrouter/owl-alpha`                                          |
 | `openrouter/pareto-code`                                        |
 | `prime-intellect/intellect-3`                                   |
 | `qwen/qwen-2.5-coder-32b-instruct`                              |

package/.docs/models/gateways/vercel.md

@@ -1,6 +1,6 @@
 # ![Vercel logo](https://models.dev/logos/vercel.svg)Vercel
 
-Vercel aggregates models from multiple providers with enhanced features like rate limiting and failover. Access 240 models through Mastra's model router.
+Vercel aggregates models from multiple providers with enhanced features like rate limiting and failover. Access 246 models through Mastra's model router.
 
 Learn more in the [Vercel documentation](https://ai-sdk.dev/providers/ai-sdk-providers).
 
@@ -52,10 +52,12 @@ ANTHROPIC_API_KEY=ant-...
 | `alibaba/qwen3-max-thinking`                   |
 | `alibaba/qwen3-next-80b-a3b-instruct`          |
 | `alibaba/qwen3-next-80b-a3b-thinking`          |
+| `alibaba/qwen3-vl-235b-a22b-instruct`          |
 | `alibaba/qwen3-vl-instruct`                    |
 | `alibaba/qwen3-vl-thinking`                    |
 | `alibaba/qwen3.5-flash`                        |
 | `alibaba/qwen3.5-plus`                         |
+| `alibaba/qwen3.6-27b`                          |
 | `alibaba/qwen3.6-plus`                         |
 | `amazon/nova-2-lite`                           |
 | `amazon/nova-lite`                             |
@@ -123,6 +125,7 @@ ANTHROPIC_API_KEY=ant-...
 | `google/text-embedding-005`                    |
 | `google/text-multilingual-embedding-002`       |
 | `inception/mercury-2`                          |
+| `inception/mercury-coder-small`                |
 | `inception/mercury-edit-2`                     |
 | `interfaze/interfaze-beta`                     |
 | `kwaipilot/kat-coder-pro-v1`                   |
@@ -256,11 +259,14 @@ ANTHROPIC_API_KEY=ant-...
 | `xai/grok-4.20-non-reasoning-beta`             |
 | `xai/grok-4.20-reasoning`                      |
 | `xai/grok-4.20-reasoning-beta`                 |
+| `xai/grok-4.3`                                 |
 | `xai/grok-code-fast-1`                         |
 | `xai/grok-imagine-image`                       |
 | `xai/grok-imagine-image-pro`                   |
 | `xiaomi/mimo-v2-flash`                         |
 | `xiaomi/mimo-v2-pro`                           |
+| `xiaomi/mimo-v2.5`                             |
+| `xiaomi/mimo-v2.5-pro`                         |
 | `zai/glm-4.5`                                  |
 | `zai/glm-4.5-air`                              |
 | `zai/glm-4.5v`                                 |

package/.docs/models/index.md

@@ -1,6 +1,6 @@
 # Model Providers
 
-Mastra provides a unified interface for working with LLMs across multiple providers, giving you access to 3803 models from 106 providers through a single API.
+Mastra provides a unified interface for working with LLMs across multiple providers, giving you access to 3832 models from 106 providers through a single API.
 
 ## Features
 

package/.docs/models/providers/cortecs.md

@@ -1,6 +1,6 @@
 # ![Cortecs logo](https://models.dev/logos/cortecs.svg)Cortecs
 
-Access 34 Cortecs models through Mastra's model router. Authentication is handled automatically using the `CORTECS_API_KEY` environment variable.
+Access 35 Cortecs models through Mastra's model router. Authentication is handled automatically using the `CORTECS_API_KEY` environment variable.
 
 Learn more in the [Cortecs documentation](https://cortecs.ai).
 
@@ -64,6 +64,7 @@ for await (const chunk of stream) {
 | `cortecs/minimax-m2.5`                   | 197K    |       |           |       |       |       | $0.32      | $1          |
 | `cortecs/minimax-m2.7`                   | 203K    |       |           |       |       |       | $0.47      | $1          |
 | `cortecs/nova-pro-v1`                    | 300K    |       |           |       |       |       | $1         | $4          |
+| `cortecs/qwen-2.5-72b-instruct`          | 33K     |       |           |       |       |       | $0.06      | $0.23       |
 | `cortecs/qwen3-32b`                      | 16K     |       |           |       |       |       | $0.10      | $0.33       |
 | `cortecs/qwen3-coder-480b-a35b-instruct` | 262K    |       |           |       |       |       | $0.44      | $2          |
 | `cortecs/qwen3-coder-next`               | 256K    |       |           |       |       |       | $0.16      | $0.84       |

package/.docs/models/providers/digitalocean.md

@@ -1,6 +1,6 @@
 # ![DigitalOcean logo](https://models.dev/logos/digitalocean.svg)DigitalOcean
 
-Access 62 DigitalOcean models through Mastra's model router. Authentication is handled automatically using the `DIGITALOCEAN_ACCESS_TOKEN` environment variable.
+Access 63 DigitalOcean models through Mastra's model router. Authentication is handled automatically using the `DIGITALOCEAN_ACCESS_TOKEN` environment variable.
 
 Learn more in the [DigitalOcean documentation](https://docs.digitalocean.com/products/gradient-ai-platform/details/models/).
 
@@ -50,6 +50,7 @@ for await (const chunk of stream) {
 | `digitalocean/bge-reranker-v2-m3`                    | 8K      |       |           |       |       |       | $0.01      | —           |
 | `digitalocean/deepseek-3.2`                          | 128K    |       |           |       |       |       | $0.50      | $2          |
 | `digitalocean/deepseek-r1-distill-llama-70b`         | 131K    |       |           |       |       |       | $0.99      | $0.99       |
+| `digitalocean/deepseek-v4-pro`                       | 1.0M    |       |           |       |       |       | $2         | $3          |
 | `digitalocean/e5-large-v2`                           | 512     |       |           |       |       |       | $0.02      | —           |
 | `digitalocean/fal-ai/elevenlabs/tts/multilingual-v2` | —       |       |           |       |       |       | —          | —           |
 | `digitalocean/fal-ai/fast-sdxl`                      | —       |       |           |       |       |       | —          | —           |