Firefly Cost Optimization

Firefly Cost Optimization

The FinOps playbook for Firefly Services. Production deployments eventually get the question: "why is consumption 3× what we forecast?" The answer is almost always one of six causes, all of which are preventable with the patterns below.

This skill encodes how to think about Firefly cost: where it actually goes, what knobs reduce it, what the cost shape of each endpoint looks like, and the debugging sequence that resolves a consumption surprise in hours instead of weeks.

When to Use This Skill

Use this skill when:

• The user mentions "cost", "consumption", "credits", "API spend", "billing", "budget"
• Consumption is running ahead of forecast and you need to debug why
• A new pipeline is about to ship and the customer wants a cost forecast
• The architect is choosing between two patterns and cost is the tiebreaker (custom model vs style reference, generate vs cache, base vs custom model)
• The customer is renewing their Firefly enterprise contract and needs consumption justification

Do NOT use this skill when:

• The workload is low-volume interactive (a designer using the app) — cost optimization is premature
• The customer's spend is on Firefly-the-app (creative cloud subscription), not Firefly Services API — different cost model

Where Cost Actually Goes — The Five Buckets

API consumption breaks down into five buckets. Memorize the order — it tells you where to look first when consumption is high.

Bucket 2 is the variable. A healthy pipeline runs at 5%. A pipeline with bad retry logic and duplicate-generation bugs runs at 25%. The gap is the gap between forecast and reality.

Step 1 — Forecast Before You Build

Before any pipeline ships, forecast consumption. The formula:

monthly_credits = (
  active_campaigns_per_month *
  jobs_per_campaign *
  variants_per_job *
  aspects_per_variant
) * (1 + retry_overhead_pct) * (1 + rejection_overhead_pct)

Multiply the surprise values across the formula and you arrive at the 3-5× overrun that real pipelines hit. The forecast is a contract: the build team signs up for it, the FinOps team alarms when actual exceeds it.

Step 2 — Caching: The Highest-Leverage Lever

Three caches matter, in order of impact:

Cache 1: Prompt deduplication (per-campaign)

In a single campaign run, the same prompt is often submitted multiple times — by different upstream systems, retry logic, or accidental duplicates. A prompt-deduplication cache keyed on (promptHash, modelId, seeds, parameters) returns the prior output without calling Firefly.

const cacheKey = sha256(JSON.stringify({
  prompt: req.prompt,
  customModelId: req.customModelId,
  seeds: req.seeds,
  size: req.size,
  contentClass: req.contentClass,
  styleReference: req.style?.imageReference?.source?.uploadId,
  structureReference: req.structure?.imageReference?.source?.uploadId,
}));

const cached = await ddb.get({ TableName: 'firefly-prompt-cache', Key: { cacheKey } });
if (cached.Item) return cached.Item.outputUrls;

const result = await firefly.generate(req);
await ddb.put({ TableName: 'firefly-prompt-cache', Item: {
  cacheKey, outputUrls: result.outputs.map(o => o.image.url), ttl: ...
}});
return result.outputs.map(o => o.image.url);

Cache TTL: align with the validity of the Firefly output URLs. Adobe's pre-signed output URLs expire in one hour, so a cache that stores Adobe URLs must use a TTL of ≤ 1 hour — anything longer serves dead links. Re-hosting outputs in your own bucket (Cache 3) lets you cache indefinitely; that is the pattern that makes long-TTL deduplication worthwhile.

Typical hit rate: 5-15% on a campaign run, climbing to 25%+ in batch-driven workflows where duplicate prompts are common.

Cache 2: Token cache (per-credential)

The IMS token cache is covered in firefly-services-auth. It is not a cost lever directly, but a broken token cache means re-auth on every call, which can hammer rate limits and cause retry storms (which are a cost lever).

Token cache hit ratio < 99% means refresh logic is broken — fix before optimizing anything else.

Cache 3: Asset cache (post-generation)

