trigger-cost-savings（触发成本节约）

Trigger.dev Cost Savings Analysis

Analyze task runs and configurations to find cost reduction opportunities.

Prerequisites: MCP Tools

This skill requires the Trigger.dev MCP server to analyze live run data.

Check MCP availability

Before analysis, verify these MCP tools are available:

• list_runs — list runs with filters (status, task, time period, machine size)
• get_run_details — get run logs, duration, and status
• get_current_worker — get registered tasks and their configurations

If these tools are not available, instruct the user:

To analyze your runs, you need the Trigger.dev MCP server installed.

Run this command to install it:

  npx trigger.dev@latest install-mcp

This launches an interactive wizard that configures the MCP server for your AI client.

Do NOT proceed with run analysis without MCP tools. You can still review source code for static issues (see Static Analysis below).

Load latest cost reduction documentation

Before giving recommendations, fetch the latest guidance:

WebFetch: https://trigger.dev/docs/how-to-reduce-your-spend

Use the fetched content to ensure recommendations are current. If the fetch fails, fall back to the reference documentation in references/cost-reduction.md.

Analysis Workflow

Step 1: Static Analysis (source code)

Scan task files in the project for these issues:

1. Oversized machines — tasks using large-1x or large-2x without clear need
2. Missing maxDuration — tasks without execution time limits (runaway cost risk)
3. Excessive retries — maxAttempts > 5 without AbortTaskRunError for known failures
4. Missing debounce — high-frequency triggers without debounce configuration
5. Missing idempotency — payment/critical tasks without idempotency keys
6. Polling instead of waits — setTimeout/setInterval/sleep loops instead of wait.for()
7. Short waits — wait.for() with < 5 seconds (not checkpointed, wastes compute)
8. Sequential instead of batch — multiple triggerAndWait() calls that could use batchTriggerAndWait()
9. Over-scheduled crons — schedules running more frequently than necessary

Step 2: Run Analysis (requires MCP tools)

Use MCP tools to analyze actual usage patterns:

2a. Identify expensive tasks

list_runs with filters:
- period: "30d" or "7d"
- Sort by duration or cost
- Check across different task IDs

Look for:

• Tasks with high total compute time (duration x run count)
• Tasks with high failure rates (wasted retries)
• Tasks running on large machines with short durations (over-provisioned)

2b. Analyze failure patterns

list_runs with status: "FAILED" or "CRASHED"

For high-failure tasks:

• Check if failures are retryable (transient) vs permanent
• Suggest AbortTaskRunError for known non-retryable errors
• Calculate wasted compute from failed retries

2c. Check machine utilization

get_run_details for sample runs of each task

Compare actual resource usage against machine preset:

• If a task on large-2x consistently runs in < 1 second, it's over-provisioned
• If tasks are I/O-bound (API calls, DB queries), they likely don't need large machines

2d. Review schedule frequency

get_current_worker to list scheduled tasks and their cron patterns

Flag schedules that may be too frequent for their purpose.

Step 3: Generate Recommendations

Present findings as a prioritized list with estimated impact:

## Cost Optimization Report

### High Impact
1. **Right-size `process-images` machine** — Currently `large-2x`, average run 2s.
   Switching to `small-2x` could reduce this task's cost by ~16x.

machine: { preset: "small-2x" } // was "large-2x"

### Medium Impact

1. **Add debounce to `sync-user-data`** — 847 runs/day, often triggered in bursts. `` debounce: {key: `user-${userId}`, delay: "5s"} ``

### Low Impact / Best Practices

1. **Add `maxDuration` to `generate-report`** — No timeout configured. `maxDuration: 300 // 5 minutes`

Machine Preset Costs (relative)

Larger machines cost proportionally more per second of compute:

Key Principles

• Waits > 5 seconds are free — checkpointed, no compute charge
• Start small, scale up — default small-1x is right for most tasks
• I/O-bound tasks don't need big machines — API calls, DB queries wait on network
• Debounce saves the most on high-frequency tasks — consolidates bursts into single runs
• Idempotency prevents duplicate work — especially important for expensive operations
• AbortTaskRunError stops wasteful retries — don't retry permanent failures

See references/cost-reduction.md for detailed strategies with code examples.