Statsig Updates & Release Notes

You can now separate the ability to delete configs from the ability to edit them.

What you can do now

• Manage Edit, Archive, and Delete as distinct permissions on your Role Permissions page

Why this matters

Previously, delete was bundled into a single "Edit Delete Configs" permission with no way to separate them. Now, you can grant edit access broadly and keep delete access narrow, without having to create workarounds or roles with too many extra permissions.

FYI!

This is opt-in and not on by default. To enable granular delete permissions for your organization, contact your Statsig account team. Once enabled, the separate Delete permission will appear on your Role Permissions page under Project Settings.

Try it out

Learn more in the

Statsig Access Management docs

.

The full experiment review lifecycle is now accessible over the Console API and the Statsig MCP.

What you can do now

We now have eight new CAPI endpoints and niine new MCP tools cover the complete review lifecycle:

• Create a review proposing a change to an experiment
• List an experiment's reviews, newest first
• Get a single review including status, proposed change, author, and reviewers
• Look up who is eligible to approve or reject
• Edit a pending review's metadata
• Approve or reject an in-flight review
• Cancel a pending review
• Commit an approved review to apply it to the live experiment

Why this matters

Before, creating and moving an experiment review through approval required the console, blocking any automated workflow that touched a review-gated experiment. Now you can propose, approve, and commit experiment changes entirely through the API or MCP, with no manual console step in the way.

Try it out

If you have the Statsig MCP set up, try a prompt like:

"Open a review to make a decision on
experiment_name
, shipping the Test group."

Review the full API reference in the
Statsig Console API docs
.

🔎 Audit Overrides Across Your Entire Project

You can now query all overrides across your project in a single API call.

What you can do now

We now have one new endpoint available on statsigapi.net/console/v1/ :

GET /console/v1/overrides

Why this matters

Before , finding where a user was overridden meant querying each gate, experiment, and layer one by one. Now you can audit overrides project-wide in a single call, whether you're debugging unexpected behavior for a specific user, running a compliance audit, or cleaning up override sprawl.

Try it out

Review the full API reference in the Statsig Overrides Audit docs.

You can now follow and unfollow Dynamic Configs to get notified when they're updated.

What you can do now

• Follow a Dynamic Config to receive notifications whenever it's updated
• Unfollow at any time to stop receiving notifications

Why this matters

Dynamic Configs often control things like API settings and rollout thresholds. Being able to follow means the right people get notified the moment a Dynamic Config updated, without having to watch the console or find out after the fact.

Try it out

Open a Dynamic Config in the Statsig console and click Follow to subscribe to updates.
Learn more in the Statsig Console docs.

Feature Gate Reviews in the Console API

The full feature gate review lifecycle is now exposed over the Console API.

What you can do now

Eight new endpoints cover the complete review lifecycle:

• POST /gates/:id/reviews create a review with the proposed change
• GET /gates/:id/reviews list reviews, newest first
• GET /gates/:id/reviews/:reviewID get a single review
• PUT /gates/:id/reviews/:reviewID edit metadata or content
• PUT /gates/:id/reviews/:reviewID/approve approve
• PUT /gates/:id/reviews/:reviewID/reject reject
• DELETE /gates/:id/reviews/:reviewID cancel an in-flight review
• GET /gates/:id/eligible_reviewers look up eligible reviewers

Why this matters

Before , creating and moving a review through approval required the console, blocking any automated workflow that touched a review-gated gate. Now you can propose, approve, and commit gate changes entirely through the API, with no manual console step in the way.

Try it out

Review the full API reference in the Statsig Console API docs.

🗄️ Parameter Store Management in the Statsig MCP

You can now create and manage Parameter Stores directly through the Statsig MCP.

What you can do now

Three new tools are available on

api.statsig.com/v1/mcp

:

• Create_Param_Store
• Update_Param_Store
• Delete_Param_Store

Why this matters

Now, you can create a store, define its parameters, and point them at a gate or experiment without leaving your agent flow, making end-to-end feature provisioning possible for the first time.

Try it out

If you have the Statsig MCP set up, try a prompt like:

• "Using the Statsig MCP, create a Parameter Store called checkout-config and add a static boolean parameter "express_checkout_enabled" set to true.

