Rate Limiting and Message Length
Rate limiting tracks the browser user token and client IP separately in WordPress transients; length limiting checks the submitted message before OpenAI processing.
Rate limits count accepted attempts in short WordPress transient windows for both the browser token and detected client IP. Message length rejects a single oversized input before an OpenAI request. Together they reduce burst abuse, accidental pasted documents, and avoidable API consumption, while separate token/IP settings help balance individual use against shared networks.
First, keep rate limiting enabled. The useful result comes later when you use security tester and a private browser to check ordinary use, boundary, and burst behavior, because configuration values matter only when their effect can be seen in retrieval, a generated reply, visitor access, or the connected service.
What this feature does and when to use it
Section titled “What this feature does and when to use it”Use these limits to reduce bursts, accidental oversized input, and cost exposure.
Use this feature in the following situations:
- A public assistant needs predictable burst and message-size boundaries before launch.
- Legitimate users are being limited and you need to identify token versus shared-IP pressure.
- You need a clear visitor message when a limit is reached.
Where to find it
Section titled “Where to find it”Before you begin
Section titled “Before you begin”- SmartSite Assistant is installed and activated.
- You are signed in with an account that can manage WordPress options.
Set it up step by step
Section titled “Set it up step by step”- Keep rate limiting enabled.
- Set token requests/window and IP requests/window based on traffic tests.
- Set a cooldown message period.
- Keep message length enabled and choose a limit suitable for expected questions.
- Customize safe user-facing messages, preserving {limit} where applicable.
- Save settings.
- Use Security Tester and a private browser to check ordinary use, boundary, and burst behavior.
Fields, controls, and important values
Section titled “Fields, controls, and important values”These limits control how much and how quickly visitors can submit, which protects cost and availability rather than improving the model’s knowledge. Sensible message length can encourage focused questions, but a limit that is too small removes details the AI needs. Token and IP windows should permit normal follow-up conversation while slowing obvious bursts.
| Field, control, or status | What SmartSite Assistant does with it | How to use it and why it matters |
|---|---|---|
| Enable Rate Limiting | Turns token- and IP-window counting on or off. It is enabled by default. | Keep this on for a public assistant so the token and IP counters can reject bursts before an OpenAI request. Turning it off leaves the saved thresholds in place but stops applying both rate checks. |
| Messages per user token | Maximum messages accepted for one browser token during its window. Default 30; allowed 1–1,000. | Set how many attempts one browser token may make during the token window. Lowering it reduces one browser’s burst capacity but can interrupt a legitimate visitor who asks several short follow-up questions. |
| User-token window | Number of seconds used for the token counter. Default 60 seconds; allowed 10–3,600. | Set how long, in seconds, the per-token counter groups attempts. A longer window makes the same message allowance more restrictive because each accepted attempt remains counted for longer. |
| Messages per IP address | Maximum messages accepted for one detected client IP during its window. Default 60; allowed 1–5,000. | Set the combined allowance for requests detected from one client IP during the IP window. Keep it higher than the token allowance to accommodate offices, homes, mobile gateways, and proxies that share an address. |
| IP-address window | Number of seconds used for the IP counter. Default 60 seconds; allowed 10–3,600. | Choose the period during which requests from one detected address remain in the shared counter. Test behind the production proxy because incorrect client-IP detection can group unrelated visitors together. |
| Cooldown | Additional cooldown value stored for rate-limit behavior/messages. Default 30 seconds; allowed 0–600. | Set the additional cooldown value used by the saved rate-limit configuration and messages. Treat it as part of the visitor recovery experience and test the exact wait behavior instead of assuming the counter resets immediately. |
| Rate-limit message | Visitor-facing text returned when the token or IP limit denies the request. | Write the notice shown when either the token or IP check rejects a request. Explain that the visitor should wait and retry without revealing thresholds, IP data, tokens, or other security details. |
| Enable Maximum Message Length | Turns the single-message character check on or off. It is enabled by default. | Keep this on to reject a single oversized submission before it is sent to OpenAI. Turning it off does not increase model context guarantees and can increase cost and pasted-data privacy risk. |
| Maximum message length | Largest accepted visitor message in characters. Default 2,000; allowed 50–50,000. | Set the largest visitor input, in characters, appropriate for the site’s questions. Lower values reject long legitimate descriptions; very high values allow pasted documents and potentially unnecessary OpenAI processing. |
| Message-length response | Visitor-facing text returned for an oversized message. {limit} is replaced with the saved numeric maximum. | Write the notice returned when a message exceeds the character maximum. Keep the supported {limit} placeholder so visitors see the actual allowance, and test one message immediately above the boundary. |
How to confirm it is working
Section titled “How to confirm it is working”After saving Rate Limiting and Message Length, repeat the final test with clean context. That distinction matters because WordPress can store a valid value even when remote processing, access rules, caching, or delivery prevents it from influencing the real experience.
Practical example
Section titled “Practical example”A public support site may retain 30/token and 60/IP per minute, then tighten only after observing legitimate burst behavior.
Recommended practice
Section titled “Recommended practice”- Change one part of Rate Limiting and Message Length at a time and keep a short record of the previous value and test result.
- Include ordinary near-matches in every test so protection is not tuned only against deliberately obvious abuse.
Important warnings
Section titled “Important warnings”Common problems and focused checks
Section titled “Common problems and focused checks”| Problem | What to check and what to do next |
|---|---|
| Legitimate users are rate-limited. | Compare token and IP counters, proxy IP handling, shared networks, and the chosen window before raising limits. |
| Rate Limiting and Message Length is missing or does not match this guide. | Confirm the plugin is active and the account can manage WordPress options. Reproduce the exact message safely and identify the matching limit, pattern, score, address, or whitelist entry. |
| A change on Rate Limiting and Message Length does not produce the expected result. | Keep the exact notice and test case, then review the browser console and WordPress/PHP log. Reproduce the exact message safely and identify the matching limit, pattern, score, address, or whitelist entry. |
Screen reference
Section titled “Screen reference”- Capture
- Show rate and message-length controls with audited defaults and custom messages that reveal no internal data.
- Show
- Token count/window, IP count/window, cooldown, maximum length, messages, Save
- Viewport
- Desktop, 1440 × 900
- Annotate
- Use numbered callouts only for controls referenced in the procedure.
- Redact
- OpenAI keys, tokens, secrets, personal information, private URLs, IP addresses, and conversation text