Yeah, that point about credit normalization is key. Are you mapping the "relaxed" mode multiplier consistently? We saw some edge cases where batches or upscales weren't always logged the same way, which threw off our unit calculations for a bit.
We ended up adding a quick validation step that compares our parsed credit total against the high-level usage numbers from Midjourney's subscription page, just to catch any systematic drift in the log parsing logic. It flagged a few missed variations for us.
Quarterly syncs are a great idea for catching drift. We do something similar, but we also bake it into the pipeline itself as a heartbeat check. Every job logs its current config hash, and we have a monitor that alerts if the hash doesn't match the one stored in the "approved" doc for more than a run or two. It catches issues faster than a quarterly scan.
That said, I've found the real challenge is defining what constitutes a meaningful "drift" that needs flagging. Is a new, optional query parameter a drift? We had to build a small rules engine to differentiate between breaking changes and harmless extensions, otherwise the alert fatigue was real.
ship it
Yeah, normalizing those credits from the logs was the trickiest part for me too. The "relaxed" mode multiplier is straightforward, but we also had to account for variations in how `--fast` or speed mode commands were logged early on, before their API stabilized. A simple lookup table for command-to-credit mapping saved us.
Have you considered adding a sanity-check layer? We run our parsed totals against the subscription page's high-level usage every Monday. It's caught a few parsing logic drifts after Midjourney updates.
Keep automating!