Evidence-Based Runway Credit Optimization

Overview

Runway pricing changes independently of models and code. Cost tuning begins from the current pricing page and authorized usage data, then removes accidental duplicates, rejected work, oversized outputs, unnecessary variants, and poor routing without lowering an approved quality or safety bar.

Prerequisites

• Current first-party pricing and organization usage evidence
• Operation, task, model, duration, output-count, state, and credit records
• A product-owned quality policy and finance-approved budget

Instructions

Step 1: Freeze the authority

Record retrieval time and fingerprint for the current pricing page, billing model, organization tier, and contract exceptions. Do not copy a historical credit table into a long-lived calculator.

Step 2: Reconcile demand to tasks

Join internal operation IDs to provider task IDs and usage. Separate successful, failed, moderated, cancelled, duplicate, abandoned, and stored outputs; account for safety failures that still consume credits.

Step 3: Find duplicate generation

Identify timeouts, client retries, queue resubmission, race conditions, and lost task IDs. Fix persistence and recovery before trading away output quality.

Step 4: Compare eligible policies

For each workload, compare approved direct models or Model Router configurations on current estimated credits, latency, and quality. Use router dryRun where supported because it returns selection and estimated cost without generating an asset.

Step 5: Control request shape

Review duration, resolution, output count, reference count, recipe choice, and retries against the product requirement. Reduce only fields that do not violate the approved result.

Step 6: Roll out with guardrails

Set per-operation and rolling budgets, alerts, concurrency locks, and automatic stop conditions. Compare credits per accepted asset and quality escape rate before expanding.

Authentication

Use minimally scoped server-side API and authorized organization usage access. Finance exports should contain aggregate identifiers and credits, not API keys, customer media, prompts, or signed output URLs.

Tool Discipline

Use Read and Grep to inspect application configuration, provider documentation, lockfiles, fixtures, schemas, tests, and redacted operational evidence before proposing a change. Use Write or Edit only for an approved implementation, configuration, test, runbook, or redacted receipt. Do not create, cancel, delete, retry, deploy, rotate, revoke, publish, or otherwise mutate production Runway resources without explicit operator approval.

Output

• Pricing and usage authority snapshot
• Measured credit drivers, duplicate waste, and policy scenarios
• Approved change with before/after credits, quality, latency, and rollback evidence

Return the environment, organization alias, operation and task identifiers, API and SDK versions, model or router policy, source-contract fingerprint, task-state evidence, credit boundary, output disposition, unresolved risk, rollback state, and final decision without exposing API secrets, prompt or media contents, or temporary signed URLs.

Examples

The review finds workers resubmit THROTTLED tasks. Persisting task IDs and waiting on the existing jobs removes duplicate spend; a router dry run then identifies a lower-cost eligible model for draft previews without changing final-render policy.

Error Handling

Validation

Reconcile sampled usage to task receipts, prove duplicate paths are closed, compare approved variants with blind quality review, and monitor credits per accepted asset through a reversible rollout.

Resources

• First-party source notes
• Runway agent context
• API reference
• Models
• Usage tiers
• Pricing
• Production checklist