Open Source vs Closed Source AI Models in 2025: How to Choose What Actually Works for You

Picture this.

You’re in a late‑night strategy meeting, half‑cold coffee on the table, a slide deck titled “AI Roadmap 2025” glowing on the screen.

Your CTO is excited:

“We should go all‑in on open‑source AI. Full control, no vendor lock‑in, we can even self‑host.”

Your CISO looks horrified.

“Or we could not expose our core IP and customer data to some half‑maintained GitHub project, thanks.”

Meanwhile, your CFO just wants to know why the AI line item looks like the cost of a small satellite.

If that sounds even vaguely like your world, this guide is for you.

In this article, we’ll unpack open source vs closed source AI models in a way that actually maps to reality in 2025 — not just ideology. You’ll see where each approach truly shines, where it quietly breaks, and how to design a hybrid AI strategy that fits your risks, budget, and ambitions.

What “open source AI” really means (and why everyone keeps misusing the term)

Before you can make a smart choice, you need to untangle a messy bit of language: open source does not just mean “you can download the model weights.”

Open source: the classical meaning

For software, the term open source is defined by the Open Source Initiative (OSI). Their Open Source Definition says that a license must, among other things:

• Allow free redistribution without royalties
• Provide access to the source code
• Not discriminate against specific users or fields of endeavor

In 2024–2025, OSI went a step further and released the first stable “Open Source AI Definition 1.0”, because they concluded that you can’t just copy‑paste the old software rules onto AI models — the economics and risks are too different.

So in its strict sense, an open source AI model should grant you:

• The ability to use it for any purpose
• Access to the model artefacts (code, weights, often training data)
• Freedom to modify and redistribute it, without field‑of‑use restrictions

In practice, very few frontier‑scale models meet that bar.

Open weights, source‑available, and “open‑washing”

Most of what’s marketed today as “open source AI” is actually something softer:

• Open‑weight models – You can download the weights, fine‑tune them, and run them locally, but you don’t necessarily get full training data or unconstrained license freedoms. This is how Meta’s Llama models and OpenAI’s gpt‑oss models are positioned. (The Guardian)
• Source‑available models – You can see or use the code and/or weights, but under licenses that may restrict commercial use or certain domains (e.g., banning weapons, surveillance, or political operations).

The OSI has explicitly called out Meta’s Llama 3.x license as not open source under their definition. They argue it fails basic freedoms like using the model “for any purpose” and restricts certain users (including some in the EU) and fields of endeavour.

That’s why you’ll increasingly hear the term “open‑washing” — using the credibility of open source to market what is, legally and practically, still proprietary.

What counts as closed source or proprietary AI?

On the other side, closed source AI models:

• Keep their model artefacts (weights, training data, internal optimizations) proprietary
• Are usually accessed via a paid or rate‑limited API or SaaS product
• Provide limited or no visibility into training data, architecture, or fine‑tuning processes

Think of systems like GPT‑4-class models, Claude, or some high‑end Gemini variants. Their providers may publish research papers, model cards, or safety reports — but you don’t get the weights, and you certainly can’t fork them and ship your own competing SaaS.

A 2024 policy analysis from the R Street Institute summarizes it bluntly: closed‑source AI is about centralized control and proprietary protection, while open‑source AI is about distributed access and collaboration — and each comes with distinct security, governance, and innovation implications.

Why open‑source AI matters: transparency, innovation, and control

Let’s start with the upside of opening things up.

1. Transparency, reproducibility, and real scrutiny

A 2024 review in the journal Computers looked specifically at open‑source AI privacy and security. It found that as more high‑quality open models are released on platforms like Hugging Face, TensorFlow Hub, and PyTorch Hub, they’re increasingly used in critical applications — but that their transparency is a double‑edged sword.

On the plus side:

• Researchers can inspect architectures, training setups, and sometimes data sources
• Security teams can reproduce attacks and patch vulnerabilities
• Regulators and auditors can verify claims rather than just trusting glossy blog posts

A separate 2025 study on “The Open‑Source Advantage in Large Language Models” points out that this transparency has enabled projects like BLOOM, where the entire training pipeline, data set (The Pile), and logs are open — allowing thousands of researchers to replicate, critique, and extend the model. (arXiv)

If you care about reproducibility, auditability, and independent verification, open‑source AI (properly licensed) is simply in a different league to closed systems.

