Stigg now provides dedicated estimation endpoints for usage events and usage measurements.

The estimation uses the same credit calculation logic as actual usage consumption, but does not ingest the event or deduct credits.

For each relevant credit currency, the response includes:

• estimatedCost — The number of credits the usage would consume
• currentBalance — The customer’s current credit balance
• balanceAfterEstimate — The projected balance after the estimated consumption
• wouldOverdraft — Whether the operation would take the balance below zero
• breakdown — A per-feature breakdown of the estimated credit cost
• warnings — Any limitations or unsupported calculations encountered during estimation

Estimations support both customer-level and resource-level usage, including custom event dimensions.

⭐️ Why It Matters

For products with dynamic pricing models, such as LLM workflows, media rendering, or multi-step API pipelines, the credit cost of an action isn't always known up front.

Credit cost estimation enables you to:

• Build pre-flight confirmation flows: Show customers an accurate estimate before launching an expensive task (e.g., "This image generation will cost ~15 credits. Proceed?").
• Prevent mid-task overdrafts: Evaluate wouldOverdraft to block heavy jobs before execution if a user lacks sufficient credits.
• Eliminate calculation drift: Ensure UI estimates perfectly match actual deductions by relying on Stigg's engine rather than re-implementing billing math in your frontend.

⚠️ Current Limitations

1. Aggregation types: For event-based estimation, COUNT and SUM aggregations are supported. UNIQUE and MAX are not currently supported as they rely on historical aggregation state.
2. Routing: Estimation endpoints are served through the standard Stigg REST API and are not currently routed via the Edge.

📦 Availability

Credit cost estimation is available now through the Stigg REST API and the following REST SDK versions or later:

• TypeScript: v0.1.0-beta.43
• Python: v0.1.0-beta.38
• Go: v0.1.0-beta.39
• Java: v0.1.0-beta.37
• Ruby: v0.1.0-beta.41

The reportUsage response now includes a consumed field, showing exactly how many credits were deducted by each individual usage report.

✨ What’s New

Previously, the reportUsage response returned the customer’s updated credit usage, but it did not clearly indicate how many credits were consumed by that specific request.

With this update, the credit object returned by reportUsage now includes:

• consumed — The number of credits deducted by this specific reportUsage call
• currentUsage — The customer’s total credit usage across the wallet

Idempotency handling: For duplicate/retry requests with the same idempotency key, consumed returns 0. This makes it effortless to verify that a retried request did not trigger a duplicate credit deduction.

⭐️ Why It Matters

While tracking the total balance is necessary for access control, backend applications often need to log or display the direct impact of individual operations—especially when credit costs are dynamic (e.g., variable LLM token consumption).

The consumed field enables you to:

• Display per-action costs: Show end users instant feedback on how many credits a specific task, AI prompt, or API request consumed.
• Audit idempotency instantly: Safely confirm whether a network retry resulted in a fresh deduction or was recognized as a duplicate (consumed: 0).
• Simplify logging & reconciliation: Debug usage calculations and keep your internal database or audit logs perfectly in sync without manually diffing previous balance states.

📦 Availability

The consumed field is available now in the reportUsage response across Stigg’s REST, GraphQL APIs, and server SDKs:

REST-based SDKs

• TypeScript: v0.1.0-beta.49
• Python: v0.1.0-beta.43
• Go: v0.1.0-beta.44
• Java: v0.1.0-beta.41
• Ruby: v0.1.0-beta.46

GraphQL-based SDKs

• Node.js: v4.50.0
• Python / Go / .NET: v6.18.0
• Java: v6.19.0
• Ruby: v6.16.0

We’ve launched a new Spotlight search experience that makes it faster to navigate across Stigg and jump directly to the resources you need.

✨ What’s New

Press CMD + K (or Ctrl + K) anywhere in the Stigg app to open Spotlight.

Instead of clicking through sidebar menus and paginated tables, you can instantly search for and jump to resources across your entire workspace, including:

