How to Build Per-Customer Usage Billing for Your SaaS with Namespaces

If you're building a SaaS product on top of AI agents or cloud infrastructure, you need to answer a critical question: how do you bill each customer for what they use?

Flat monthly pricing is simple, but it doesn't work when customers have wildly different usage patterns. One customer runs 5 agent sessions a day. Another runs 500. Charging them the same price means you're subsidizing heavy users with light users' money.

Usage-based billing solves this - but building it from scratch takes months. Metering, rate limiting, spending caps, per-customer dashboards, proration, overages... it's an entire billing infrastructure project.

Namespaces give you all of this out of the box.

What Are Namespaces?

A namespace is an isolated billing and resource scope. Think of it as a container for a single customer (or team, or environment) within your SaaS product.

Each namespace gets:

Instead of building all this, you create a namespace for each customer and configure their limits.

The Architecture

Your SaaS Product
         │
         ├── Customer A  ──→  Namespace "customer-a"
         │                     ├── 1,000 credits/month cap
         │                     ├── AI Chat: enabled, 100 req/hr
         │                     ├── Deployment: enabled, no limit
         │                     └── Usage: tracked per service
         │
         ├── Customer B  ──→  Namespace "customer-b"
         │                     ├── 5,000 credits/month cap
         │                     ├── AI Chat: enabled, 500 req/hr
         │                     ├── Deployment: enabled
         │                     └── Code Exec: enabled, 200 req/hr
         │
         └── Customer C  ──→  Namespace "customer-c"
                               ├── 500 credits/month cap
                               ├── AI Chat: enabled, 50 req/hr
                               └── Deployment: disabled

Each customer is completely isolated. Customer A's usage doesn't count against Customer B's quota. Customer C can't access features you haven't enabled for them.

Setting Up Per-Customer Billing

Step 1: Create a namespace for each customer

When a new customer signs up for your SaaS:

Create a namespace with their unique ID, a human-readable name, and the type of environment (production, testing, development). Each gets a unique slug for API access.

Step 2: Configure service access and limits

Each namespace can have individual services configured:

• AI Chat - enable with rate limit of 100 requests per hour
• Workspace (Compute) - enable with rate limit of 50 requests per hour
• Deployment - enable with 20 requests per day
• Web Search - disable entirely for this customer

You can also set per-service credit quotas - "this customer can spend max 200 credits on AI Chat per month."

Step 3: Set spending caps

Three levels of spending control:

1. Global cap - your overall Oblien balance (the floor)
2. Namespace cap - max credits this customer can consume
3. End-user cap - max credits a specific end-user within the namespace can use

If Customer A has a 1,000 credit cap and they hit it, your system returns a "quota exceeded" error. Their agents stop, but Customer B is completely unaffected.

Step 4: Route customer requests through their namespace

When Customer A makes an API call to your product, your backend routes the request through their namespace. Their usage is automatically metered and checked against limits - rate limits, spending caps, and service access all enforced automatically.

Three-Tier Quota System

This is the killer feature for SaaS builders:

┌─────────────────────────────────┐
│  Your Oblien Account             │
│  Balance: 50,000 credits         │
│                                  │
│  ┌────────────────────────────┐  │
│  │ Namespace: Customer A      │  │
│  │ Cap: 5,000 credits/month   │  │
│  │                            │  │
│  │ ┌──────────────────────┐   │  │
│  │ │ End-user: Alice      │   │  │
│  │ │ Cap: 500 credits/mo  │   │  │
│  │ └──────────────────────┘   │  │
│  │ ┌──────────────────────┐   │  │
│  │ │ End-user: Bob        │   │  │
│  │ │ Cap: 500 credits/mo  │   │  │
│  │ └──────────────────────┘   │  │
│  └────────────────────────────┘  │
│                                  │
│  ┌────────────────────────────┐  │
│  │ Namespace: Customer B      │  │
│  │ Cap: 10,000 credits/month  │  │
│  └────────────────────────────┘  │
└─────────────────────────────────┘