Outputs cached in your own S3 (instead of re-fetching from Adobe's temporary URLs) saves bandwidth and avoids URL-expiry retries. Always re-host generated assets immediately.

Step 3 — Retry Storms: The #1 Cost Surprise

A retry storm happens when the pipeline retries calls that should not be retried. Patterns:

The retry classification table from firefly-services-rate-limits §5 is the canonical reference. The cost-specific extension:

Audit one week of DLQ contents. Any class that should not have been retried but was, multiplied by the average retry count, equals your retry-storm overhead.

Step 4 — Seed Reuse for Deterministic Regeneration

The seeds parameter on Generate Image (an array of 1-4 unique integers) biases generation toward a consistent composition. It does not guarantee byte-identical reproduction — a live check (2026-08-10) comparing two calls with identical prompt, seed, and size returned different image bytes. For cost control, seeds matter in two scenarios:

Without seed reuse, "make it slightly different" requires generating multiple new variants and picking. With seed reuse, one targeted generation often suffices.

{
  "prompt": "an icon of a key, brand-light style",
  "customModelId": "...",
  "seeds": [42],
  "size": {"width": 1024, "height": 1024}
}

When customModelId is set, the request must also send the x-model-version: image3_custom header — without it, the call runs against the base Firefly model, customModelId is ignored, and you still pay for an off-brand output (which then feeds the rejection-regeneration loop in §7 #4). See firefly-custom-models for the full invocation pattern.

Each output in the response carries the seed (singular) that produced it. Store that seed alongside every output asset in DynamoDB. When designers want a variation, the UI surfaces "regenerate with tweak" using the original seed.

Step 5 — Custom Model vs Style Reference: The Cost Tradeoff

Both produce on-brand output. The cost shapes are different.

* Credit consumption rates are plan- and feature-dependent and change over time — confirm current rates in the customer's Adobe enterprise agreement (see the compatibility note in this skill's frontmatter).

Break-even math: a custom model amortizes once you exceed ~hundreds of generations against the same style. Below that, style references are cheaper. Above that, the model wins — and as a bonus, the model is faster (no reference upload per call) and more consistent than reference-only.

See firefly-custom-models for the full lifecycle.

Step 6 — Right-Sizing Variants and Aspects

The variants and aspects multiply through every campaign. Be deliberate:

The single highest-impact change: keep numVariations at 1. Note the actual API default: numVariations defaults to the number of seeds passed, or 1 only when seeds is not specified. A request with seeds: [42, 43] generates 2 images — and bills 2 credits — even without numVariations in the body. Since Step 4 teaches passing seed arrays, keep them single-element unless you intend to pay per seed. Designers can request more if they need them — but watch for code or UI that quietly sets numVariations to 4 or passes multi-element seed arrays, which multiplies the credits before anyone notices.

Step 7 — The "Consumption is 3× Forecast" Debugging Sequence

When a customer reports overrun, work this sequence in order. Stop when you find the cause — usually one of the first three.

1. Check the retry rate

Query metrics for the past week:

Above the "concerning" thresholds, retry storm is the answer. Audit DLQ classification (§3).

2. Check for duplicate generations

In the job ledger, GROUP BY promptHash + customModelId + seed. If the same key has multiple succeeded jobs, idempotency is broken upstream.

-- Athena over the job ledger
SELECT promptHash, customModelId, seed, COUNT(*) as duplicate_count
FROM firefly_job_ledger
WHERE status = 'succeeded' AND createdAt > now() - INTERVAL '7' DAY
GROUP BY promptHash, customModelId, seed
HAVING COUNT(*) > 1
ORDER BY duplicate_count DESC LIMIT 100;

Duplicates × credits-per-duplicate = duplicate-generation overhead. Fix by enforcing idempotency keys at intake (see firefly-batch-pipeline §1).

3. Check variant and aspect counts

Audit the actual numVariations and aspect-count distributions across recent jobs. If numVariations >= 4 is the modal value, switch to default 1 and watch consumption drop.

4. Check rejection rate

If the human review queue (see firefly-brand-guardrails) is rejecting > 20% of output, the model or prompts are off-brand and the pipeline is regenerating to compensate. Retrain or tighten deny-lists.

5. Check for cache miss rate

Prompt deduplication cache hit rate should be in the 5-15% range. Below 5% means either the cache is broken (check TTLs and key construction), or the workload genuinely has no duplicates (which is fine).

6. Check for unused custom models

Models that were trained for an exploration and never retired still incur training charges. Audit the model registry quarterly; delete models that have not been called in 60 days.

Step 8 — Cost Observability — Dashboards to Build

Per-customer cost allocation uses S3 object tags (see firefly-batch-pipeline §6). Roll up to a daily / weekly / monthly customer invoice.

Validate

The cost layer is production-ready when:

1. Every campaign has a documented monthly forecast and an alarm at 150% of forecast
2. The retry-rate and duplicate-rate metrics are dashboarded with alarms
3. Idempotency keys are enforced at intake (no duplicate generations from upstream retries)
4. Prompt-dedup cache exists with measured hit rate
5. The DLQ classification rules in §3 are wired (no retry on 422 / 403 / 404)
6. numVariations defaults to 1; designers opt in to more
7. Custom-model registry is audited quarterly; unused models are deleted
8. The 7 dashboards above exist

Troubleshooting & Edge Cases

• Forecast looks healthy but invoices are 2× expected: The forecast omitted a category. Check Photoshop / Lightroom / Custom Model training charges — they bill separately and are often missed.
• One credential burning 5× the others: Either one customer is doing legitimate high-volume work, or one credential leaked and is being abused. Rotate and audit.
• Cache hit rate dropped after a deploy: Cache key construction broke — a new parameter changes the hash. Audit cache key vs request shape.
• Retry overhead climbed without a code change: Firefly-side incident is in progress. Check the Adobe status page; throttle the pipeline until it clears.
• Custom-model generation is consistently slow + expensive: The model is poorly trained; high seed-to-seed variance forces designers to regenerate. Retrain with better data.
• Reviewers reject everything from a new template: Template is off-brand. Pull from production; iterate; do not just "regenerate until it lands" — every regeneration burns credits.
• Bandwidth charges from re-fetching Firefly outputs: Outputs are at temporary URLs that expire. Re-host in your bucket immediately after generation success.

Chaining with Other Skills

• firefly-services-rate-limits — Retry classification is the cost-burn cornerstone
• firefly-batch-pipeline — Idempotency, job ledger, and observability live there
• firefly-brand-guardrails — Rejection rate is a direct cost driver
• firefly-custom-models — Cost vs style-reference tradeoff
• firefly-services-auth — Token cache health affects retry rate
• firefly-services-troubleshoot — When a single failure mode dominates burn

References

• Firefly API Technical Usage Notes — Consumption
• Firefly Custom Models Overview
• AWS Architecture: Exponential Backoff and Jitter
• FinOps Foundation — Cloud cost framework