Learn more in the docs:

Statsig MCP Overview
.

Experiment reads just got a lot leaner and easier.

What you can do now

Trimmed and batched experiment reads

• Fetch multiple experiments in a single call instead of one round-trip per experiment.
• A single experiment trims from ~66 fields down to just what you ask for, achieving up to 95-99% context reduction.

Why this matters

For agentic workflows reasoning across many experiments, pulling full payloads burns through context windows fast. Field trimming and batching keep those workflows lean.

Learn more in the docs: Statsig MCP Overview.

The Statsig MCP now supports read-only users, and experiment reads got a lot leaner.

What you can do now

Read-only MCP access

• Users on a read-only role can now connect to the Statsig MCP and use it for analysis workflows.

Trimmed and batched experiment reads

• Fetch multiple experiments in a single call instead of one round-trip per experiment.
• A single experiment trims from ~66 fields down to just what you ask for, achieving up to 95-99% context reduction.

Why this matters

Now teams can give people who are on a read-only role access to use Statsig MCP for analysis. And for agentic workflows reasoning across many experiments, pulling full payloads burns through context windows fast. Field trimming and batching keep those workflows lean.

Try it out

If you have the Statsig MCP set up, try a prompt like: "Using the Statsig MCP, fetch experiments exp_a and exp_b and show only their hypothesis and primaryMetrics."

Learn more in the docs: Statsig MCP Overview.

Now, you can create an Autotune (multi-armed bandit) experiment directly through the Statsig MCP, no console required.

What you can do now

• Create an Autotune by describing the arms, success event, exploration and attribution windows, and winner threshold.
• Autotunes are created as drafts by default, so no traffic is reallocated until you start it from the console.
• The agent confirms before writing, prompting for confirmation before anything is created.

One new tool is available on api.statsig.com/v1/mcp:

• Create_autotune

Why this matters

Teams running Autotune for live AI agent experiments can now manage the full setup through agents. Instead of manually configuring a multi-armed bandit in the console, you can describe what you want and let the agent build it, keeping your agentic workflows end-to-end.

Try it out

If you have the Statsig MCP set up, try a prompt like:

• "Using the Statsig MCP, create an Autotune called checkout-button-color with a control variant {color: blue} and a treatment variant {color: green}, optimizing for the event 'checkout', with 24hr exploration and attribution windows and a 95% winner threshold."

Learn more in the docs: Statsig MCP Overview

You can now delete individual experiment and layer overrides directly via the Console API, no GET-mutate-POST workaround needed.

What you can do now

• Delete a single conditional or userID override from an experiment or layer via path-param DELETEs.
• Target a specific environment with an optional environment query param, or omit it for the all-environments bucket.
• Call these endpoints cleanly from OpenAPI-generated or SDK-based clients, since they use path and query params only with no DELETE body.

Four new endpoints are available on statsigapi.net/console/v1/ :

• DELETE /experiments/:id/overrides/conditional/:type/:name
• DELETE /experiments/:id/overrides/userID/:userID
• DELETE /layers/:id/overrides/conditional/:type/:name
• DELETE /layers/:id/overrides/userID/:userID

:type is gate or segment.

:name is the gate or segment name. All four endpoints are idempotent, returning 200 even when no matching override exists.

Why this matters

SDK-based E2E testing frameworks often need to clean up individual overrides between test runs. The previous approach required fetching the full overrides object, mutating it locally, and re-posting it, which is fragile and hard to parallelize. These endpoints make override teardown a single, safe, idempotent call.

Try it out

Review the full API reference in the Statsig Console API docs.

Statsig MCP now lets you pull the full edit history of any Feature Gate, Experiment, or Dynamic Config without a console.

What you can do now

• Retrieve the complete version timeline for a feature gate, experiment, or dynamic config.
• See who made each change, when, and exactly what was modified: rules, ID type, enabled state, allocation, variants, and values.
• Access config history programmatically to power agentic workflows that reason about how configs have changed over time.

Three new tools are available on api.statsig.com/v1/mcp:

• Get_Gate_Version_History
• Get_Experiment_Version_History
• Get_Dynamic_Config_Version_History

Why this matters