• Alice can't use more than 500 credits
• Customer A (including all their end-users) can't exceed 5,000 credits
• Your total spend can't exceed your balance of 50,000 credits

Three layers of protection against runaway costs.

Usage Analytics Per Customer

Every namespace automatically tracks:

• Total credits consumed - broken down by service (AI, compute, deployment)
• Daily usage - credit consumption per day
• Service breakdown - which services are costing the most
• Request counts - API calls per service per time period
• Active periods - when the customer is most active

You get this data through the API to build your customer-facing dashboards, or use Oblien's built-in analytics views.

Build your pricing page from real data

After running for a month, you'll know:

• Average customer uses 800 credits/month → price your "Basic" plan at 1,000 credits
• Active customer uses 3,000 credits/month → price your "Pro" plan at 5,000 credits
• Power user uses 10,000+ credits/month → price your "Enterprise" plan at 15,000 credits

Data-driven pricing instead of guesswork.

Rate Limiting Per Customer

Each namespace can have per-service rate limits:

Rate limit periods are configurable: per minute, per hour, or per day.

When a customer hits their rate limit, they get a clear error with the reset time. No impact on other customers.

Pricing Models You Can Build

Model 1: Pay per agent session

Each AI agent session consumes credits based on compute time and LLM tokens. Customers buy credit packs.

Model 2: Tiered subscription + overage

Monthly subscription includes a credit allowance. Overages billed at a per-credit rate.

Model 3: Per-seat + usage

Charge per team member for access, plus usage-based compute.

Each team member gets their own end-user quota within the namespace. The team's namespace has an overall cap. You charge the team $10/seat/month for access, plus the credit consumption at your markup.

Model 4: Free tier with paid upgrades

Namespace starts with limited credits and rate limits. Upgrade enables higher limits.

Free tier: 100 credits/month, 10 AI requests/hour, no deployment. Paid tier: 5,000 credits/month, 500 AI requests/hour, deployment enabled.

Audit Trail

Every namespace action is logged:

• Namespace created/updated/deleted
• Service configuration changes
• Rate limit modifications
• Quota changes
• Usage spikes and cap hits

Each log entry includes:

• Timestamp
• IP address
• User agent
• Country (via Cloudflare)
• Fingerprint
• Action details

This gives you a complete audit trail for compliance, debugging, and customer support.

Implementation Timeline

Compare to building from scratch:

• Custom metering system: 4-6 weeks
• Rate limiting infrastructure: 2-3 weeks
• Usage analytics: 3-4 weeks
• Multi-tier quotas: 2-3 weeks
• Audit logging: 1-2 weeks
• Total: 12-18 weeks vs 5 weeks

Who Uses This

AI SaaS products

You sell AI agent access to customers. Each customer gets a namespace with configured AI services, credit caps, and rate limits. Customers see their usage in your dashboard.

Developer tools

You sell infrastructure APIs. Each customer gets a namespace with API service access and per-endpoint rate limits. Usage tracked for billing.

Platform products

You run a marketplace where users build and deploy apps. Each user gets a namespace with compute quotas. Heavy users are automatically throttled without affecting the platform.

Enterprise internal tools

Different departments get different namespaces. Engineering gets high compute limits, marketing gets AI chat access, finance gets restricted access with audit logging.

Summary

Per-customer billing requires:

1. Isolation - each customer's usage tracked independently ✅
2. Metering - every API call and compute minute recorded ✅
3. Caps - prevent runaway costs with spending limits ✅
4. Rate limiting - per-service, per-customer throttling ✅
5. Analytics - usage dashboards for you and your customers ✅
6. Audit trail - full logging for compliance ✅

Namespaces give you all six. Create a namespace per customer, configure limits, and start billing.

Related reading → How to Give Each User Their Own Sandbox | Oblien Documentation