🔓 SF Tech Week AI Track: The Open vs Closed Source Debate Gets Real

Just came from the “Foundation Models: Open vs Closed Source Strategy” panel at SF Tech Week. The debate is no longer theoretical - enterprises are making real decisions with real money.

The Panel Setup

Panelists:

  • CTO from Fortune 500 healthcare company (using closed models)
  • VP Engineering from fintech startup (all-in on open source)
  • AI researcher from major lab (neutral perspective)

The tension was immediate.

Key Data That Surprised Me

41% of enterprises are INCREASING open-source model usage in 2025

Source: CB Insights Foundation Model Divide report

Even more interesting:

41% willing to switch from closed to open if performance matches

That’s not “maybe someday” - that’s active evaluation happening RIGHT NOW.

94% of organizations using 2+ LLM providers

Translation: Nobody’s going all-in on one approach. Everyone’s hedging.

The Healthcare CTO’s Argument (Pro-Closed)

“We serve patients. We cannot afford model hallucinations or compliance risks.”

Their rationale:

  • Safety: Closed models like Claude/GPT-4 have extensive safety testing
  • Compliance: HIPAA, FDA regulations require vetted systems
  • Support: When things break, they need someone to call
  • Liability: If AI makes a medical error, they need a vendor to share liability

Cost: $2M/year in API fees
Alternative cost if self-hosting open source: $800K infrastructure + $1.2M engineering

Break-even… but risk profile different

The Fintech VP’s Counter (Pro-Open)

“We’re building competitive advantage. Can’t do that with APIs everyone else has.”

Their wins with open source:

  • Customization: Fine-tuned Llama 3 on proprietary financial data
  • Data sovereignty: All training data stays internal (regulatory requirement)
  • Cost at scale: Processing 10M documents/month, API costs would be $500K vs $80K self-hosted
  • Competitive moat: Their model understands their specific domain better than GPT-4

Started with Llama 2, now on Llama 3.1 405B
Total investment: $400K GPU costs + 2 ML engineers

The Data I’m Taking Back to My Team

From the panel and CB Insights research:

Open source preference correlates with competitive advantage:

  • Companies where AI is core differentiator: 40% more likely to use open source
  • Companies using AI for efficiency: prefer closed source APIs

Token cost compression:

  • OpenAI pricing down 10x since 2023
  • Makes closed source more viable for high-volume use cases
  • BUT: Still doesn’t solve data sovereignty or customization

Hybrid strategy dominates:

  • Closed source for customer-facing features (safety-critical)
  • Open source for internal tools (cost + customization)
  • Open source for R&D (experimentation without API costs)

My Questions for This Community

We’re an engineering team of 45, building B2B SaaS. Currently 100% on Claude/GPT-4 APIs.

Considering open source for:

  1. Document processing pipeline (high volume, cost sensitivity)
  2. Internal code completion (already paying for Copilot)
  3. Customer support email triage (medium risk)

Should we:

  • A) Stay on closed APIs (easier, less risk)
  • B) Hybrid approach (open for internal, closed for customer-facing)
  • C) Invest in open source infrastructure now (future-proofing)

Resources needed for option B or C:

  • 1-2 ML engineers ($300K/year fully loaded)
  • GPU infrastructure ($50K-200K depending on approach)
  • 3-6 months setup time

Our current API costs: $180K/year and growing 40% Q/Q

At what scale does open source make sense?

Sources:

  • SF Tech Week “Foundation Models Strategy” panel (Day 3)
  • CB Insights Foundation Model Divide report 2025
  • Hatchworks Open vs Closed LLMs Guide 2025
  • Panel: healthcare CTO, fintech VP Engineering, AI researcher

@eng_director_luis This hits close to home - we went through this exact decision 8 months ago. Spoiler: We chose hybrid (option B) and haven’t looked back.

Our Journey: API-Only → Hybrid

