You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add usage safeguards to AI Client (limits, visibility, and cost awareness) #345
This looks like a great step toward a unified AI layer in WordPress. One concern, though, is that since plugins can send prompts through the AI Client, it may be helpful to have safeguards for usage. For example, allowing site owners to set monthly token/request limits and a simple WP-Admin usage dashboard that shows calls by plugin, with estimated costs and alerts. That could help avoid surprise bills and build more trust in the ecosystem.
Introduce a centralized AI usage management layer in WordPress core. This would allow site owners to set global and per-plugin limits (tokens/requests), view usage in a simple WP-Admin dashboard (with plugin-wise breakdown and estimated costs), and receive alerts when thresholds are reached.
Additionally, require basic plugin attribution for AI requests to improve transparency.
This would help prevent unexpected costs, improve visibility, and build trust in the AI ecosystem while remaining extensible for developers.
Great progress on this. As we move toward the 1.0 milestone, I suggest prioritizing these three architectural points to ensure the safeguards are scalable for the core ecosystem:
Mandatory Attribution: We should require a source or component identifier in the AI Client request. Without standardized attribution, the "per-plugin" breakdown in the dashboard will be impossible to maintain reliably across the ecosystem.
Hook-based Costing: Instead of hard-coding token rates, let’s provide a filter (e.g., wp_ai_request_cost). This allows specific providers (OpenAI, Anthropic, etc.) to inject their own pricing logic without bloating Core with volatile price tables.
Aggregated Logging: To avoid database bloat on high-traffic sites, the usage dashboard should rely on daily metadata aggregates rather than storing raw request/response logs in the primary tables.
Defining these "rules of engagement" now will make the 1.0.0 management layer much more robust.
Activity
gohelkunjan commentedon Apr 23, 2026
Hi @jeffpaul
Introduce a centralized AI usage management layer in WordPress core. This would allow site owners to set global and per-plugin limits (tokens/requests), view usage in a simple WP-Admin dashboard (with plugin-wise breakdown and estimated costs), and receive alerts when thresholds are reached.
Additionally, require basic plugin attribution for AI requests to improve transparency.
This would help prevent unexpected costs, improve visibility, and build trust in the AI ecosystem while remaining extensible for developers.
jeffpaul commentedon May 12, 2026
@gohelkunjan there's now a reviewable / testable PR if you want to try that out and provide feedback on the PR, thanks!
gohelkunjan commentedon May 12, 2026
Hi @jeffpaul
Great progress on this. As we move toward the 1.0 milestone, I suggest prioritizing these three architectural points to ensure the safeguards are scalable for the core ecosystem:
Mandatory Attribution: We should require a source or component identifier in the AI Client request. Without standardized attribution, the "per-plugin" breakdown in the dashboard will be impossible to maintain reliably across the ecosystem.
Hook-based Costing: Instead of hard-coding token rates, let’s provide a filter (e.g., wp_ai_request_cost). This allows specific providers (OpenAI, Anthropic, etc.) to inject their own pricing logic without bloating Core with volatile price tables.
Aggregated Logging: To avoid database bloat on high-traffic sites, the usage dashboard should rely on daily metadata aggregates rather than storing raw request/response logs in the primary tables.
Defining these "rules of engagement" now will make the 1.0.0 management layer much more robust.