I've been conducting a series of performance tests on the Recraft API for the past three months as part of my standard workflow for generating technical diagram assets. Since the most recent platform update (which I believe was deployed around October 26th), I have observed a statistically significant increase in generation latency for users on the Basic plan tier.
My methodology involves scripting API calls to generate a consistent set of test prompts (a mix of icons, illustrations, and vector art) and logging the full request/response cycle time. The environment is controlled: same geographical region, same time of day, and using a dedicated runner to minimize network variance. The observed slowdown is not intermittent but appears to be a consistent degradation.
Here is a summary of my aggregated metrics, comparing the 30-day period before and after the update:
* **Average Generation Latency (Pre-update):** 2.8 seconds (± 0.4s standard deviation)
* **Average Generation Latency (Post-update):** 6.1 seconds (± 1.2s standard deviation)
* **P95 Latency (Pre-update):** 3.5 seconds
* **P95 Latency (Post-update):** 8.7 seconds
* **Timeout Errors (Response > 30s):** 0.1% pre-update, now occurring at a rate of 1.8%
This represents an increase of approximately 118% in mean latency and a 149% increase in P95 latency. The error rate, while still low, is now non-negligible for automated workflows.
I initially hypothesized local ISP issues or regional API gateway problems, but my tests from multiple cloud providers (AWS us-east-1, DigitalOcean SGP1) show correlated results. The slowdown is most pronounced for complex prompts requesting "detailed vector art" versus simpler "flat icon" requests, suggesting a possible change in the underlying model or processing pipeline allocation per tier.
My questions for the community are:
* Can anyone else on the Basic plan replicate these findings? I would be particularly interested in data from other regions (EU, APAC).
* Have Pro or Business plan users observed any change in their generation performance? This would help isolate the issue to a tier-specific QoS change versus a global platform performance regression.
* Has anyone from Recraft's team communicated about intentional changes to service level objectives (SLOs) or queueing mechanisms for the Basic tier?
I understand resource allocation per plan is a standard cost optimization practice. However, transparency on such performance boundaries is crucial for users who rely on predictable generation times for their workflows. I'm hoping to gather more data points to understand if this is an undocumented policy change or a potential performance anomaly that needs addressing.
Your methodology here is solid, and I appreciate you sharing the specific latency numbers. That P95 jump from 3.5 to 8.7 seconds is particularly telling, as it suggests the slowest requests are being impacted much more severely than just the average.
I've been monitoring response times on the Basic plan through my support platform's integration, which logs the duration of each API call for SLA reporting. I can confirm a similar trend, though my increase has been slightly less dramatic, around a 2.5x multiplier on average wait times. A key observation from my data is that the slowdown seems most pronounced during what I'd estimate are peak platform usage hours (10am-2pm PT), while off-hour generation is closer to, but still slower than, the old baseline. This could point to a throttling or resource queueing change specifically affecting the Basic tier.
Have you noticed any correlation between time of day and the severity of the latency increase in your controlled tests? It would be interesting to see if the performance delta is constant or fluctuates.
Support is a product, not a department.
Your peak hours observation lines up with what I've seen in my own logs. I'm on the same tier and noticed the 10am-2pm PT window is brutal for icon generation especially. Off-hours (like 6am PT) still aren't back to the old speed but it's tolerable.
One thing I've started doing as a workaround is batching my non-urgent requests to run overnight via a cron job. Helps dodge the worst of the queueing. Not ideal for real-time support ticket attachments though.
Have you checked if the slowdown is uniform across all output types? I'm seeing vector art hit harder than raster icons, which makes me wonder if it's a rendering pipeline change not just straight throttling.
Automate the boring stuff.
I hadn't thought to check vector vs. raster specifically, thanks for pointing that out! I mostly generate icons for project roadmaps, so I'll pay more attention to the type now.
The cron job workaround is clever. Might have to set that up for my weekly report graphics.
Do you think this is just a permanent change on the Basic plan now, or are they working on a fix?
Your controlled methodology is exactly what's needed to move this from anecdote to actionable data. The pre and post update standard deviation shift from 0.4s to 1.2s is a critical detail - it suggests the system's latency isn't just higher, it's become more variable and less predictable. That kind of instability is often worse for pipeline design than a consistently higher median.
I've seen similar patterns with other GenAI APIs when they introduce a lower priority queue for non-paying tiers. The P95 latency degrading more than the average is a classic signature of queue starvation. Your data supports the throttling hypothesis others mentioned, but I'd add that the increased variance could also indicate resource contention within a shared, multi-tenant GPU pool dedicated to the Basic tier.
Have you run any tests to see if retrying a timed-out request yields a faster result on the second attempt? That sometimes happens with queueing systems that have a short deadlock or resource leak.
data is the product
That's an excellent point about the predictability being just as critical as the median latency. When you're building an automated workflow, that kind of variance forces you to set much higher timeout thresholds, which just cascades inefficiency through the whole system.
The retry test you suggested is a clever diagnostic. I haven't run formal tests, but anecdotally I haven't seen a second attempt succeed faster within a short window. If it were a simple queue deadlock, you'd expect some luck on a retry. The consistency of the slowness, especially during those peak windows, makes me lean more toward the resource contention hypothesis you mentioned - it feels like being in a pool that's simply under-provisioned for the current load.
It makes me wonder if the update changed the allocation logic or if there's just a lot more concurrent usage on the Basic tier now, stretching the same resources thinner.
Stay curious.
Resource contention's a solid guess, but it doesn't explain the increased variance. Under-provisioning usually gives you a uniformly slow queue, not a wider spread.
The retry test failing points to something sticky, like a session affinity or a per-request token bucket that's already empty when you hit the queue. Seen it happen when they try to implement 'fair' scheduling across a tenant pool. You're not just waiting, you're waiting in the wrong line.
Could be the update switched the Basic tier from a dedicated cold queue to a hot, shared one. Same resources, but now you're competing with Pro tier preemptions.
Prove it.