2. Innovation and ecosystem effects

Open ecosystems tend to compound.

According to OSI, a 2024 Harvard study estimated the demand‑side value of the wider open‑source software ecosystem at around $8.8 trillion, and suggested that firms would need to spend about 3.5× more on software without it.

That’s not AI‑specific, but it shows how powerful open collaboration can be.

On the AI side specifically:

• Policy research describes open‑source AI as enabling under‑resourced universities, smaller firms, and civil society groups to participate in frontier research instead of watching from the sidelines.
• A 2024 study on AI’s impact on open‑source software development found that AI tools accelerate project creation and management in the OSS community, while raising new ethical questions — suggesting a positive feedback loop between AI and open development. (journals.flvc.org)
• Developer sentiment leans heavily open: a recent StackOverflow‑referenced survey reported that 57% of developers prefer open‑source projects, versus about 30% who prefer proprietary tech, a split cited in Index.dev’s 2025 guide on open vs closed AI. (Index.dev)

The result: important architectural ideas — like Mixture‑of‑Experts (MoE) and parameter‑efficient fine‑tuning — are now being driven aggressively by open‑source projects such as Mistral’s Mixtral, DeepSeek, and OLMoE, not just by closed labs. (arXiv)

3. Customization, self‑hosting, and data sovereignty

The single biggest practical reason teams fall in love with open models is control:

• You can self‑host models inside your VPC or on‑prem hardware.
• You can fine‑tune them on proprietary data without sending that data to a third‑party vendor.
• You can strip or harden features for your risk posture — for example, completely disabling code execution, RAG over internal documents, or tool use in sensitive contexts.

A 2025 deep‑dive on Meta’s Llama 4 notes that self‑hosting open‑weight Llama 4 gives maximum control over data residency, sovereignty, and capacity planning, at the cost of taking on more operational and security overhead yourself. (Skywork)

If your main fear is “our sensitive data should never leave our infrastructure,” open‑weight or genuinely open‑source models are an obvious starting point.

Where closed‑source AI models still win: performance, polish, and support

So if open‑source AI is so great, why is there still such a stampede toward proprietary APIs?

Because in several important dimensions, closed models still lead.

1. Raw performance on broad benchmarks

Both policy and technical research converge on the same picture:

• A 2024 policy report cited by the R Street Institute concluded that the best open large language models lag behind top closed models by around 5–22 months in benchmark performance and training compute. (R Street Institute)
• The “Open‑Source Advantage” study acknowledges that closed models like GPT‑4 still dominate general‑purpose benchmarks such as MMLU, GSM8K, HumanEval, and GPQA, largely because they’re trained on enormous proprietary corpora with massive compute budgets. (arXiv)

Open models have narrowed the gap — and in some niches even overtaken older closed ones — but if you need absolute state‑of‑the‑art performance across many tasks, the frontier is still mostly proprietary.

2. Enterprise polish: SLAs, tooling, and integrated ecosystems

Most closed‑model providers don’t just sell a model; they sell a platform:

• Managed hosting, autoscaling, observability
• Built‑in guardrails, content filters, and policy tooling
• Fine‑tuning endpoints, vector stores, and orchestration frameworks
• Enterprise contracts, SLAs, indemnities, and compliance documentation

For a lot of organizations, that bundle is worth paying for. The total cost of ownership may be lower than building an in‑house MLOps stack to run open models reliably at scale.

3. Regulatory clarity and accountability

Under the EU AI Act, providers of general‑purpose AI models (GPAI) — which include many closed models — must maintain documentation, provide technical information to regulators, and may face fines of up to 3% of global annual turnover for non‑compliance. (Digital Strategy)

Some commentators argue that this makes closed systems, ironically, more accountable in certain high‑risk contexts, because:

• There is a clearly identifiable provider with legal obligations.
• Liability, incident reporting, and remediation are more straightforward.

A 2024 analysis of models under the AI Act notes that closed‑source models can offer regulatory clarity, security, and control, albeit at the cost of transparency and access for smaller players. (DISC InfoSec blog)

If you’re in healthcare, finance, or critical infrastructure, that trade‑off may be entirely acceptable.

You might want to read this: The AI Advertising Strategy Blueprint: How Smart Marketers Use Smart Bidding, Broad Match, and RSAs to Achieve 20% More Conversions

