Why BYO-Model AI Orchestration Beats Paying AI Markup — A Builder's Guide

Most managed AI platforms operate on a straightforward but rarely advertised model: they buy API access from providers like OpenAI, Anthropic, Google, or Mistral at standard rates, then resell that inference to you at a markup — typically somewhere between 2× and 5× the underlying provider cost. The markup is baked into per-token pricing, bundled into seat tiers, or obscured inside a "compute credits" abstraction that makes direct comparison nearly impossible.

This isn't inherently dishonest — the platform is providing orchestration, tooling, and support on top of raw inference. But the problem is opacity. Teams rarely model the true cost of AI calls at the platform layer versus going direct, and by the time usage scales, switching costs feel prohibitive.

Consider what that markup compounds to over time. If your team is running 50 million tokens per month through a platform charging 3× provider rates, you are paying for roughly 100 million tokens you never received. That delta funds the vendor's margin, not your product. At scale, this is not a rounding error — it is a structural cost disadvantage baked into your architecture.

The less-discussed dimension is control. When a platform owns the model routing, you don't always know which model version handled a given request, whether the provider changed something upstream, or whether your data transited a third-party inference layer you didn't explicitly approve. For teams with compliance obligations — SOC 2, GDPR, HIPAA-adjacent use cases — that ambiguity is a liability, not a feature.

"Bring Your Own Model" and "Bring Your Own Keys" are terms that get used loosely, so it's worth being precise about what they mean in a production orchestration context — and what they don't.

BYO-Keys means your API credentials for each AI provider live in your environment, not the platform vendor's. Every inference call is authenticated with your keys, billed directly to your provider account, and subject to your provider agreements — not a resale arrangement. The platform is purely an orchestration layer; it never touches the billing relationship between you and the model provider.

BYO-Model goes further. It means the orchestration platform is provider-agnostic: you can point it at OpenAI, Anthropic, a self-hosted Ollama instance, a fine-tuned model on a private endpoint, or any other inference API — and the platform routes, chains, and manages workflows against whichever model you configure. You are not locked into a curated model menu chosen by the vendor.

Together, these two properties give you three things that matter operationally:

• Cost transparency. You see exactly what you're paying because the bill comes directly from the provider. There is no markup layer to reverse-engineer.
• Model flexibility. You can swap providers, test new models, or run different models for different workflow steps — without waiting for the platform vendor to add support.
• Data sovereignty. Your keys, your contracts, your audit trail. The orchestration platform never holds credentials or sits in the billing path of your inference spend.

This architecture also has compliance implications. When your keys authenticate directly to the provider, you can point to a clean chain of custody for every AI call — which matters when a compliance auditor asks who had access to what, and when.

DAVE supports 8 AI provider types out of the box — not a curated shortlist, but a broad enough surface to cover the realistic range of how serious teams actually deploy AI in production workflows today.

That range matters because real-world AI architectures are rarely mono-provider. A team might use a frontier model for complex reasoning steps, a smaller open-weights model for high-volume classification tasks, a self-hosted instance for data that can't leave the network perimeter, and a specialized embedding model for retrieval-augmented generation. Forcing all of that through a single provider — or through a platform that only supports one or two — is an architectural constraint masquerading as a product decision.

With DAVE's provider model:

• Each workflow step can target a different provider and model.
• Provider credentials are scoped per-tenant — in a multi-tenant deployment, Tenant A's OpenAI key never touches Tenant B's workflow.
• Adding or rotating provider credentials doesn't require a platform vendor support ticket — it's configuration you own.
• You can run entirely on self-hosted or open-weights models if your compliance posture requires it, with no platform-level dependency on any external inference service.

The practical upshot: when a new model drops that's materially better for your use case, you can evaluate and adopt it on your timeline, not the vendor's roadmap. That's what "Your AI" means in practice.

If you're building a product on top of an AI orchestration platform — or running multiple internal teams, business units, or client environments through one — multi-tenancy is not a nice-to-have. It's the architectural property that determines whether your platform is production-grade or a liability.

The baseline expectation is logical isolation: Tenant A cannot access Tenant B's data, workflows, credentials, or outputs. But logical isolation at the application layer is not sufficient for teams with real compliance obligations. The question to ask is: where does encryption happen, and who holds the keys?

