Is your feature request related to a problem?
On many survival servers, players build automatic villager breeder farms and leave them running unattended.
Common situations include:
Players going AFK near a breeder
Breeders left active after players log out
Chunk loaders or always-loaded areas keeping breeders active
As a result, villagers continue to breed indefinitely unless manually stopped, leading to:
Unbounded villager population growth
Increasing AI and pathfinding cost over time
POI contention amplification
Gradual but severe TPS degradation
From the server’s perspective, this is passive performance loss caused by unattended player automation, not intentional gameplay. The lag does not appear immediately, but accumulates over hours or days.
Describe the solution you'd like.
Provide an optional, preventative villager breeding density cap at the Paper level.
When a villager breeding event occurs:
When a villager breeding event occurs, the server counts nearby unemployed or non-working villagers within a configurable radius. If the number of such villagers already exceeds a defined threshold, the breeding event is cancelled before the child entity is spawned. By targeting villagers that are not bound to work-related POIs and provide minimal gameplay value, this approach stops runaway population growth at the source while remaining largely unnoticeable to players, even when breeder farms are left running indefinitely.
Describe alternatives you've considered.
On our server, we have already deployed a lightweight mitigation strategy specifically targeting unattended villager breeder farms. The implementation listens to EntityBreedEvent and, when the breeding entity is a villager, counts nearby villagers within a configurable radius, with the option to focus specifically on unemployed or non-working villagers that are not bound to work-related POIs and contribute little gameplay value while still incurring AI cost (such as nitwits). If the local population of such villagers exceeds a defined threshold, the breeding event is cancelled before the child entity is spawned. By limiting only villagers that are not actively participating in village mechanics, this approach prevents further runaway population growth without requiring entity cleanup or forced killing and remains largely unnoticeable to players. It also introduces negligible runtime overhead due to early-exit logic. After deploying this solution, villager populations no longer grew indefinitely even when breeders were left running, TPS degradation caused by long-running breeder farms was effectively eliminated, and no impact on normal gameplay or short-term breeding behavior was reported by players. Because the check only runs on breeding events, no additional tick cost was observed, and the solution has been running stably in a real production server environment.
Other
Why Move This Logic Into Paper
While this approach already works well as a plugin, implementing it directly at the Paper level offers clear advantages. Most importantly, it allows server owners to prevent performance issues before they accumulate, rather than reacting after villager populations have already grown out of control. By stopping runaway breeding at the source, servers can avoid emergency entity cleanup, manual intervention, or disruptive kill commands. In addition, a Paper-level implementation avoids the overhead of plugin event dispatch and enables tighter integration with internal entity logic, allowing for more efficient early exits and cleaner interaction with existing AI and villager systems. Centralizing this logic also reduces ecosystem duplication: many performance-focused servers currently implement their own breeder-limiting plugins with slightly different behavior, while an opt-in Paper feature would provide a consistent, well-tested solution across servers. Finally, because the feature would be fully configurable and disabled by default, it introduces no gameplay changes unless explicitly enabled, offering a clear and predictable performance safeguard for servers that choose to use it.
Is your feature request related to a problem?
On many survival servers, players build automatic villager breeder farms and leave them running unattended.
Common situations include:
Players going AFK near a breeder
Breeders left active after players log out
Chunk loaders or always-loaded areas keeping breeders active
As a result, villagers continue to breed indefinitely unless manually stopped, leading to:
Unbounded villager population growth
Increasing AI and pathfinding cost over time
POI contention amplification
Gradual but severe TPS degradation
From the server’s perspective, this is passive performance loss caused by unattended player automation, not intentional gameplay. The lag does not appear immediately, but accumulates over hours or days.
Describe the solution you'd like.
Provide an optional, preventative villager breeding density cap at the Paper level.
When a villager breeding event occurs:
When a villager breeding event occurs, the server counts nearby unemployed or non-working villagers within a configurable radius. If the number of such villagers already exceeds a defined threshold, the breeding event is cancelled before the child entity is spawned. By targeting villagers that are not bound to work-related POIs and provide minimal gameplay value, this approach stops runaway population growth at the source while remaining largely unnoticeable to players, even when breeder farms are left running indefinitely.
Describe alternatives you've considered.
On our server, we have already deployed a lightweight mitigation strategy specifically targeting unattended villager breeder farms. The implementation listens to EntityBreedEvent and, when the breeding entity is a villager, counts nearby villagers within a configurable radius, with the option to focus specifically on unemployed or non-working villagers that are not bound to work-related POIs and contribute little gameplay value while still incurring AI cost (such as nitwits). If the local population of such villagers exceeds a defined threshold, the breeding event is cancelled before the child entity is spawned. By limiting only villagers that are not actively participating in village mechanics, this approach prevents further runaway population growth without requiring entity cleanup or forced killing and remains largely unnoticeable to players. It also introduces negligible runtime overhead due to early-exit logic. After deploying this solution, villager populations no longer grew indefinitely even when breeders were left running, TPS degradation caused by long-running breeder farms was effectively eliminated, and no impact on normal gameplay or short-term breeding behavior was reported by players. Because the check only runs on breeding events, no additional tick cost was observed, and the solution has been running stably in a real production server environment.
Other
Why Move This Logic Into Paper
While this approach already works well as a plugin, implementing it directly at the Paper level offers clear advantages. Most importantly, it allows server owners to prevent performance issues before they accumulate, rather than reacting after villager populations have already grown out of control. By stopping runaway breeding at the source, servers can avoid emergency entity cleanup, manual intervention, or disruptive kill commands. In addition, a Paper-level implementation avoids the overhead of plugin event dispatch and enables tighter integration with internal entity logic, allowing for more efficient early exits and cleaner interaction with existing AI and villager systems. Centralizing this logic also reduces ecosystem duplication: many performance-focused servers currently implement their own breeder-limiting plugins with slightly different behavior, while an opt-in Paper feature would provide a consistent, well-tested solution across servers. Finally, because the feature would be fully configurable and disabled by default, it introduces no gameplay changes unless explicitly enabled, offering a clear and predictable performance safeguard for servers that choose to use it.