Muse Spark 1.3

Text Generation • Meta

meta/muse-spark-1.3

• Third-party

Muse Spark 1.3 is Meta's latest agentic and coding model, tuned for multi-step tool loops, browser tasks, software engineering, and long-horizon reasoning.

Usage

const response = await env.AI.run(
  'meta/muse-spark-1.3',
  {
    messages: [
      {
        role: 'system',
        content:
          'You are a principal engineer writing for a team that will implement the design. Be concrete, identify failure modes, and avoid unnecessary infrastructure.',
      },
      {
        role: 'user',
        content:
          'Design a multi-tenant webhook delivery service for a SaaS product. It must support signed webhooks, at-least-once delivery, exponential backoff, tenant-specific rate limits, and replay from an audit log. Provide: (1) a short component diagram in text, (2) the event state machine, (3) an idempotency strategy, and (4) three operational metrics with alert thresholds. Keep the proposal under 700 words.',
      },
    ],
    max_completion_tokens: 4096,
  },
)
console.log(response)

curl https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
  "model": "meta/muse-spark-1.3",
  "input": {
    "messages": [
      {
        "role": "system",
        "content": "You are a principal engineer writing for a team that will implement the design. Be concrete, identify failure modes, and avoid unnecessary infrastructure."
      },
      {
        "role": "user",
        "content": "Design a multi-tenant webhook delivery service for a SaaS product. It must support signed webhooks, at-least-once delivery, exponential backoff, tenant-specific rate limits, and replay from an audit log. Provide: (1) a short component diagram in text, (2) the event state machine, (3) an idempotency strategy, and (4) three operational metrics with alert thresholds. Keep the proposal under 700 words."
      }
    ],
    "max_completion_tokens": 4096
  }
}'

## Multi-tenant Webhook Delivery: Proposal

Goal: durable, at-least-once delivery without building streaming infra. Use **Postgres as source of truth + queue, stateless workers, Redis only for rate limiting.**

### 1. Component diagram (text)

```
Producer services -> [Ingest API] -> [Postgres: events, deliveries, audit_log]
                          |                    ^
[Tenant Control Plane: endpoints, secrets/KMS, rate limits] |
                          v                    | claim with SKIP LOCKED
[Replay API] --------> [Scheduler/Workers] -> [Redis Token Bucket per-tenant] -> [HTTPS Sender] -> Customer endpoint
                            |                          (respect Retry-After)
                            v
                       [DLQ + Metrics/Logs]
```

* **Ingest API:** validates, assigns `event_id (UUIDv7)`, writes event + first delivery row. Idempotent.
* **Postgres:** tables `webhook_events`, `deliveries`, `audit_log (append-only)`, `endpoints`. No Kafka needed until >2k rps sustained.
* **Workers:** poll due deliveries, HMAC-sign, POST with timeout (10s), handle retry scheduling.
* **Control Plane:** per-tenant endpoint URL, secret refs, `rate_per_min, burst, max_attempts, timeout`.

**Failure modes:** slow customer blocks worker threads -> use isolated worker pool + per-endpoint circuit breaker (open after 20 consecutive 5xx/timeouts, half-open after 5m). Poison event -> cap payload 256KB, max 12 attempts then DLQ. Redis loss -> fail-open with local in-memory limiter + alert, never fail-closed delivery. Replay storm -> replay is rate-limited like normal traffic.

### 2. Event state machine

One row per `(tenant_id, event_id, endpoint_id)`, `attempt_count` increments:

`PENDING -> QUEUED -> IN_FLIGHT -> DELIVERED (terminal)`
`IN_FLIGHT -> RETRY_WAIT -> QUEUED -> IN_FLIGHT ... -> DEAD_LETTER (terminal)`

Transitions:
* `PENDING->QUEUED`: ingest commit, `next_attempt_at=now()`.
* `QUEUED->IN_FLIGHT`: worker claims via `SELECT ... FOR UPDATE SKIP LOCKED`, sets `lease_until=now()+5m`.
* `IN_FLIGHT->DELIVERED`: receiver returns 2xx within timeout. Log to audit.
* `IN_FLIGHT->RETRY_WAIT`: timeout, 5xx, 429, network error. Set `next_attempt_at = now() + backoff`. Backoff: `min(30s * 2^attempt + jitter(0-10s), 6h)`, max 12 attempts over ~24h.
* `IN_FLIGHT->DEAD_LETTER`: 4xx except 408/429, or attempts exhausted, or HMAC misconfig. Require manual replay.
* Lease expiry: crashed worker -> `IN_FLIGHT` with expired lease returns to `QUEUED`.

### 3. Idempotency strategy

At-least-once means receivers **will** see duplicates. Make duplicates harmless:

