What happened
Baseten announced autoscaling schedules on October 30, 2026. The feature is intended for deployments whose traffic follows a known pattern: a recurring daily peak, a planned launch, a load test, or a migration. Rather than waiting for incoming requests to trigger additional capacity, an operator can tell the platform to have replicas running before the expected demand begins.
The problem being addressed is the cold start. Baseten describes this as the time needed to allocate compute resources, start the serving software, and load the model. When demand rises and a new replica is needed, requests that arrive while this preparation is happening can see longer end-to-end response times. The new scheduling control raises the minimum replica count ahead of that arrival window, so the autoscaler has a ready baseline of capacity.
A schedule defines a time window along with a minimum and maximum number of replicas. The minimum is the number of replicas the autoscaler will keep running during that window; the maximum caps how far it may scale. When no schedule is active, the environment returns to its default autoscaling settings. This makes the feature a temporary override of normal operating bounds rather than a replacement for autoscaling itself.
Baseten supports recurring schedules and one-time schedules. The company gives weekday mornings as an example of a recurring use: a meeting-transcription application could increase its minimum replica count before meetings start, then lower it after the busy period. A one-time window can be used before a product launch, load test, or deployment migration. The operational point is not merely to add capacity, but to align a capacity floor with a demand event that is already known.
There can be up to 10 schedules per environment. They share one timezone, cannot overlap, and each must last at least five minutes. Operators can choose daily, hourly, or one-time windows. Baseten says schedules are configurable in its dashboard, command-line interface, or Management API. The announcement does not specify a separate price for the feature, model-specific behavior, or a promise about a particular latency reduction.
What the archive adds
This is a new fact on a related scheduling story. OpenAI Agents API adds Scheduled Automations with cron and one-time runs covered scheduling for agent runs; Baseten applies recurring and one-time timing controls to inference capacity instead. The common theme is moving predictable timing into the platform, while the controlled resource is different.
Trend signal
No supplied pattern is a close enough fit: this is a specific inference-platform capacity control, not evidence by itself for a broader agent architecture shift.
Why now
The announcement frames the timing around predictable traffic rather than a change in models or pricing. As teams run launches, tests, migrations, and recurring production workloads, they can know that demand is coming while still lacking ready replicas at the moment it arrives. Scheduling makes that forecast actionable within Baseten’s autoscaling configuration.
Connections to other events
The earlier OpenAI Agents API note is the closest connection because it added cron-based and one-time execution timing. Baseten’s release uses the same two broad temporal modes—recurring and one-time—but does not schedule an agent task. It schedules the replica bounds that govern model-serving capacity during a selected window.
Why it matters
For a team serving models in a user-facing product, average throughput is not the whole operating experience. A predictable morning surge or launch spike can be painful precisely because autoscaling reacts after the workload arrives. Pre-warming a minimum replica count gives operators a direct trade-off: accept the cost of running capacity during a defined window in exchange for reducing the chance that early requests wait on model loading and runtime startup.
The release also reduces operational glue. A team that previously needed an external scheduler to modify scaling settings can instead express the time window, lower bound, and upper bound in the deployment platform. That is most useful when demand is predictable enough to schedule but variable enough that leaving a high minimum replica count active all day would be wasteful. It does not eliminate the need to size limits, observe traffic, or validate latency under load.
Limits and uncertainty
The source is a Baseten product announcement and does not provide independent latency measurements, customer results, or comparative data against an external scheduler. It does not say how quickly a scheduled change takes effect for every model or hardware configuration, how replica availability behaves under capacity constraints, or whether all account types have access. It also does not establish the cost impact of holding additional replicas warm. A schedule can reduce cold-start exposure only when the demand window is known with sufficient accuracy and the selected minimum is adequate for the arriving workload.
Skill to build now
Make a short demand calendar for one production model endpoint. List recurring peak windows, planned launches, load tests, and migrations; then compare each event’s likely arrival rate with the minimum capacity currently kept ready. For Baseten users, translate one reliable event into a non-overlapping schedule with an explicit start and end, a minimum replica floor, and a protective maximum. Test it before relying on it for a launch, and retain the normal default settings outside the window.
Reader takeaway
Autoscaling schedules turn a known traffic calendar into a capacity policy. For Baseten deployments, they offer a native way to keep replicas ready before a predictable peak, trading bounded warm capacity for fewer requests exposed to cold-start delay. The value depends on forecasting demand and verifying the resulting latency and cost.
Open question
How much latency improvement and extra capacity cost will typical Baseten deployments see for scheduled pre-warming compared with reactive autoscaling alone?