Security and privacy: open source vs closed source AI under the microscope

Security is where the debate gets spicy — and where nuance really matters.

Open‑source AI: more eyes, more attack surface

The 2024 Computers review on open‑source AI highlights several privacy and security threats that are easier to exploit when models and code are openly available: (MDPI)

• Model inversion – Reconstructing sensitive training data from model outputs
• Membership inference – Determining whether a specific user’s data was in the training set
• Data poisoning – Polluting training data to introduce bias or backdoors
• Backdoor attacks – Embedding hidden triggers that cause malicious behavior

The paper describes improved model inversion attacks that dramatically increased reconstruction accuracy on datasets like CelebA and CIFAR‑10 — in some cases boosting accuracy from around 0.2 to over 0.7 on key metrics. That’s a strong signal that once attackers can deeply inspect and probe a model, leakage risk is very real.

On the systems side, open‑source infrastructure can become a target too:

• In 2023–2024, a vulnerability (CVE‑2023‑48022) in the popular open‑source AI framework Ray allowed attackers to steal credentials, remotely control servers, and corrupt AI models. Researchers found that thousands of Ray servers used by companies such as Uber, Amazon, and OpenAI had been compromised in a campaign dubbed “ShadowRay.”
• In 2025, follow‑up reports described “ShadowRay 2.0”, a campaign turning vulnerable Ray‑based AI clusters into a self‑expanding botnet and crypto‑mining network. (CyberSecureFox)

None of this means open‑source AI is “insecure by design,” but it does mean:

• Transparency increases the power of both defenders and attackers.
• Open models and tooling require professional‑grade security engineering, not “it’s open so the community will fix it.”

The upside? The same openness enables:

• Faster vulnerability discovery and patching
• Reproducible red‑team exercises
• Independent audits and threat modelling

Closed‑source AI: safer by default, or just opaque?

Closed models limit access — which reduces some risks, but introduces others.

The R Street analysis notes that proprietary AI allows providers to:

• Standardize development and deployment
• Enforce strict access controls and acceptable‑use policies
• Maintain rigorous oversight of how models evolve

That’s good for preventing casual misuse. But there’s a paradox:

• Because only the vendor sees the internals, critical vulnerabilities may remain hidden for longer.
• External researchers can’t easily verify claims about data contamination, benchmark integrity, or safety mitigations.

Recent controversies around benchmark “gaming” and opaque evaluation setups for some commercial models illustrate this concern — when only the vendor controls the data and model, trust is partially forced rather than earned. (arXiv)

And remember: many of the privacy attacks described in the open‑source review (membership inference, inversion, prompt‑injection‑driven data exfiltration) can still hit closed models exposed by API — you just attack through the interface instead of the weights. (MDPI)

Practical security steps, whichever path you pick

Regardless of open vs closed, you’ll want to:

1. Threat‑model your AI stack
   • What could an attacker gain?
   • Where can untrusted prompts, files, or tools slip in?
2. Harden your interfaces
   • Validate and sanitize inputs (including file and URL handling).
   • Limit tool execution scope (databases, shells, cloud APIs).
3. Use defense‑in‑depth
   • Network segmentation for self‑hosted Ai models.
   • Strong authentication and key rotation for closed APIs.
   • Monitoring and anomaly detection for weird model behavior.
4. Apply modern ML security techniques
   The open‑source privacy review highlights adversarial training, differential privacy, and model sanitization as partially effective mitigations against inversion and membership inference.
5. Red‑team regularly
   Industry guidance increasingly recommends external red teams, model cards, and transparency reports as part of a mature AI security program — whether you’re using open or closed models. (Index.dev)

Law, policy, and governance: how regulators see open vs closed AI

Regulation is moving fast, especially in the EU — and it treats open and closed models differently, but not as differently as some people assume.

The EU AI Act’s take on general‑purpose AI models

Under the EU AI Act, providers of general‑purpose AI models (GPAI) must:

• Document key technical details about their models
• Provide this information to the new AI Office and national regulators on request
• Make certain information available to downstream deployers
• Implement risk‑mitigation measures when required

Non‑compliance can attract fines of up to 3% of global annual turnover or €15M, whichever is higher. (Digital Strategy)

The “open source exemption” (with strings attached)

