LLM cost optimization in Austin.

The technical reality of multi-tenant AI spend in Austin.

Questions from Austin buyers.

Which of our tenants are actually losing us money on AI features?

The ones you cannot name yet, which is the problem. Without per-tenant metering, AI spend arrives as one invoice line while revenue arrives per account, so cross-subsidy hides: the median tenant costs you $4 a month in inference while the top decile costs $60 against a $49 plan. The fix starts with attribution: every model call tagged with tenant, feature, and tokens, aggregated into a cost-per-account view next to plan revenue. The findings are predictably skewed (a handful of accounts drive a third of spend, usually through one feature pattern: bulk operations, giant documents, automation loops) and the responses are then business choices made with numbers: usage tiers, fair-use thresholds, feature-level limits, or simply absorbing it knowingly on strategic accounts. We build the attribution layer in week one because every other decision depends on it.

Does multi-tenancy complicate prompt caching, or can we still collect the discount?

You can collect most of it, with one design rule: cache what is shared, isolate what is not. Provider-side prompt caching keys on identical prefixes, so the system prompt, tool definitions, schemas, and product instructions (identical across all tenants) belong in a stable shared prefix that caches superbly across your entire traffic. Tenant-specific context (their documents, their settings) sits after the shared prefix, where per-tenant cache reuse still applies within a tenant's session bursts. What never gets blended is the content itself: caching is a billing optimization on identical text, not shared state, and tenant A's documents are never in tenant B's prompt, cached or otherwise. Products with heavy shared instructions typically recover 40 to 70 percent of input costs through this layering, with isolation untouched, and we verify both properties (hit rate and isolation) in testing.

How should routing tiers map to our pricing tiers?

Loosely, and quality-gated rather than plan-gated, in most cases. The tempting design (cheap model for Starter, frontier for Enterprise) usually misfires: it makes your entry tier feel worse exactly when users are deciding whether to upgrade, and it ties engineering to pricing in ways that hurt both. The design that works: route by request difficulty across all tenants (the easy 70 percent of traffic to the inexpensive model wherever your eval set shows parity, the hard tail to the strong model), then differentiate plans on capacity and capability (usage allowances, feature access, bulk operations, SLAs) rather than on hidden model quality. The exception is an explicit premium capability ('advanced analysis') marketed as such, where the stronger model is the feature. Hidden quality tiers erode trust when discovered, and in Austin's B2B market, they get discovered.

When is the answer to raise prices rather than cut costs?

When the value evidence supports it and the optimization headroom is thin, and a good audit tells you which world you are in. The signals for repricing: per-tenant economics show heavy users extracting outsized value (the feature is load-bearing in their workflow), churn on price-sensitive accounts is low, and your unit costs are already within striking distance of engineered floor (caching, routing, batch all in place). In that world, usage-based pricing or a higher tier captures value that cost-cutting cannot create. The signals for optimizing first: unit costs five times the engineered floor, margin problems concentrated in architecture rather than generosity, and pricing changes that would risk accounts you could keep profitably at the right cost base. Most Austin SaaS we audit needs sequencing rather than either/or: fix the spend first (weeks), then reprice from a defensible cost base (a board conversation with real numbers).