Skip to main content
There are two common ways to isolate tenants. Most teams should start with Pattern A.

A - one key, put the user in session_id

1

Share a cached Tex client

deps.py
2

Derive session ids per user + conversation

chat.py
Replace your_llm(...) with your model call. Reuse the same turn format you already store.
The SDK accepts user_id in the constructor, but scopes are per client instance today. Creating one Tex client per end user would waste connection pools. Until per-call user_id ships in SDK 1.2, keep the tenant in session_id.

B - one key per customer org

1

Mint a fresh org when you onboard

signup.py
2

Look up the right client per request

Cache instances in a TTL map for about 1 hour. That keeps warm connections without keeping every customer client forever.

Which pattern to choose

Pattern A

You ship an app on top of Tex. Infrastructure is shared, ops are simpler, and metering stays in your product.

Pattern B

You resell Tex and customers expect their own bill and console.

Shared quota (A only)

Daily quotas are per Tex org. Under Pattern A, every user shares your quota. One noisy tenant can affect everyone. Add these controls in your own app:
  • You track per-user bytes/tokens yourself (usage is on every response).
  • You soft-cap heavy users (for example switch off memory after they consume 10% of your daily budget).
  • You poll tex.usage.today() and degrade gracefully after ~90%.