An open‑governance think tank that tracked the AI Act’s negotiations describes the final deal as a “Frankenstein‑like approach”: (Open Future)

• There’s a limited exemption for “free and open source models whose parameters are made publicly available” — they avoid some obligations.
• However, transparency duties still apply in key areas, including:
  • Publishing a summary of training data (within trade‑secret limits)
  • Implementing copyright‑compliance policies
  • Meeting extra responsibilities if the model is deemed systemic risk (e.g., trained with enormous compute or widely deployed).

Another security‑focused analysis of the AI Act notes that: (DISC InfoSec blog)

• Open‑source models can avoid some regulatory burdens as long as they remain low‑risk and non‑monetized.
• Once open models intersect with high‑risk use cases, monetization, or systemic impact, they face many of the same obligations as proprietary models.

In other words:

“It’s open source” ≠ “no regulation.”

You still need to think about risk tier, deployment context, and business model.

How performance actually compares in 2025

Let’s dispel a couple of myths.

Myth 1: “Open models are toys; closed models are serious.”

A 2024 review on open‑source AI includes a chart comparing ELO ratings of closed vs open LLMs on a popular chatbot arena:

• Closed models like GPT‑4 and Claude cluster at the very top.
• But open models such as Qwen‑1.5‑72B, Llama‑2‑70B‑chat, and Mistral‑Medium are now close behind.
• The review emphasizes that the gap is shrinking and usage of open models is rapidly increasing.

The “Open‑Source Advantage” study goes further with detailed benchmark numbers: (arXiv)

• Open models like Mistral‑7B can outperform GPT‑3.5 on several linguistic benchmarks despite having fewer parameters.
• DeepSeek‑V3, an open Mixture‑of‑Experts model, reports:
  • 88.5% on MMLU
  • 91.6 F1 on DROP
  • 59.1% on GPQA‑Diamond
  • Around 90.2% on MATH‑500
  • About 82.6% pass rate on an extended HumanEval coding benchmark

The same paper notes that in their October 2025 snapshot, many open and closed models perform similarly on MMLU, with individual leaders emerging task‑by‑task. GPT‑4 still shows excellent all‑round performance, but open‑source models like LLaMA 3.1 405B stand out on specific tasks (e.g., reading comprehension in DROP).

A separate policy study confirms this pattern: open models are increasingly “good enough” for many enterprise AI strategy use cases, even if the absolute frontier remains closed for now.

Myth 2: “Closed models always win at safety and alignment.”

Closed models often ship with more centralized moderation and safety tooling, but research also highlights problems:

• Data contamination and evaluation malpractice in closed models can inflate benchmark scores and hide weaknesses. (arXiv)
• Without visibility into training data and fine‑tuning, it’s hard for independent experts to verify bias mitigation or compliance with emerging norms.

Meanwhile, open models are benefiting from:

• Community‑driven safety libraries
• Shared red‑team datasets
• Transparent model cards and evaluation logs

So instead of thinking open = unsafe, closed = safe, it’s more accurate to say:

Open models make safety work visible and collaborative.
Closed models make safety work centralized and contractual.

Both can be dangerous if you treat them as plug‑and‑play magic.

Hybrid strategies: why “open vs closed” is a false binary for most teams

In practice, almost nobody serious is 100% on one side.

Industry trend: open mid‑tier, closed frontier

Look at how the giants are moving:

• Meta releases Llama models as open‑weight, but OSI and others argue their licenses are still proprietary and restrictive. Meta is now signalling that its most advanced future models (code‑named “Avocado”) may not be released openly and may even be monetized more conventionally.
• OpenAI launched free, customizable “gpt‑oss” models as open‑weight LLMs that developers can fine‑tune, while keeping its top ChatGPT‑style systems closed. These gpt‑oss models are reported to reach near‑parity with the company’s smaller proprietary AI models on reasoning tasks. (The Guardian)
• DeepSeek and others ship powerful open‑weight MoE models, while still building proprietary services and infrastructure around them. (arXiv)

A major policy study summarizes the emerging consensus:

The long‑term sweet spot is likely a marriage of open and closed approaches, not a total victory for either.

Technical hybrid models

The same R Street paper outlines three “hybrid” architectures that are already showing up in real systems:

1. Open‑source AI with controlled access
   • Open code and/or weights, but behind license gates and vetting (e.g., Llama’s license banning certain high‑risk uses).