DAVE implements per-tenant encryption — meaning data at rest is encrypted with keys scoped to each individual tenant, not a shared platform key. This has concrete implications:

• A compromise of one tenant's encryption context does not expose other tenants' data.
• Tenant offboarding is cryptographically clean — key rotation or deletion renders that tenant's data unreadable without application-layer deletion dependencies.
• Audit trails are tenant-scoped, which simplifies compliance reporting for individual customers or business units.

DAVE also ships with SOC 2 and GDPR modes — not as marketing checkboxes, but as configurable runtime behaviors that affect data retention, logging, and processing boundaries. Combined with OAuth2/OIDC SSO, you get an identity and access model that integrates with your existing IdP rather than requiring a parallel credential store.

For teams evaluating AI orchestration platforms: if a vendor can't clearly articulate where per-tenant encryption happens and who controls the keys, that's a gap worth probing before you put production workloads on their platform.

Self-hosting an AI orchestration platform used to mean significant operational overhead — custom infrastructure, bespoke deployment scripts, and a dedicated platform engineering investment before you could run a single workflow. That calculus has shifted.

DAVE runs on any Linux VPS or managed cloud environment. The stack is NestJS 11 / Next.js 16 / PostgreSQL 16 — a modern, well-understood combination with a large talent pool, mature tooling, and no exotic runtime dependencies. If your team can operate a Node.js application and a Postgres database, you can operate DAVE.

The economics of self-hosting in this context break down into three buckets:

1. Infrastructure cost. You pay for compute and storage at commodity cloud or VPS rates, not at SaaS platform margins. For most teams, this is materially lower than equivalent managed platform pricing at any meaningful usage volume.
2. Operational cost. This is the real variable. Self-hosting requires someone to own deployments, upgrades, and incident response. For teams with existing DevOps capacity, this is incremental. For teams without it, it's a genuine consideration — though DAVE's conventional stack minimizes the specialist knowledge required.
3. Avoided markup. As covered above, BYO-keys means your AI inference spend goes directly to providers. At scale, the avoided markup alone can dwarf the infrastructure cost of self-hosting.

A useful proof point: voolama — the company behind DAVE — runs its own production infrastructure on DAVE. That's not a marketing claim; it's a statement about operational confidence in the platform's production readiness. When the builders eat their own cooking, the incentive to keep the stack stable and operable is direct.

Whether you're evaluating DAVE or any other AI orchestration platform, these are the questions worth getting clear answers to before you commit architecture decisions — and budget — to a vendor relationship.

• Who holds my AI provider credentials? Are my keys stored in the vendor's environment, or do they stay in mine? If the vendor holds keys, what is their key management and access control model?
• How is AI inference billed? Am I billed directly by the provider, or does the platform resell inference? If the latter, what is the markup, and is it disclosed per-model?
• Which AI providers and models can I use? Is the model menu fixed by the vendor, or can I bring any provider with a compatible API? Can I run self-hosted or open-weights models?
• How is multi-tenant data isolated? Is isolation logical (application-layer) or cryptographic (per-tenant encryption)? Who controls the encryption keys?
• What compliance modes are available? Does the platform have documented SOC 2 and GDPR configurations, or is compliance left entirely to the operator?
• What does self-hosting look like? Can I run this on my own infrastructure? What are the runtime dependencies, and what operational expertise is required?
• What is the API surface? How many endpoints does the platform expose, and how complete is the documentation? A thin API means limited automation and integration flexibility.
• Does the vendor run on their own platform? Dogfooding is a meaningful signal of production confidence. Ask directly.

These questions don't have universally "correct" answers — the right answer depends on your team's scale, compliance posture, and operational capacity. But a vendor who can't answer them clearly is telling you something important about the maturity of their platform and the transparency of their business model.

DAVE's answers: BYO-keys (your credentials, your provider accounts), zero AI markup, 8 provider types with full BYO-model support, per-tenant encryption, SOC 2 and GDPR modes, self-hostable on any Linux VPS, 246 REST endpoints, and voolama runs on DAVE in production. That's the baseline we hold ourselves to — and the baseline worth demanding from any platform you're seriously evaluating.