• Customers & Subscriptions: Find specific accounts, active plans, or billing states.
• Product Catalog: Jump straight to feature flags, entitlements, plans, and add-ons.
• Developer Resources: Quickly access environment settings, API keys, and webhooks.

This new experience replaces the previous command-bar component with a faster, Stigg-native search engine designed for speed.

⭐️ Why It Matters

As your Stigg environment grows with hundreds of customers, feature, and plan variations, navigating via sidebars slows down your workflow.

Spotlight enables you to:

• Keyboard-first navigation: Jump between any page or resource in seconds without taking your hands off the keyboard.
• Frictionless workflow: Find customer accounts or configuration screens instantly without manually searching through list views.
• Built for scale: Move quickly even when managing complex, multi-environment setups.

📦 Availability

The new Spotlight search is available now for all customers.

Press CMD + K (macOS) or Ctrl + K (Windows/Linux) anywhere in the Stigg app to try it out.

All Stigg REST SDKs now route requests through edge.api.stigg.io by default, improving latency while keeping your existing integrations unchanged.

✨ What's New

REST SDKs now send requests through edge.api.stigg.io, which transparently proxies requests to api.stigg.io.

For supported endpoints, requests are served directly from the Edge, reducing latency without requiring any changes to your application or SDK configuration.

The following endpoints are currently served directly from the Edge:

• GET /api/v1/customers/{customerId}/entitlements/check
• GET /api/v1/customers/{customerId}/entitlements

⭐️ Why It Matters

Entitlement checks sit directly on your application's request path. Every millisecond saved on an entitlement check translates directly to a faster, more responsive app for your users.

• Zero-config performance: Lower latency out of the box without needing to configure custom routing, edge nodes, or caching layers.
• 100% backward compatible: You don't need to update API base URLs, implement custom proxy logic, or change how you instantiate Stigg SDK clients.
• Global low latency: Entitlements are evaluated closer to where your traffic originates.

📦 Availability

The Edge routing is available in the following REST SDK versions (or later):

• TypeScript: v0.1.0-beta.34
• Python: v0.1.0-beta.30
• Go: v0.1.0-beta.31
• Java: v0.1.0-beta.29
• Ruby: v0.1.0-beta.33

Simply upgrade your SDK dependency to the latest version to automatically benefit from Edge routing.

The Stigg AI Terminal lets you connect your AI coding assistant to Stigg in a single command. It signs you in, configures the MCP server, installs Stigg's AI skills, and gets your coding agent ready to build pricing, entitlements, and usage tracking using natural language.

✨ What's New

Getting started with Stigg and AI no longer requires manual setup.

Run: npx @stigg/terminal


The AI Terminal automatically handles the heavy lifting:

• Instant authentication: Authenticates your local machine directly to your Stigg account.
• MCP configuration: Automatically connects the Stigg MCP server to your local AI coding environment.
• Skill deployment: Installs Stigg's AI skills, embedding deep product knowledge and integration best practices right into your agent's memory context.
• Environment detection: Automatically detects supported AI clients, including Claude Code, Cursor, VS Code, Claude Desktop, and more.

Once setup is complete, your coding agent can immediately start interacting with your Stigg environment using natural language.

⭐️ Why It Matters

Instead of looking up API endpoints or configuring Stigg manually, you can simply describe what you want to build.

For example:

• Architect packaging: "Create a Premium tier plan with seat-based limits and a 14-day trial."
• Manage credits: "Configure a wallet system with soft limits for API consumption."
• Handle provisioning: "Provision a new enterprise customer and apply an add-on."
• Enforce constraints: "Add code to report usage on the request path and enforce real-time credit checks."

By combining the Stigg MCP server with explicit AI skills, your coding assistant gets both the tools to modify your Stigg environment and the contextual product logic required to do it securely and efficiently.

📦 Availability

The Stigg AI Terminal is available today in Public Beta. You can spin it up immediately by running:
npx @stigg/terminal


You can now consume credits directly in Stigg without requiring an active subscription. This allows you to use Stigg as a standalone credits engine for tracking balances, enforcing entitlements, and governing usage, while managing subscriptions entirely in your own platform.

