Pre-call rule evaluation with sub-5ms overhead. Block model usage before it happens. Model redirect for seamless policy enforcement without developer friction.
Gateway mode enables synchronous rule evaluation before each LLM call. When a blocking rule matches, the call is prevented before it reaches the LLM provider — zero cost incurred for blocked calls. P50 overhead: 3.2ms. P99 overhead: 11ms. Gateway mode requires adapter configuration (enforcement_mode: gateway in ~/.forg/config.yaml). Fail-open behavior: if the Rule Engine is unreachable within the configured timeout, the call is allowed through.
Model policy rules now support a redirect_to field. Instead of blocking a disallowed model and returning an error to the user, FORG can transparently redirect the call to a configured fallback model. Example: deny claude-opus*, redirect to claude-sonnet-4-5. The redirect is applied at the adapter level before the API call is made. The dashboard shows redirected calls with both the original model and the model actually used.
Gateway mode now supports explicit fail-open configuration. If the Rule Engine is unreachable within gateway_timeout_ms (default: 500ms), the adapter falls back to async mode: allows the call through and queues the signal for later evaluation. This ensures that Rule Engine downtime never blocks developer productivity. Fail-open events are logged and visible in the dashboard.
Budget accumulator updates (the atomic Postgres write that tracks accumulated spend against limits) had P99 latency of ~45ms under high-concurrency conditions. v2.6.0 replaces advisory lock-based concurrency control with optimistic locking and a retry loop, reducing P99 to ~11ms. This improvement is particularly significant for teams with many simultaneous active developers triggering budget rule evaluations.
Budget rules with period: rolling_30d were incorrectly resetting at month boundaries (treating them as calendar-month rules). v2.6.0 correctly evaluates rolling_30d windows as a true 30-day lookback from the current timestamp, regardless of month boundaries. Teams using rolling_30d rules may see their accumulated totals change at upgrade time as the window recalculates.