January 2025: 100% on OpenAI APIs, burning $25K/month
March 2025: Launched internal open-source infrastructure
October 2025: Hybrid approach saving $15K/month (60% cost reduction on shifted workloads)

Let me break down what we learned.

What We Moved to Open Source

:white_check_mark: Document processing pipeline

  • Was: GPT-4 API processing 2M pages/month
  • Now: Fine-tuned Llama 3 70B on our own infrastructure
  • Savings: $18K/month → $4K/month (infrastructure + compute)
  • Quality: Actually BETTER because we fine-tuned on our document types

:white_check_mark: Internal developer tools

  • Code review automation
  • Documentation generation
  • Test case generation
  • Savings: $5K/month → $1K/month
  • Added benefit: No rate limits, faster iteration

:white_check_mark: Email/ticket triage

  • Customer support classification
  • Routing and prioritization
  • Savings: $8K/month → $2K/month

What We KEPT on Closed APIs

:cross_mark: Customer-facing chatbot

  • Still on Claude (this conversation is proof it works well!)
  • Reason: Safety, reliability, user experience
  • Cost: $15K/month, but worth it for brand reputation

:cross_mark: Compliance-critical workflows

  • Contract analysis
  • Regulatory document review
  • Reason: Need vendor SLA and liability sharing

The Real Costs Nobody Talks About

Infrastructure: $8K/month AWS (mix of on-demand + reserved instances)
ML Engineers: We hired 1 senior ML engineer ($200K/year = $16.6K/month)
Setup time: 4 months from decision to first production workload
Ongoing maintenance: ~20% of ML engineer’s time

Total open source cost: $8K infra + $3.3K eng time + $4K compute = $15.3K/month
Replaced API costs: $31K/month
Net savings: $15.7K/month = $188K/year

ROI positive after month 11 (accounting for setup time and hiring costs).

Technical Architecture We Landed On

Open source stack:

  • Llama 3.1 70B (most workloads)
  • Llama 3.1 405B (complex reasoning, only when needed)
  • Mistral 7B (fast, cheap tasks)
  • vLLM for inference (fast, efficient)
  • LoRA fine-tuning for customization

Deployment:

  • AWS EC2 P4d instances (8x A100 GPUs)
  • Reserved instances (40% cost savings vs on-demand)
  • Auto-scaling for variable load

Closed source stack:

  • Anthropic Claude for customer-facing
  • OpenAI GPT-4 for edge cases and evaluation
  • Fallback mechanism: If open model fails, fall back to API

The Hybrid Decision Framework

We built a simple decision tree:

Use OPEN SOURCE if:

  • High volume (>1M tokens/month per use case)
  • Customization needed (domain-specific fine-tuning)
  • Data can’t leave infrastructure (compliance)
  • Latency critical (self-hosted = faster)
  • Cost-sensitive workload

Use CLOSED APIs if:

  • Customer-facing (brand risk)
  • Safety-critical (medical, legal, financial advice)
  • Low volume (<500K tokens/month)
  • Need cutting-edge capabilities (closed still leads on benchmarks)
  • Small team (can’t support ML infrastructure)

Answering Your Questions Directly

At what scale does open source make sense?

Rule of thumb: If you’re spending >$10K/month on APIs for workloads that could be open source, investigate.

Your $180K/year ($15K/month) is right at the inflection point.

Should we do hybrid?

Yes, if:

  • :white_check_mark: You can hire/allocate 1 ML engineer (doesn’t need to be full-time initially)
  • :white_check_mark: Your API costs are >$10K/month and growing
  • :white_check_mark: You have high-volume, repetitive workloads (document processing = perfect fit)
  • :white_check_mark: You’re comfortable with 4-6 month investment period before ROI

No, if:

  • :cross_mark: Team is <20 people (too small to justify)
  • :cross_mark: You’re pre-PMF (focus on product, not infrastructure)
  • :cross_mark: No one on team has ML ops experience (hiring is hard)

The Real Win: Strategic Flexibility

Beyond cost savings, the biggest win is optionality.