✨ What's New

Previously, consuming credits through reportUsage or reportEvent required customers to have an active subscription with credit-based entitlements. With this release, credits can now be consumed directly against customer credit grants, completely bypassing the subscription layer.

This enables two common use cases:

• Standalone credits engine: Use Stigg as a dedicated credits engine while managing subscriptions in your own billing system.
• Hybrid integration: Integrate an existing credit model with Stigg to track balances, consume credits, and enforce entitlements.

The release includes:

• Direct UI & API consumption: Grant promotional or paid credits using the existing grantCredit functionality and consume directly against those grants.
• Full ledger visibility: Complete visibility in the credit ledger for every credit grant and consumption event.
• New SDK capabilities: Call getCreditEntitlement, consumeCredits, and consumeCreditsAsync for customers without any active subscription.

⭐️ Why It Matters

Not every product needs subscription management. Many teams already have an existing billing platform or custom subscription system and simply need a reliable way to manage credits and enforce usage.

Direct credit consumption enables you to:

• Decouple credits from subscriptions: Build usage-based products without coupling credits to subscription lifecycles.
• Keep your billing platform: Retain your existing subscription or billing platform while offloading the consumption logic.
• Audit every single action: Track every credit grant and consumption event reliably in the Stigg ledger.

📦 Availability

Direct credit consumption is available in the Stigg app and across our developer ecosystem, including GraphQL, REST, and our associated SDKs:

REST-based SDKs

• TypeScript: v0.1.0-beta.36
• Python: v0.1.0-beta.31
• Go: v0.1.0-beta.33
• Java: v0.1.0-beta.31
• Ruby: v0.1.0-beta.35

GraphQL-based SDKs

• Node.js: v4.48.0
• Python / Go / .NET: v6.16.0
• Java: v6.17.0
• Ruby: v6.14.0

You can now configure credit entitlements with soft limits, allowing customers to continue accessing your product even after their credit balance reaches zero.

🆕 What's New

Until now, credit entitlements enforced a hard limit once a customer's credit balance was depleted.

With this release, you can now choose whether a credit entitlement is enforced as a hard limit or a soft limit directly from the plan and add-on editor.

When a credit entitlement is configured as a soft limit:

• Customers can continue consuming credits after their balance is exhausted
• Access checks continue to return access granted
• Stigg surfaces a soft-limit indication so your application can distinguish between available credits and overage usage

This gives you greater flexibility in how you manage credit-based plans and overage experiences.

⭐️ Why It Matters

Not every usage-based business wants to block customers the moment they run out of credits.

Soft limits enable you to:

• Allow overages while maintaining visibility into credit consumption
• Prevent service interruptions for high-value customers
• Create usage-based plans that balance flexibility with control
• Build grace-period and overage billing experiences

Whether you're monetizing API calls, AI requests, or platform usage, soft limits let you decide when credit balances should enforce access and when they should simply act as a billing signal.

📦 Availability

Soft limits for credit entitlements are available in the Stigg app and across our developer ecosystem, including GraphQL, REST, and our associated SDKs:

REST-based SDKs

• Python: v0.1.0-beta.27
• Go: v0.1.0-beta.28
• Java: v0.1.0-beta.26
• Ruby: v0.1.0-beta.30

GraphQL-based SDKs

• Node.js: v4.45.0
• Python / Go / .NET: v6.13.0
• Java: v6.14.0
• Ruby: v6.11.0

We've enhanced credit ingestion to support real-time balance updates. Applications can now deduct credits synchronously and receive an updated balance immediately in the response, enabling real-time usage experiences without waiting for ingestion to complete.

🆕 What's New

Previously, credits were consumed through reportEvent, which processes usage asynchronously. As a result, credit balances were only updated after ingestion, introducing a delay of several seconds before the latest balance was available.

With this release, reportUsage now supports synchronous credit deductions.

When usage is reported:

• Credits are deducted immediately
• The updated balance is returned in the reportUsage response
• Applications can display current credit balances without waiting for ingestion pipelines to complete