2. Tiered access models
   • Basic capabilities open or free; advanced capabilities available via paid tiers or partnerships (think ChatGPT’s free vs Plus vs Pro tiers).
3. Federated learning
   • Models trained collaboratively across many devices or organizations, where only updates — not raw data — are shared.

These are all attempts to get the best of both worlds: openness for innovation, control for safety and monetization.

A practical decision framework: open source vs closed source AI for your use case

Let’s bring this down to earth. Here’s a concrete way to decide.

Step 1: Classify your use case by risk

Ask yourself:

• Is this internal & low‑risk (e.g., code search, documentation assistants, log summarization)?
• Customer‑facing but low/medium risk (marketing copy, productivity features)?
• High‑risk / regulated (credit decisions, medical advice, legal analysis, critical infrastructure control)?

As a rough rule of thumb:

• Low risk → open models are often ideal for experimentation and cost control.
• Medium risk → hybrid (open for experimentation, closed for production, or vice‑versa).
• High risk → closed or tightly controlled open‑weight models, with strong governance and legal oversight. (DISC InfoSec blog)

Step 2: Look at data sensitivity and residency

Key question:

“What happens if the model, its logs, or its training data leak?”

If you absolutely cannot risk data leaving your perimeter (healthcare records, trade secrets, defence systems), you’ll lean toward:

• Self‑hosted open‑weight models with strong security controls, or
• Very carefully vetted closed providers that offer strong isolation, on‑prem options, or sovereign cloud setups.

If your data is less sensitive (e.g., public marketing copy), API‑only closed models are usually fine.

Step 3: Audit your skills and infrastructure

Open models shine when you have:

• An MLOps team comfortable with GPU clusters, observability, and deployment pipelines
• Security engineers who can properly segment, patch, and monitor your AI stack
• Legal/compliance resources to manage licenses and obligations

If you don’t have that, a closed API with solid enterprise support can drastically reduce your operational risk — especially early on.

Step 4: Match performance to actual needs

Not every use case needs GPT‑frontier‑level power.

For many workloads, especially:

• Structured generation (emails, templates, product descriptions)
• Domain‑specific summarization (support tickets, logs)
• Retrieval‑augmented question answering over your own data

a well‑tuned open‑weight model (like a 7B–70B‑class LLM) is more than sufficient, especially when combined with good RAG and UX.

Reserve the super‑expensive, top‑tier closed models for tasks where:

• Misfires are especially costly (legal, medical, financial reasoning), or
• You’ve empirically shown the performance delta justifies the spend.

Step 5: Decide your hybrid pattern

Three very workable patterns in 2025:

1. Open for experimentation, closed for production
   • Prototype agents and workflows on local open models.
   • When the product is stable and high‑impact, move critical paths to a closed model with SLAs.
2. Closed core, open extensions
   • Use a closed model as the main orchestrator.
   • Plug in specialized open models for particular tasks (e.g., code, multilingual, domain‑specific NER).
3. Open primary, closed fallback
   • Default to an open model for cost and control.
   • Automatically fall back to a closed frontier model for prompts detected as particularly complex or safety‑critical.

You’re not picking a religion. You’re designing a portfolio.

Actionable takeaways you can apply this quarter

If you just skimmed, here’s the short, highly practical version:

• Don’t trust labels. “Open source” is often actually open‑weight or source‑available. Check the license and OSI’s definitions if freedoms matter to you.
• Assume all models are attackable. Open models give attackers more surface; closed models give you fewer eyes on the problem. Design your security program accordingly.
• Open models are no longer toys. Modern open LLMs rival or beat GPT‑3.5‑class systems on many tasks and continue to close the gap with frontier models.
• Closed models still lead at the absolute frontier. If you need the very best general‑purpose reasoning, you’re still mostly shopping on the proprietary aisle. (arXiv)
• Regulation is catching up. The EU AI Act treats open and closed differently but still places obligations on both, especially at systemic or high‑risk scales. (Digital Strategy)
• Plan for a hybrid future. Most serious teams will end up combining open and closed models, not choosing one forever.

FAQ: Open source vs closed source AI models

1. Is open‑source AI safer than closed‑source AI?

Not inherently — it’s safer in some ways and riskier in others.