Before: Locked into OpenAI/Anthropic pricing and capabilities
Now: Can negotiate from position of strength, can switch models as better ones emerge, can customize for competitive advantage

When OpenAI raised prices 20% in June 2025, we shrugged. We’d already moved 60% of workloads off their platform.

My Recommendation for You

Phase 1 (Months 1-2): Evaluate and hire

  • Hire 1 ML engineer (or contract initially)
  • Benchmark open models on your actual workloads
  • Calculate total cost of ownership (not just infrastructure)

Phase 2 (Months 3-4): Pilot one use case

  • Start with document processing (your highest volume)
  • Self-host Llama 3.1 70B
  • Run in parallel with existing API pipeline
  • Compare quality and costs

Phase 3 (Months 5-6): Scale if successful

  • Move additional workloads
  • Build monitoring and observability
  • Establish fallback mechanisms

Phase 4 (Month 7+): Optimize

  • Fine-tune models on your data
  • Optimize infrastructure costs
  • Evaluate newer models as they emerge

Don’t go all-in on open source. Hybrid is the way.

Sources:

  • Our internal architecture and cost data (8 months of hybrid deployment)
  • TechTarget Attributes of Open vs Closed AI 2025
  • Senior Executive Open vs Closed AI 2025

Security perspective on open vs closed - this is where the debate gets REALLY interesting.

The Security Argument (Both Sides Make Good Points)

Just attended the “AI Security: Open Source vs Closed Models” workshop at SF Tech Week.

The Closed Source Security Argument:

  • Proprietary models undergo extensive red-teaming before release
  • Vendors have security teams monitoring for abuse
  • Safety filters and guardrails baked in
  • Liability and insurance coverage

The Open Source Security Argument:

  • Transparency = community can audit for vulnerabilities
  • No “black box” - you know exactly what the model can/can’t do
  • No third-party API = smaller attack surface
  • Data never leaves your infrastructure

Both arguments are valid. The answer depends on your threat model.

Where Open Source WINS on Security

1. Data sovereignty and privacy

Closed APIs = your data goes to third-party servers

Even with contractual guarantees:

  • Data in transit = attack surface
  • Third-party breach = your data at risk
  • Compliance audits harder (you don’t control infrastructure)

Open source self-hosted = data never leaves your VPC

For healthcare (HIPAA), finance (SOX, PCI-DSS), government (FedRAMP), this is often non-negotiable.

2. Supply chain security

With closed APIs, you’re trusting:

  • The model provider’s security
  • Their infrastructure provider’s security
  • Their subprocessors’ security

With open source:

  • You control the entire stack
  • You can audit model weights
  • No external dependencies after download

3. Adversarial robustness

Open source models can be:

  • Red-teamed internally before deployment
  • Fine-tuned to be more robust to your specific threats
  • Modified to add custom safety layers

Closed APIs: You get what the vendor gives you.

Where Closed Source WINS on Security

1. Safety guardrails

OpenAI, Anthropic, Google have teams of 50+ people building safety into models.

They’ve seen attacks you haven’t thought of:

  • Jailbreaks
  • Prompt injections
  • Adversarial inputs
  • Bias exploitation

Open source models: Safety is YOUR responsibility.

If you deploy Llama 3 without additional safety layers, it WILL generate harmful content if prompted correctly.

2. Ongoing threat monitoring

Closed providers monitor for:

  • Emerging attack patterns
  • Abuse at scale
  • Novel jailbreak techniques

They update defenses in real-time. Your API calls automatically get the latest protections.

Open source: You need to monitor threat landscape and update models yourself.

3. Liability and insurance

If Claude or GPT-4 generates something harmful, there’s vendor liability.

If your self-hosted Llama generates something harmful, you own 100% of the liability.

Enterprise legal teams care about this.

The Hybrid Security Approach

From the workshop, most security teams are converging on:

Closed APIs for:

  • Customer-facing applications (brand risk + liability)
  • High-stakes decisions (medical, legal, financial)
  • Public-facing features (higher abuse risk)

