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
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
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 (
usageis 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%.

