Alright, let's get into the weeds on this one. You're not building a website with static assets, you're building a deliverable that requires a generative AI component with a real, recurring operational cost. Treating Midjourney credits like a one-time software license is a great way to blow your project margin or have an awkward conversation with your client when the credits run out three-quarters of the way through.
The core problem is that clients see "AI image generation" as a magic box, not a consumable resource with a direct cost-per-unit. Your proposal needs to reframe it as infrastructure, because that's what it is. It's a utility, like compute time or cloud storage.
Here's how I structure it in a project SOW or proposal, breaking it down into clear, billable components.
**1. Isolate the Cost from Your Services Fee**
Never bundle the Midjourney cost into your hourly or project fee. It must be a separate, pass-through line item. This creates transparency and separates your expertise (prompt engineering, iteration, integration) from the raw material cost.
```yaml
Project Cost Breakdown:
- Service Fee (Design & Development): $X
- Software Licenses (Figma, etc.): $Y
- **AI Image Generation Infrastructure (Midjourney Credits):** $Z
- Contingency Buffer: $A
```
**2. Define the "Unit of Work" and Estimate Consumption**
This is the hardest part and requires some upfront scoping. You need to estimate usage. Be brutally conservative.
* Assume a **minimum** of 10-15 generations per final accepted image. This accounts for prompt refinement, variations, upscaling, and rerolls.
* Define what a "final image" is in the project context (e.g., "1 hero image," "5 product concept scenes").
* Build a simple table in the proposal.
| Deliverable | Estimated Final Images | Generations per Image (Avg) | Total Estimated Generations | Cost per Generation | **Estimated Credit Cost** |
| :--- | :--- | :--- | :--- | :--- | :--- |
| Hero Graphics | 3 | 12 | 36 | ~$0.10 | ~$36 |
| Concept Art | 10 | 15 | 150 | ~$0.10 | ~$150 |
| **Total** | | | **186** | | **~$186** |
**3. Include a Clear Provisioning and Management Clause**
This is your CYA (Cover Your Assets). You need clauses that state:
* The estimated credit cost is based on the scope defined above.
* The client will fund a dedicated Midjourney account or prepay for credit blocks.
* You will provide regular usage reports (screenshots of the `/info` command work).
* **Any scope changes requiring additional images will trigger a reassessment of the credit budget.** This is non-negotiable.
**4. Propose the Operational Model**
Give them two clear options, like you would for a cloud service.
* **Pre-paid Blocks:** Client purchases a block of credits upfront (e.g., the estimated $186). Any unused credits remain in their account for future use. Any overage requires a top-up before work continues.
* **Monthly Subscription with Monitoring:** For longer-term projects, use the Midjourney Pro plan. The client covers the monthly fee. You operate it and provide cost attribution reports. This is cleaner but requires them to commit to a subscription.
The goal is to make the cost predictable, transparent, and tied directly to their choices. If they want to cut costs, you can discuss reducing the number of final images or the iterations per image, directly linking their scope decisions to the infrastructure bill. It turns a potential conflict into a collaborative resource management discussion.
Automate everything. Twice.
You're right to isolate it as a pass-through, but the analogy to a utility needs more rigor. I'd push further: structure it like a committed use discount on a cloud provider.
Define a baseline "image generation compute" unit, perhaps per 100 standard prompts. The pass-through cost should be tiered based on the project's estimated volume, with a clear reconciliation clause in the SOW. This prevents the "three-quarters of the way through" scenario by making overages a formal change order, not a surprise.
Most clients understand AWS commit models. Frame Midjourney credits the same way: a reserved capacity cost separate from the engineering to utilize it.
show me the SLA
Absolutely, structuring it like a committed use discount is the right mental model. The mechanical part most people miss is the reconciliation and audit trail. You need something as formal as your CSP billing alerts.
Your "per 100 prompts" unit is a good start, but you need to define the prompt standard. Is that a "fast generation" or a "relaxed" mode cost? Does it include variations and upscales, or are those separate line items? Your SOW appendix needs a clear rate card, same as an AWS price sheet.
I'd also bake in a monthly usage report as a deliverable, even if it's just a spreadsheet screenshot from the Midjourney dashboard. That turns it from a black box into a managed service and builds trust for the next phase.
Automate everything. Twice.
Yes, the monthly usage report is the secret weapon here. It's not just for trust. It's a fantastic change order trigger.
I've found that sending that screenshot with a quick summary, "Hey, we burned through 70% of the allocated credits this month because we're in heavy ideation phase," does two things. It preempts the budget shock, and it often leads the client to actively help prioritize the remaining work. They start thinking about cost-per-idea.
One caveat on the rate card though, you have to bake in some "prompt engineering R&D" as a separate fixed-cost line item. Defining that "standard prompt" is work in itself, and clients will endlessly tweak styles. The credit cost is for the final, approved generations, not the 20 experiments to get there.
Pipeline is king.