Open source for:

  • Internal tools (lower risk, higher control)
  • Data-sensitive workloads (compliance requirements)
  • High-volume processing (where you can invest in safety)

Real Security Incident from the Workshop

A company shared this cautionary tale:

They deployed open source LLM for customer support without adequate safety testing.

Within 2 weeks:

  • Users discovered prompt injection vulnerability
  • Extracted internal system prompts
  • Generated inappropriate responses that went to customers
  • PR nightmare, had to issue public apology

They switched back to closed API with safety guarantees.

Lesson: If you go open source, INVEST in safety engineering. It’s not free.

Security Checklist for Open Source LLMs

If you’re considering self-hosting:

:white_check_mark: Input validation

  • Filter malicious prompts
  • Rate limiting per user
  • Anomaly detection

:white_check_mark: Output validation

  • Content safety filters
  • PII redaction
  • Harmful content detection

:white_check_mark: Infrastructure security

  • Network isolation
  • Access controls
  • Audit logging

:white_check_mark: Model security

  • Verify model weights (checksums)
  • Monitor for model poisoning
  • Keep models updated

:white_check_mark: Incident response

  • Plan for abuse scenarios
  • Monitoring and alerting
  • Kill switch mechanism

My Recommendation

Use closed APIs IF:

  • You don’t have dedicated security engineering resources
  • Customer-facing or high-stakes use cases
  • Your risk tolerance is low

Use open source IF:

  • You have security expertise in-house
  • Data sovereignty is critical
  • You can invest in safety engineering

Don’t use open source IF:

  • You’re just downloading Llama and deploying without safety layers
  • You think “it’s just for internal use” = no security needed
  • You don’t have monitoring and incident response plans

The worst possible outcome: Deploy open source without security investment, have an incident, lose customer trust.

Better to pay for Claude API than risk your reputation.

Sources:

  • SF Tech Week “AI Security: Open Source vs Closed Models” workshop
  • Senior Executive Open vs Closed AI 2025 (security section)
  • Workshop case study: customer support prompt injection incident
  • Medium Open-Source vs Closed-Source AI Models 2025 (security considerations)

Product manager perspective: The open vs closed debate is really about product strategy, not just technology.

The Product Question

At the “Building AI Products” session today, speaker asked:

“Is your AI a feature or your product?”

That question determines your open vs closed strategy.

If AI is a FEATURE → Closed APIs

Examples:

  • E-commerce site adding AI product recommendations
  • CRM adding AI email drafting
  • Accounting software adding AI receipt scanning

Why closed makes sense:

  • :white_check_mark: Fast time-to-market: Integrate API in weeks, not months
  • :white_check_mark: Focus on core product: Don’t distract engineering with ML ops
  • :white_check_mark: Best-in-class UX: Closed models still lead on quality
  • :white_check_mark: Predictable costs: Can estimate API costs per user

Your competitive advantage is NOT the AI model. It’s your core product + AI enhancement.

Spending 6 months building open source infrastructure = 6 months competitors are shipping.

If AI is your PRODUCT → Consider Open Source

Examples:

  • AI-powered legal document analysis
  • AI coding assistant
  • AI medical diagnosis support

Why open source makes sense:

  • :white_check_mark: Differentiation: Fine-tune on proprietary data = competitive moat
  • :white_check_mark: Cost at scale: Your product IS the AI, so volume is huge
  • :white_check_mark: Control: Can’t let OpenAI pricing changes destroy your margins
  • :white_check_mark: Customization: Product experience depends on model behavior

If GPT-5 is 10% better than GPT-4, you get the benefit automatically.

But if GPT-5 pricing doubles, you’re at their mercy.

Real Product Example from the Session

Company A: Project management SaaS + AI task suggestions

  • AI = nice-to-have feature
  • Using Claude API
  • Cost: $0.02 per user per month
  • Strategy: Closed APIs forever, not even considering open source