1. **Inbound dedup:** Producer must send `Idempotency-Key: <event_id>`. DB has `UNIQUE(tenant_id, event_id)`. Retried ingest returns existing row, no new delivery.
2. **Stable identity downstream:** Payload immutable. Headers on every attempt:
`X-Webhook-Id: <event_id>, X-Delivery-Attempt: <n>, X-Webhook-Timestamp: <unix>, X-Webhook-Signature: v1=<hex>`
Signature: `HMAC_SHA256(endpoint_secret, timestamp + "." + event_id + "." + raw_body)`. Receivers dedup on `X-Webhook-Id` for 24h. Replays reuse same `event_id` with new `attempt_id` + `replay_of` audit ref, so customer dedup still works.
3. **Worker safety:** Side-effects only via single `deliver()` function guarded by `lease_owner`. Double-claim impossible due to row lock; duplicate send after crash is expected and safe due to (2).
4. **Secrets:** per-endpoint secret, encrypted with KMS, versioned `v1,v2` for rotation. Reject if timestamp skew >5m.

### 4. Operational metrics + alerts

1. **Delivery Success Rate (global + per-tenant):** `delivered / (delivered+dead_letter) over 10m`. Alert: `<99.5% global` or `<98% for any top-20 tenant` for 10m -> page. Indicates receiver outage or our bug.
2. **Oldest Undelivered Age / Queue Depth:** `now() - min(next_attempt_at) where state in (QUEUED, RETRY_WAIT)`. Alert: `age >15m OR depth >10k` for 5m -> page. Indicates worker stall, DB lock contention, or per-tenant limiter too strict.
3. **Dead-Letter Insertion Rate:** `rate(dead_letter_total[5m])`. Alert: `>10/min global OR spike 5x per-tenant vs 1h baseline` -> ticket + Slack to tenant owner. Indicates bad endpoint config, auth/4xx loop, signature failures.

Dashboards must be sliceable by `tenant_id, endpoint_id, status_code`.

