docs(pipecat-cloud): document that min-agents changes apply asynchronously (T-3351) - #1089
Open
jamsea wants to merge 4 commits into
Open
docs(pipecat-cloud): document that min-agents changes apply asynchronously (T-3351)#1089jamsea wants to merge 4 commits into
jamsea wants to merge 4 commits into
Conversation
…ously (T-3351) Raising min-agents returns a success response as soon as the change is accepted. It does not mean the new reserved instances exist or are ready. Customers who raise min-agents and then dial a second later race the scale-up and get cold starts. Adds a "Changing min-agents at Runtime" section to the capacity planning guide with the poll-before-traffic recipe (reconciledDeploymentId == desiredDeploymentId, ready, readyReplicas minus activeSessionCount), plus a warning on the scaling page and a note on the CLI --min-agents param.
Contributor
|
🔍 Mintlify preview for this branch: https://daily-docs-pcc-min-agents-async-scale-up-t3351.mintlify.site |
Reverts the scaling.mdx and deploy.mdx changes. Keeps only a short tip on the capacity planning page: raise min-agents minutes ahead of traffic, and note that the change applies asynchronously. Refs T-3351
Contributor
There was a problem hiding this comment.
Pull request overview
This PR aims to close a Pipecat Cloud documentation gap by clarifying that raising min-agents does not make new warm instances immediately available, so traffic sent “seconds later” can still experience cold starts.
Changes:
- Added a new callout emphasizing that
min-agentsupdates take effect asynchronously and should be done minutes in advance. - Updated the “Time-Based Scaling” strategy bullet to reinforce making the change ahead of traffic.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
A customer raised
min-agentson their agent, waited 5 seconds, then started dialing. They got repeated 18 to 26 second cold starts and could not work out why, because their scaling config looked right.The reason: a
min-agentschange is applied asynchronously. The successful response means the change was accepted, not that the new reserved instances exist or are ready to take a session. There is no readiness gate on that response. Their calls raced the scale-up.Nothing in the public docs said this, and nothing told a customer how to check when the new reserved instances are actually ready. The ~30 second warm-up delay was already documented for idle agents on the capacity planning page, but it was never connected to a
min-agentschange.Searchability
The new section names the symptom a customer actually sees ("unexpected cold starts right after raising min-agents") so it turns up in search and in Kapa answers.