Roll out AI features safely with model-version flags, A/B testing, gradual rollouts, and automatic rollback on quality regression.
AI Feature Flags enable the incremental rollout, monitoring, and control of machine learning model behavior, inference pipelines, and AI-driven application logic in production. They are essential when model updates, hyperparameter tuning, or new AI workflows must be tested, validated, and rolled out without downtime or risk to end users. Feature flags become critical when multiple models compete in A/B testing, when real-time inference pipelines depend on dynamically selected components, or when AI logic evolves faster than deployment cycles.
Feature flags for AI are not just toggles for UI behavior; they govern model selection, input preprocessing, output postprocessing, and routing logic. A single flag may determine which model version serves a request, which preprocessing pipeline applies to input data, or whether to apply a post-hoc correction layer.
The most common use of AI feature flags is to route traffic to different model versions based on runtime conditions.
{
"model_version": "v2.3.1",
"preprocessing_pipeline": "image_enhance_v2",
"inference_batch_size": 32,
"enable_postprocessing": true,
"postprocessing_threshold": 0.72
}
This configuration is applied per request via a X-AI-Model-Config header:
GET /predict HTTP/1.1
Host: api.ai.example.com
X-AI-Model-Config: {"model_version":"v2.3.1","preprocessing_pipeline":"image_enhance_v2"}
Accept: application/json
The backend service reads the header, applies the configuration, and routes the request to the appropriate model endpoint. The model version is resolved through a centralized configuration store—typically a database or a key-value service like Redis.
When a new model is deployed, it is registered in the models table:
INSERT INTO models (name, version, url, created_at, metadata)
VALUES ('image_classifier', 'v2.3.1', 'https://models.ai.example.com/v2.3.1', '2024-03-15T12:00:00Z', '{"accuracy": 0.942, "latency_ms": 47}');
A feature flag named ai_model_routing controls the active model for a given service.
{
"feature": "ai_model_routing",
"enabled": true,
"rules": [
{
"condition": "header",
"key": "X-AI-Model-Config",
"operator": "contains",
"value": "image_enhance_v2"
},
{
"condition": "percentage",
"value": 75
}
],
"variants": {
"v2.1.0": {
"priority": 1,
"weight": 0.4,
"config": {
"model_version": "v2.1.0",
"preprocessing_pipeline": "image_enhance_v1"
}
},
"v2.3.1": {
"priority": 2,
"weight": 0.6,
"config": {
"model_version": "v2.3.1",
"preprocessing_pipeline": "image_enhance_v2"
}
}
}
}
The system evaluates the rules in order, selecting the first matching variant. If no rule matches, the default variant is used.
AI feature flags extend beyond model selection to control entire inference pipelines.
ai_inference_pipeline:
enable_batching:
enabled: true
rollout_strategy: "gradual"
rollout_percentage: 60
rollout_start_time: "2024-03-15T14:00:00Z"
rollout_end_time: "2024-03-15T16:00:00Z"
parameters:
batch_size: 16
max_wait_ms: 150
min_batch_size: 4
warmup_interval_s: 30
enable_caching:
enabled: false
cache_ttl_seconds: 300
cache_key_template: "{{model_version}}_{{input_size}}_{{preprocessing}}"
cache_strategy: "lru"
enable_postprocessing:
enabled: true
threshold: 0.65
method: "top_k"
top_k: 5
Each flag is stored in a key-value store under a ai.feature.flag: prefix. The ai_inference_pipeline.enable_batching flag is checked at the start of the inference pipeline:
func (s *InferenceService) ServeHTTP(w http.ResponseWriter, r *http.Request) {
config := s.GetFeatureFlag("ai_inference_pipeline.enable_batching")
if config.Enabled {
batcher := NewBatcher(
BatchSize: config.Parameters["batch_size"].(int),
MaxWaitMs: config.Parameters["max_wait_ms"].(int),
MinBatchSize: config.Parameters["min_batch_size"].(int),
WarmupInterval: time.Duration(config.Parameters["warmup_interval_s"].(int)) * time.Second,
)
// ... apply batching
}
// Apply postprocessing if enabled
if s.GetFeatureFlag("ai_inference_pipeline.enable_postprocessing").Enabled {
threshold := s.GetFeatureFlag("ai_inference_pipeline.enable_postprocessing").Parameters["threshold"].(float64)
topK := s.GetFeatureFlag("ai_inference_pipeline.enable_postprocessing").Parameters["top_k"].(int)
// ... apply top-k filtering with threshold
}
}
The system evaluates flag state at runtime, so changes propagate immediately without redeployment.
Feature flags support A/B testing of model behavior, where different models serve different user segments.
{
"feature": "ai_ab_test_image_classifier",
"enabled": true,
"rules": [
{
"condition": "user_id",
"operator": "in",
"values": [1001, 1002, 1003]
},
{
"condition": "device",
"operator": "eq",
"value": "mobile"
},
{
"condition": "time",
"start": "2024-03-15T00:00:00Z",
"end": "2024-03-15T23:59:59Z"
}
],
"variants": {
"baseline_model": {
"weight": 0.6,
"config": {
"model_version": "v2.0.0",
"preprocessing": "standard"
}
},
"new_model": {
"weight": 0.4,
"config": {
"model_version": "v2.3.1",
"preprocessing": "enhanced"
}
}
}
}
Requests are routed to one of the two variants based on the evaluation of the rules. The system logs the selected variant and its configuration for each request.
When a user makes a request, the service logs:
{
"request_id": "req-7a1b2c3d",
"user_id": 1002,
"device": "mobile",
"timestamp": "2024-03-15T14:23:45Z",
"variant": "new_model",
"model_version": "v2.3.1",
"preprocessing": "enhanced",
"model_prediction": [0.82, 0.11, 0.07]
}
This enables tracking of model performance across user cohorts.
AI feature flags are not just configuration—they are observability points. Each flag change is logged, and flag state is exposed via a metrics endpoint.
GET /metrics/feature-flags?flag=ai_inference_pipeline.enable_batching HTTP/1.1
Host: monitoring.ai.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yVq9sJ5iRq4k
Response:
{
"flag": "ai_inference_pipeline.enable_batching",
"last_updated": "2024-03-15T14:12:03Z",
"current_value": true,
"history": [
{
"timestamp": "2024-03-15T12:00:00Z",
"value": false,
"reason": "initial rollout"
},
{
"timestamp": "2024-03-15T14:12:03Z",
"value": true,
"reason": "increased traffic, validated performance"
}
],
"usage": {
"total_requests": 12403,
"flag_enabled_requests": 7421,
"flag_disabled_requests": 4982
}
}
A dashboard can show the adoption rate of a flag over time, and correlate it with model performance metrics.
Several silent failures commonly arise with AI feature flags:
device and user_id, but the user_id is a string in the request, while the flag expects an integer. The routing fails silently, with users on mobile devices receiving the wrong model.model_version and preprocessing, but the preprocessing key is misspelled as preprocess in the config. The pipeline uses the default preprocessing, but no logs indicate the mismatch.null value. The batch_size field is null, so the inference pipeline uses 0 as the batch size, leading to underutilization.rollout_percentage of 60 is applied, but the system interprets 60 as a boolean true instead of 60%. Requests are routed to the new variant, but only half the expected traffic arrives.ai_inference_pipeline.enable_postprocessing flag depends on ai_inference_pipeline.enable_batching. The system checks for the latter, but if it is not defined, the enable_postprocessing flag is treated as false even when it is set to true in the database.Feature flags are updated via a REST API. A client sends a patch request to update a flag:
PATCH /api/feature-flags/ai_inference_pipeline.enable_batching HTTP/1.1
Host: config.ai.example.com
Content-Type: application/json
Authorization: Bearer <token>
{
"enabled": true,
"parameters": {
"batch_size": 32,
"max_wait_ms": 200,
"min_batch_size": 8
}
}
The service responds with:
{
"flag": "ai_inference_pipeline.enable_batching",
"updated_at": "2024-03-15T14:20:12Z",
"status": "success",
"message": "Configuration updated and applied to all active services"
}
The system validates the request body, ensuring that all required parameters are present and correctly typed. If batch_size is a string, the server returns:
{
"error": "invalid_parameter",
"parameter": "batch_size",
"expected_type": "integer",
"actual_value": "32",
"message": "batch_size must be an integer"
}
All feature flags follow a common schema, defined in schema/feature-flag.json:
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"feature": { "type": "string", "pattern": "^[a-z][a-z0-9_]*$" },
"enabled": { "type": "boolean" },
"rules": {
"type": "array",
"items": {
"type": "object",
"properties": {
"condition": { "enum": ["header", "user_id", "device", "time", "percentage"] },
"key": { "type": "string" },
"operator": { "enum": ["eq", "ne", "in", "contains", "gt", "lt"] },
"value": { "anyOf": [ { "type": "string" }, { "type": "number" }, { "type": "boolean" } ] },
"start": { "format": "date-time" },
"end": { "format": "date-time" },
"percentage": { "type": "number", "minimum": 0, "maximum": 100 }
},
"required": [ "condition" ]
}
},
"variants": {
"type": "object",
"additionalProperties": {
"type": "object",
"properties": {
"weight": { "type": "number", "minimum": 0, "maximum": 1 },
"priority": { "type": "integer", "minimum": 1 },
"config": { "type": "object" }
},
"required": [ "weight", "priority" ]
}
},
"parameters": { "type": "object" }
},
"required": [ "feature", "enabled" ]
}
The system validates every flag update against this schema, rejecting malformed configurations.
For high-traffic systems, a feature flag supports weighted A/B testing across multiple variants.
{
"feature": "ai_model_ab_test",
"enabled": true,
"rules": [
{
"condition": "percentage",
"value": 100
}
],
"variants": {
"model_a": {
"weight": 0.3,
"config": { "model_version": "v1.0.0" }
},
"model_b": {
"weight": 0.4,
"config": { "model_version": "v2.0.0" }
},
"model_c": {
"weight": 0.3,
"config": { "model_version": "v2.1.0" }
}
}
}
The system uses a weighted random selection algorithm. Each request is assigned a variant based on the cumulative weights.
Multiple flags are combined in a chain to control complex AI workflows.
{
"feature": "ai_pipeline_composite",
"enabled": true,
"rules": [
{
"condition": "header",
"key": "X-Processing-Type",
"operator": "eq",
"value": "realtime"
}
],
"variants": {
"realtime": {
"config": {
"enable_batching": true,
"enable_caching": true,
"model_version": "v2.3.1"
}
},
"batch": {
"config": {
"enable_batching": false,
"enable_caching": false,
"model_version": "v2.0.0"
}
}
}
}
The system evaluates the ai_pipeline_composite flag, then applies its configuration, which may include nested feature flags like enable_batching and enable_caching, each with their own rules and variants.
A flag determines which model to use based on input features.
{
"feature": "ai_model_selector",
"enabled": true,
"rules": [
{
"condition": "input",
"key": "image_size",
"operator": "gt",
"value": 1024
},
{
"condition": "input",
"key": "color_space",
"operator": "eq",
"value": "RGB"
}
],
"variants": {
"high_resolution": {
"config": { "model_version": "v2.3.1" },
"weight": 0.7
},
"standard": {
"config": { "model_version": "v2.0.0" },
"weight": 0.3
}
}
}
The system inspects the input payload and selects the appropriate model variant. If image_size is 1500 and color_space is RGB, the high_resolution variant is selected.
This page was rewritten on 17 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.
We use cookies for analytics (Google Analytics) and advertising (Google AdSense) to improve your experience and support free content. Privacy Policy