• Open models are easier to audit and reproduce, which is crucial for trustworthy systems.
• But the same transparency makes powerful attack techniques (like model inversion and data poisoning) easier to design and test, especially when weights are public.

Closed models reduce some risks by restricting access but can hide others because fewer independent experts can inspect them.

Bottom line: safety is about your whole system, not just the licensing model. You can build unsafe systems on top of either.

2. Which is better for enterprises: open source AI or closed source AI?

It depends on your priorities:

Choose primarily open if:

• Data sovereignty and self‑hosting are critical.
• You have a strong MLOps and security team.
• You want deep customization and lower marginal inference costs.

Choose primarily closed if:

• You value SaaS simplicity, vendor support, and SLAs.
• You’re in a high‑risk or heavily regulated domain and prefer clear external accountability. (DISC InfoSec blog)
• You need top‑tier performance with minimal in‑house infra.

For many enterprises, the winning answer is a hybrid of both, mapped to specific use cases.

3. Can open‑source AI models replace GPT‑4‑level closed models?

For some tasks, yes; for others, not yet.

Open models have:

• Reached or exceeded GPT‑3.5‑class performance on several benchmarks.
• Produced specialized models (e.g., biomedical, legal) that outperform general closed models on niche workloads.

But for the absolute frontier of general‑purpose reasoning, coding, and multimodal capabilities, the best closed models still lead — at least according to current public benchmarks and policy analyses. (arXiv)

If your question is: “Can I run my business productively on open models?” — the answer is often yes. If it’s “Can I replicate GPT‑frontier behaviour exactly?” — not today, and certainly not without serious engineering.

4. How does the EU AI Act treat open‑source AI models?

In short:

• All general‑purpose AI providers (open or closed) must document technical information and share it with regulators when requested. (Digital Strategy)
• “Free and open source” models with publicly available parameters get a partial exemption, but:
  • They still must publish a training data summary and implement copyright‑compliance policies.
  • If they are considered systemic risk (e.g., trained with very high compute or widely deployed), full obligations can apply. (Open Future)

So open‑source AI doesn’t sit completely outside regulation; it just has a somewhat different path through it.

5. What’s the difference between open source, open‑weight, and source‑available AI models?

• Open source AI
  • Meets OSI’s Open Source Definition and OSI’s Open Source AI Definition.
  • You can use, modify, and redistribute for any purpose, without restrictive clauses.
• Open‑weight AI
  • You can download and fine‑tune the weights.
  • The license may restrict commercial use, specific domains, or user groups (as critics argue is the case for Meta’s Llama license).
• Source‑available AI
  • You can see or use the code/weights, but under a proprietary license that does not meet OSI’s freedoms (e.g., strong commercial restrictions, bans on certain sectors).

When in doubt, read the license — and if the vendor is loudly shouting “open source” while imposing lots of “you may not…” clauses, assume you’re in open‑washing territory.

6. Are open‑source AI models really free to use commercially?

Not always.

• Some genuinely open‑source models use permissive licenses (Apache, MIT) or AI‑native equivalents that allow broad commercial use.
• Many popular “open” models use community licenses that:
  • Restrict certain industries (e.g., weapons or surveillance)
  • Cap usage above a certain scale
  • Require separate licenses for monetization or embedding in closed products

If you’re planning a commercial product, you absolutely need a lawyer to review the model license — especially for anything branded as “community,” “research,” or “non‑commercial.”

7. What is a hybrid AI strategy, and why should I care?

A hybrid AI strategy is deliberately combining open and closed models across your stack to balance:

• Cost
• Performance
• Risk
• Regulatory exposure

Examples:

• Using a self‑hosted open model for internal tools and a closed model for customer‑visible features with legal implications.
• Using a closed orchestrator (for high‑quality reasoning and safety tooling) that routes some subtasks to small, specialized open models.
• Defaulting to open models and falling back to closed models when the confidence or safety profile demands it.

Policy research suggests that this kind of hybridization is where most of the long‑term value and resilience will come from: leveraging openness for innovation and scrutiny, while using proprietary systems where centralized control and resources matter most.

If you’re deciding your AI strategy right now, don’t frame it as “open source vs closed source AI models — which team am I joining?”

Frame it as:

“For this use case, with this risk profile and this budget,
what mix of open and closed models gives me the most trustworthy, sustainable leverage?”

Once you ask that question, the path forward becomes much clearer.