{
  "id": "resp_6ac7acc41128bd4d6cd74cef",
  "object": "response",
  "created_at": 1791470788,
  "model": "muse-spark-1.3",
  "output": [
    {
      "type": "reasoning",
      "id": "rs_6ac7acc41128bd4d6cd74cef:rs_4c7f2910-34ff-4ac8-bc50-e03e60bc61b9",
      "summary": [],
      "status": "completed"
    },
    {
      "type": "message",
      "id": "msg_2783bcfa-5988-4878-9a6b-6a7edb9b3c07",
      "role": "assistant",
      "content": [
        {
          "type": "output_text",
          "text": "## Multi-tenant Webhook Delivery: Proposal\n\nGoal: durable, at-least-once delivery without building streaming infra. Use **Postgres as source of truth + queue, stateless workers, Redis only for rate limiting.**\n\n### 1. Component diagram (text)\n\n```\nProducer services -> [Ingest API] -> [Postgres: events, deliveries, audit_log]\n                          |                    ^\n[Tenant Control Plane: endpoints, secrets/KMS, rate limits] |\n                          v                    | claim with SKIP LOCKED\n[Replay API] --------> [Scheduler/Workers] -> [Redis Token Bucket per-tenant] -> [HTTPS Sender] -> Customer endpoint\n                            |                          (respect Retry-After)\n                            v\n                       [DLQ + Metrics/Logs]\n```\n\n* **Ingest API:** validates, assigns `event_id (UUIDv7)`, writes event + first delivery row. Idempotent.\n* **Postgres:** tables `webhook_events`, `deliveries`, `audit_log (append-only)`, `endpoints`. No Kafka needed until >2k rps sustained.\n* **Workers:** poll due deliveries, HMAC-sign, POST with timeout (10s), handle retry scheduling.\n* **Control Plane:** per-tenant endpoint URL, secret refs, `rate_per_min, burst, max_attempts, timeout`.\n\n**Failure modes:** slow customer blocks worker threads -> use isolated worker pool + per-endpoint circuit breaker (open after 20 consecutive 5xx/timeouts, half-open after 5m). Poison event -> cap payload 256KB, max 12 attempts then DLQ. Redis loss -> fail-open with local in-memory limiter + alert, never fail-closed delivery. Replay storm -> replay is rate-limited like normal traffic.\n\n### 2. Event state machine\n\nOne row per `(tenant_id, event_id, endpoint_id)`, `attempt_count` increments:\n\n`PENDING -> QUEUED -> IN_FLIGHT -> DELIVERED (terminal)`\n`IN_FLIGHT -> RETRY_WAIT -> QUEUED -> IN_FLIGHT ... -> DEAD_LETTER (terminal)`\n\nTransitions:\n* `PENDING->QUEUED`: ingest commit, `next_attempt_at=now()`.\n* `QUEUED->IN_FLIGHT`: worker claims via `SELECT ... FOR UPDATE SKIP LOCKED`, sets `lease_until=now()+5m`.\n* `IN_FLIGHT->DELIVERED`: receiver returns 2xx within timeout. Log to audit.\n* `IN_FLIGHT->RETRY_WAIT`: timeout, 5xx, 429, network error. Set `next_attempt_at = now() + backoff`. Backoff: `min(30s * 2^attempt + jitter(0-10s), 6h)`, max 12 attempts over ~24h.\n* `IN_FLIGHT->DEAD_LETTER`: 4xx except 408/429, or attempts exhausted, or HMAC misconfig. Require manual replay.\n* Lease expiry: crashed worker -> `IN_FLIGHT` with expired lease returns to `QUEUED`.\n\n### 3. Idempotency strategy\n\nAt-least-once means receivers **will** see duplicates. Make duplicates harmless:\n\n1. **Inbound dedup:** Producer must send `Idempotency-Key: <event_id>`. DB has `UNIQUE(tenant_id, event_id)`. Retried ingest returns existing row, no new delivery.\n2. **Stable identity downstream:** Payload immutable. Headers on every attempt:\n`X-Webhook-Id: <event_id>, X-Delivery-Attempt: <n>, X-Webhook-Timestamp: <unix>, X-Webhook-Signature: v1=<hex>`\nSignature: `HMAC_SHA256(endpoint_secret, timestamp + \".\" + event_id + \".\" + raw_body)`. Receivers dedup on `X-Webhook-Id` for 24h. Replays reuse same `event_id` with new `attempt_id` + `replay_of` audit ref, so customer dedup still works.\n3. **Worker safety:** Side-effects only via single `deliver()` function guarded by `lease_owner`. Double-claim impossible due to row lock; duplicate send after crash is expected and safe due to (2).\n4. **Secrets:** per-endpoint secret, encrypted with KMS, versioned `v1,v2` for rotation. Reject if timestamp skew >5m.\n\n### 4. Operational metrics + alerts\n\n1. **Delivery Success Rate (global + per-tenant):** `delivered / (delivered+dead_letter) over 10m`. Alert: `<99.5% global` or `<98% for any top-20 tenant` for 10m -> page. Indicates receiver outage or our bug.\n2. **Oldest Undelivered Age / Queue Depth:** `now() - min(next_attempt_at) where state in (QUEUED, RETRY_WAIT)`. Alert: `age >15m OR depth >10k` for 5m -> page. Indicates worker stall, DB lock contention, or per-tenant limiter too strict.\n3. **Dead-Letter Insertion Rate:** `rate(dead_letter_total[5m])`. Alert: `>10/min global OR spike 5x per-tenant vs 1h baseline` -> ticket + Slack to tenant owner. Indicates bad endpoint config, auth/4xx loop, signature failures.\n\nDashboards must be sliceable by `tenant_id, endpoint_id, status_code`.",
          "annotations": [],
          "logprobs": []
        }
      ],
      "status": "completed"
    }
  ],
  "status": "completed",
  "usage": {
    "input_tokens": 144,
    "output_tokens": 2443,
    "total_tokens": 2587,
    "input_tokens_details": {
      "cached_tokens": 0
    },
    "output_tokens_details": {
      "reasoning_tokens": 1306
    }
  },
  "top_logprobs": 0,
  "temperature": 1,
  "top_p": 1,
  "service_tier": "auto",
  "reasoning": {
    "effort": "high"
  },
  "background": false,
  "tools": [],
  "tool_choice": "auto",
  "truncation": "disabled",
  "completed_at": 1791470788,
  "error": null,
  "incomplete_details": null,
  "instructions": null,
  "parallel_tool_calls": true,
  "store": true,
  "max_output_tokens": 4096
}

Examples

<details>

<summary>OAuth Callback Threat Model — Threat-model an OAuth callback endpoint and prioritize concrete mitigations.</summary>

const response = await env.AI.run(
  'meta/muse-spark-1.3',
  {
    messages: [
      {
        role: 'system',
        content:
          'You are an application security engineer. Distinguish threats from mitigations and call out assumptions explicitly.',
      },
      {
        role: 'user',
        content:
          'Threat-model an OAuth callback at GET /oauth/callback?code=...&state=... for a multi-tenant SaaS app. The callback exchanges the code server-side, redirects to the tenant dashboard, and stores the resulting session in an HttpOnly cookie. List the five most important threats, their impact, and one mitigation for each. Include one test case for state validation and one for redirect validation.',
      },
    ],
    max_completion_tokens: 4096,
  },
)
console.log(response)

curl https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
  "model": "meta/muse-spark-1.3",
  "input": {
    "messages": [
      {
        "role": "system",
        "content": "You are an application security engineer. Distinguish threats from mitigations and call out assumptions explicitly."
      },
      {
        "role": "user",
        "content": "Threat-model an OAuth callback at GET /oauth/callback?code=...&state=... for a multi-tenant SaaS app. The callback exchanges the code server-side, redirects to the tenant dashboard, and stores the resulting session in an HttpOnly cookie. List the five most important threats, their impact, and one mitigation for each. Include one test case for state validation and one for redirect validation."
      }
    ],
    "max_completion_tokens": 4096
  }
}'