Feature
What is a Feature?
Features are the building blocks of your product offering, they represent the various capabilities of your system. Practically speaking, they typically translate to line items on your pricing page, so we'll use this thinking going forward.
The feature set between plans can vary in terms of what features are available, what configurations are available for a given feature, and what usage limits are enforced. Let's see an example for a fictional AI startup:
Feature | Plan 1 | Plan 2 |
---|---|---|
Feature 1: GPT Tokens | 10,000 /m | 1,000,000 /m |
Feature 2: Available Models | gpt-3 | gpt-3, gpt-4 |
Feature 3: SAML SSO Auth | - | Yes |
You can see how, when modeling this, the table rows naturally translate to features, while the individual cells (plan specific configurations) translate to entitlements.
Using Features
Check out the Get Started guide to see how to create your first features using the OpenMeter SDK.
Features have a system generated Id
and a user defined Key
. Key should be an
easy to understand string that can be used to reference the feature in your
codebase, e.g. gpt_4_tokens. The entitlement access APIs can be used with
feature key too, so you don't have to resolve the Ids before each query.
Features can be archived
, after which no new entitlements can be created for
them, but the existing entitlement are left intact. You can think of this as
deprecating a feature, removing it from the pricing page, or migrating it to a
new name (key). Feature key
has to be unique among active (non archived)
features, but archived features can have the same key as other archived or
active ones.
If you want to track usage for a feature, you can associate a meter with it. The
associated meter will be used to track usage in metered entitlements of the
feature, and it must have either SUM
or COUNT
as its aggregation type. You
can also filter the usage tracked by the meter using the meterGroupByFilter
property. This is useful if you want to share the same meter accross different
features, but want to track and enforce usage separately based on some
differentiating property. When doing this, the meter must have the same group by
keys defined which you want to use for metering.
Property | Description |
---|---|
key | A unique lookup key to help access features in API or web. |
name | A human-readable display name for the feature. |
meterSlug | Optional, Associated meter to measure subject usage. |
meterGroupByFilter | Optional, to filter for a subset of usage in the meter. |
Check our API Docs for detailed descriptions of all feature properties.
Getting Started
Check out the Get Started guide to get started with OpenMeter Entitlements or use the Cloud UI:
Features DashboardExamples
Check out some examples of features:
GPT-4 Tokens
The feature GPT-4 Tokens is used to track the token usage and enforce limits.
Property | Value |
---|---|
key | gpt_4_tokens |
name | GPT-4 Tokens |
meter | tokens_total |
meterGroupByFilter | model=gpt-4 |
Available Models
The feature Available Models is used to determine what models are available for the subject.
Property | Value |
---|---|
key | gpt_models |
name | Available GPT models |
meter | - |
meterGroupByFilter | - |
SAML SSO
The feature SAML SSO enables SAML SSO for the subject.
Property | Value |
---|---|
key | saml_sso |
name | SAML SSO |
meter | - |
meterGroupByFilter | - |