Config history is critical for debugging, incident reviews, and agentic reasoning, but it's been locked behind manual console navigation. Now, you can understand when behavior changed, reconstruct a timeline for an incident post-mortem or feed agents that need to detect or reason about config drift over time.

Try it out

If you have the Statsig MCP, try a prompt like:

• "Using the Statsig MCP, pull the version history for gate feature-gate-name and summarize what changed across versions."

Learn more in the docs: Statsig MCP Overview.

Today, we’re launching agent-skills, our new public repository for reusable Statsig skills. It’s designed to help teams run common Statsig workflows faster and more consistently from AI agents.

What you can do now

• Create Dashboard: Generate Statsig dashboards with a repeatable, structured workflow instead of manual one-off setup.
• Create Cloud Metric: Define cloud metrics through a guided skill flow, including key configuration steps that are easy to miss in ad hoc API calls.

Why this matters

Skills turn complex Statsig workflows into repeatable, shareable agent instructions you can personalize or share and reuse across your team's projects. With Skills, you can direct your agents to execute multi-step logic, stitching together Console API calls, MCP tool calls, and prompt instructions.

Getting started

1. Ensure you have a Console API Key -- this is required for the skill to carry out Statsig Console API actions.
2. Install the Statsig agent-skills repo with the Vercel skills CLI:

npx skills add statsig-io/agent-skills

1. Instruct your agent to use the skill (e.g., "Codex, help me create a cloud ratio metric for checkout rate).
2. Watch your agent follow your direction and the skill instructions to work with Statsig!

Explore the repo and start building repeatable Statsig workflows: statsig-io/agent-skills.

Statsig MCP now supports for both Segments and Layers, so you can more seamlessly manage user targeting and experiment configuration using your AI workflows.

What you can do now

• View full segment definitions and create new segments (rule-based or ID-based)
• Update existing segments, including rule-based segments and ID-based segment membership
• View all layers and their parameter details
• Create layers and create experiments with assignment to a layer

Why this matters

Segments and Layers are core building blocks for safe, precise experimentation. Segments unlocked faster targeting definition based on a set of users or rules. Layers unlocked cleaner parameter management under high experiment volume. Now, empowering your agents with these tools will help accelerate iteration velocity and improved engineering efficiency, all while maintaining safe and consistent experiment configurations.

Try it out

If you have the Statsig MCP set up, try the below example prompts and workflows to explore the new segment and layers functionality:

• "List all segments, then show details for the segment [segment_name].”
• “Create a layer for shared signup experiment parameters.”
• "Create an experiment testing new signup flow UI and add it to the signup_tests layer."

Learn more in the docs

Statsig MCP Overview.

Abort long-running queries from Metrics Explorer to reduce warehouse load and avoid unnecessary compute usage.

What You Can Do Now

• Prevent long-running queries from tying up warehouse resources
• Avoid accidental full-dataset scans
• Limit the cost impact of exploratory queries

How It Works

Metrics Explorer queries can be canceled after 5 seconds when running on supported warehouse integrations (BigQuery, Databricks, Snowflake, and Athena). Query cancellation currently applies to individual charts and does not yet extend to dashboards.

Impact on Your Analysis

Cancel Queries let you interrupt a run, refine the query, and try again immediately. This reduces unnecessary warehouse usage while keeping exploratory workflows fast and responsive.

What You Can Do Now

• Understand product stickiness out of the box
• Separate growth driven by new vs sustained engagement
• Spot churn and reactivation patterns at a glance

How It Works

Select an event, define a unique unit, and choose a time interval. Lifecycle Charts automatically classify activity by one of four lifecycle states:

• New:
  Active in the current interval with no prior activity within the lookback window (up to one year)
• Resurrected:
  Active in the current interval, not active in the previous interval, but had activity earlier in the lookback window
• Recurring:
  Active in both the current and immediately previous interval, indicating continued engagement.
• Dormant:
  Active in the previous interval but inactive in the current one, highlighting potential churn

Impact on Your Analysis

Lifecycle Charts reveal why usage changes by showing shifts in engagement composition over time. Teams can distinguish growth from retention changes, identify drop-off earlier, and understand product stickiness without building custom retention analyses.

Check out our docs for more information.