I've been analyzing our team's usage patterns across our data stack for the past quarter, and a concerning trend emerged when I isolated the API calls and credit consumption for our HeyGen subscription. The core issue, from an analytics engineering perspective, is that the current per-credit pricing structure creates a significant disincentive for iterative development and robust testing—cornerstones of any reliable data pipeline. This isn't just a cost complaint; it's a fundamental friction against achieving high-quality output.
Let me illustrate with a concrete workflow. Developing a new product explainer video involves:
* **Iteration on script:** Each text-to-speech generation to check pacing and tone consumes credits.
* **Avatar and voice testing:** Experimenting with different presenter avatars and voice combinations to find the optimal fit is a multi-credit process per attempt.
* **Scene and template adjustments:** Minor tweaks to visuals or templates often require regenerating entire scenes.
In a typical data pipeline, we'd run a model dozens of times with different parameters, validating output at each stage, before promoting it to production. The marginal cost of each test run is effectively zero. With HeyGen, the cost is direct and accruing. This forces a "right-first-time" mentality that is antithetical to creative or systematic experimentation. Our data shows a 40% drop in experimental variants created per project after the first month, not due to mastery, but due to budget conservation.
Consider the analogy to our dbt projects. We would never accept a scenario where executing `dbt run --select my_model` incurred a per-run fee. It would cripple our development cycle. The optimal pricing for a tool that demands iteration should be based on **output volume** or **feature tiers**, not on the **input attempts**. A model that charges for the journey, not just the destination, inherently punishes the process required to reach a quality destination.
I'd be very interested to see if others have quantified this. Have you tracked your credit burn rate versus finalized video output? My preliminary SQL query on our log data (anonymized) looks something like this:
```sql
WITH usage_agg AS (
SELECT
DATE_TRUNC('week', call_timestamp) AS week,
project_id,
SUM(CASE WHEN call_status = 'experimental' THEN credit_cost ELSE 0 END) AS experimental_credits,
SUM(CASE WHEN call_status = 'final' THEN credit_cost ELSE 0 END) AS final_output_credits,
COUNT(DISTINCT CASE WHEN call_status = 'final' THEN asset_id END) AS final_assets_produced
FROM heygen_api_logs
GROUP BY 1, 2
)
SELECT
week,
SUM(experimental_credits) AS total_experimental_spend,
SUM(final_output_credits) AS total_final_spend,
SUM(final_assets_produced) AS total_assets,
-- Calculate the experimentation tax
ROUND(SUM(experimental_credits) * 100.0 / (SUM(experimental_credits) + SUM(final_output_credits)), 2) AS pct_credits_spent_on_experimentation
FROM usage_agg
GROUP BY 1
ORDER BY 1;
```
Our results show consistently over 30% of credits are consumed by experimental calls that do not yield a final asset. This is a substantial tax on the learning curve.
- dan
Garbage in, garbage out.