⭐️ Why It Matters

Many usage-based products rely on real-time credit visibility and enforcement.

With synchronous deductions, you can:

• Show customers accurate credit balances immediately after usage occurs
• Enforce credit limits in real time
• Build AI, API, and consumption-based products without balance update delays
• Deliver a more responsive usage experience

Whether you're charging credits per API call, AI request, or other metered action, customers can now see the impact of their usage instantly.

⚒️ Getting Started

Use reportUsage to report and consume credits synchronously.

The updated balance is returned directly in the API response and is supported by the latest Stigg SDKs.

📦 Availability

To consume credits synchronously and receive updated balances in the reportUsage response, upgrade to one of the following SDK versions:

REST-based SDKs

• Python: v0.1.0-beta.29
• Go: v0.1.0-beta.30
• Java: v0.1.0-beta.28
• Ruby: v0.1.0-beta.32

GraphQL-based SDKs

• Node.js: v4.46.0
• Python / Go / .NET: v6.14.0
• Java: v6.15.0
• Ruby: v6.12.0

We're excited to introduce significant updates to our credit tracking UX, making it easier than ever for you and your customers to understand exactly how credits are allocated and consumed.

With a redesigned usage overview and a new searchable group-by filter for usage history, you now have complete clarity and effortless control over your credit data.

🆕 What’s new?

• Granular Credit Overviews: The usage overview section has been overhauled to provide deep visibility into your credit pools. You can now see an explicit breakdown of granted credits between recurring and one-time credit grants. We’ve also enhanced the UI to provide immediate clarity on the exact number of credits used, credits remaining, and the timeline for the next reset period.
  
  
  

• Searchable Group-by Dimensions: Analyzing usage history is now much faster. The "Group by" filter in the usage history view now features a built-in search bar. Instead of scrolling through an endless list of properties when your reported usage events include a massive amount of metadata, you can simply type to find the exact dimension you want to use to break down your data.

  
  

We're excited to introduce a major update to credit tracking: Credit usage breakdown by dimensions of reported usage events. 

You can now slice-and-dice credit consumption history using the custom dimensions attached to your usage events - such as user ID, workspace ID, LLM model type, and more - giving you and your customers unprecedented visibility into how credits are spent.

🆕 What’s new?

Previously, Stigg only allowed you to view credit usage history at the feature level (i.e., which feature drew down from the credit pool).

With this update, you can drill down into the granular event attributes behind those feature drawdowns. Furthermore, you can break down consumption by multiple dimensions simultaneously - for instance, grouping usage by both Feature ID and User ID to see exactly which team member consumed the most credits on a specific feature.

To ensure performance remains lightning-fast even with high volumes of granular data, all breakdown results are fully paginated.

⭐️ Why it matters

• End-Customer Transparency: Build trust by showing your customers exactly who or what is driving up their bill (e.g., "User A spent 400 credits on gpt-4o queries").
• Internal Troubleshooting & BI: Equips your customer success and engineering teams with the granular data needed to debug unexpected usage spikes or run deep business intelligence analyses on credit utilization.

🍿 See it in action

Via the Stigg API & SDKs - You can request dimension-based breakdowns programmatically. Simply pass the groupBy array in your credit usage history queries.

In the Stigg App - when viewing a customer's credit pool in the Stigg dashboard, you can now toggle custom dimension filters to instantly generate usage charts and breakdown tables based on your custom event metadata:

📦 Availability

Credit usage breakdown by event dimensions is available immediately for all customers. You can access it directly within the Stigg app UI or query it programmatically via the latest versions of the Stigg API and SDKs:

REST-based SDKs

• TypeScript: v0.1.0-beta.15
• Python: v0.1.0-beta.13
• Go: v0.1.0-beta.15
• Java: v0.1.0-beta.13
• Ruby: v0.1.0-beta.15

GraphQL-based SDKs

• Node.js: v4.43.0
• Python: v6.11.0
• Go: v6.11.0
• Java: v6.11.0
• .NET: v6.11.0
• Ruby: v6.9.0