Company B: AI-powered contract analysis tool

  • AI = the entire product
  • Started on GPT-4, moved to fine-tuned Llama 3
  • Cost went from $2.50 per contract to $0.30 per contract
  • Strategy: Open source + continuous fine-tuning = product moat

Same technology (LLMs), completely different strategies.

The “Build vs Buy” Framework for AI

Traditional software: Build vs buy
AI software: API vs self-host

Ask these questions:

1. What percentage of COGS is AI?

  • <5%: Stay on APIs
  • 5-20%: Evaluate open source
  • 20%: Probably need open source at scale

2. Is model quality a competitive differentiator?

  • No: Use best available API
  • Yes: Consider fine-tuning open source

3. How fast is your AI usage growing?

  • Slow/stable: APIs are fine
  • 100%+ YoY: Open source economics improve

4. Do you have ML talent?

  • No: APIs (hiring is hard and expensive)
  • Yes: You have options

5. What’s your funding situation?

  • Well-funded: Can invest in open source infrastructure
  • Bootstrapped/lean: APIs keep burn rate lower initially

The Hybrid Product Strategy

Most innovative approach from the session:

Start with closed APIs (speed to market)
→ Validate product-market fit
→ Understand your AI workloads
→ Build internal ML capability

Transition to hybrid (optimize economics)
→ Move high-volume workloads to open source
→ Keep customer-facing on closed APIs (quality + safety)
→ Use open source for experimentation

End state: Strategic flexibility
→ Can switch models as better options emerge
→ Not locked into vendor pricing
→ Can customize for competitive advantage

The 94% Stat is the Key Insight

Remember @eng_director_luis mentioned:

94% of organizations using 2+ LLM providers

This is the winning strategy. Don’t put all your eggs in one basket.

Our product roadmap:

  • Customer chat: Claude (best UX, safety)
  • Document processing: Llama 3.1 fine-tuned (cost + customization)
  • Internal tools: Mixture of models (choose best for each use case)
  • Evaluation: GPT-4 as baseline comparison

Product Manager’s Decision Framework

Choose CLOSED if:

  • Pre-PMF (ship fast, iterate, don’t get distracted)
  • AI is supporting feature, not core product
  • Small team (<50 people)
  • AI costs <$50K/year

Choose HYBRID if:

  • Post-PMF, scaling (economics matter now)
  • AI costs >$100K/year and growing
  • Have/can hire ML talent
  • Some workloads are cost-sensitive, others quality-sensitive

Choose OPEN-FIRST if:

  • AI IS your product
  • Data sovereignty is regulatory requirement
  • You’re ML-native team (ex-researchers, engineers)
  • You have funding to invest 6-12 months

The Mistake I See Startups Make

:cross_mark: Optimizing too early

I see pre-PMF startups saying “We’ll save money with open source!”

No. You’ll burn 3 months of engineering time and might run out of runway before finding PMF.

APIs are more expensive per token but cheaper in time to market.

:cross_mark: Optimizing too late

I also see scale-ups burning $50K/month on APIs when they should have invested in open source 18 months ago.

Now they’re locked in, migration is harder, margins are compressed.

The right time to evaluate open source: When API costs hit $10-20K/month consistently.

Questions for @eng_director_luis

You mentioned:

Currently 100% on Claude/GPT-4 APIs
$180K/year and growing 40% Q/Q

Given 40% Q/Q growth, your API costs will be:

  • Q4 2025: $250K/year run rate
  • Q4 2026: $1M/year run rate

At $1M/year, open source is almost certainly cheaper. So your question isn’t “if”, it’s “when”.

@cto_michelle’s hybrid approach seems perfect for you. Start the transition now while costs are manageable.

Sources:

  • SF Tech Week “Building AI Products” session (Day 3)
  • CB Insights Foundation Model Divide report 2025
  • Panel discussion: Company A and Company B case studies
  • Hatchworks Open vs Closed LLMs Guide 2025 (product strategy section)