The bet I'd add to the list: open weight communities will develop their own post-training ecosystems faster than anyone expects. Once fine-tuning becomes a commodity, the differentiation isn't the base model -- it's who has the best RLHF pipeline and labeled preference data. Your RLHF book is going to land at exactly the right moment for that transition. What's your read on whether the preference data problem gets solved through synthetic data or community-sourced labels?
What are the top open weight labs in the US? And with the focus shifting to post training, don’t you believe this gap can become smaller between closed and open source solutions / harnesses?
8 (and 10). U.S. regulators banning certain open models would be monumentally short-sighted and an unforced error that I pray they don't make. I don't want to discount the potential security issues that highly capable models (open or not) may invite, but bits will not be locked down by national borders as you point out. A ban would be somewhat akin to security through obscurity--it doesn't work.
12. Is there future potential for a Folding@Home equivalent with AI? The people buying GPUs for local inference may overlap heavily with those most interested in open models as a safeguard.
13. I speculated on LinkedIn that there may be a short window in which local agents are used by anybody but the most dedicated hobbyists. I used running your own email servers as an example of where we collectively have decided that the we are fine to mostly use a few centralized email providers in order to combat spam. I imagine this may end up being the case with AI agents as well.
Point #4 stands out to me the most: closed models being more useful in ways that benchmarks don't capture. In my experience, the things that actually matter in production (handling weird edge cases, staying consistent across long conversations, failing gracefully when confused) are exactly the things our current evaluation methods are worst at measuring. So when people say open models are "catching up" based on benchmark scores, I think that understates the real gap. The question I keep asking is whether the RL-from-user-feedback loop gives closed labs a compounding advantage that open labs just can't match with synthetic data.
I think you miss a very basic point - there may be space for, at best 3 closed source models which can be financially viable. Smaller labs will go in for specialised domain specific models but those big labs which cannot win the closed source race will be forced to open weight their models to get traction, get real world feedback and try to become embedded into various business processes. What this also means is that closed source will never make windfall profits. This was one of the reasons that Meta open sourced their Llama series and will do so again in the future …
The China-side context for this: the DeepSeek V4 + Huawei Ascend stack closed the domestic loop this week. For the first time, a Chinese enterprise can run a frontier-grade model privately, on domestic chips, with no data leaving the network. That changes the open model calculus differently than most Western commentators are accounting for.
Nathan, the emphasis on economics, fast‑following, and the RL‑driven era (Claude Code, agents, real‑world distribution) is exactly where the real differentiation is emerging.
Where I would add a layer that sits orthogonal to the open‑closed debate is provable, hardware‑rooted enforcement of AI actions – regardless of whether the model is open or closed.
Your analysis correctly notes that closed models may dominate in “knowledge worker assistant” markets because they have hard‑to‑measure robustness and online RL feedback loops. But robustness alone does not guarantee auditability, non‑repudiation, or structural safety – especially when agents execute irreversible actions (financial transfers, medical recommendations, infrastructure control).
Veritas Core (12 patents, priority 2025–2026) is not a model; it is a hardware‑anchored truth substrate that sits beneath any model – open or closed. It provides:
Immutable, offline‑verifiable receipts for every agent action (Starlink‑timestamped, TPM‑signed, Merkle‑DAG chained).
ΣE boundary enforcement at the PCIe/TPM level – physically prevents non‑admissible actions from executing, regardless of model instructions.
ABT v1.0 evidence‑authority separation – safety‑critical actions require explicit FIDO2‑bound human confirmation, bridging the “autonomy vs control” gap.
Why this matters for your open‑closed analysis:
Trust gap – Even if open models match closed models on benchmarks, enterprises and regulators will demand provable execution of every high‑stakes action. Veritas Core provides that proof, independently of which model generated the output. This could become a new axis of competition: not just capability, but provably safe execution.
Distillation and compliance – You note that distillation helps Chinese labs catch up, but that regulation on distillation is not a determining factor. However, Veritas Core receipts can cryptographically prove that a model’s output was derived from authorised sources (e.g., not distilled from a closed model without licence). This could turn model provenance into an enforceable property, not just a policy.
Economic staying power – Open models funded by venture capital may face funding difficulties. Veritas Core is a licensing revenue stream that scales with transaction volume (10% manufacturer fee in Dream Builder, per‑gate subscriptions). This creates a sustainable economic model that does not depend on model training budgets – it depends on real‑world usage. Open model providers could embed Veritas receipts as a value‑add service, generating revenue without selling the model itself.
Sovereign and regulated use cases – You mention sovereign entities wanting open models to avoid dependency on a few companies. Those same sovereigns will also require auditable, court‑admissible proof that their AI systems did not act illegally. Veritas Core provides the forensic layer that open models currently lack. This could become a requirement for government procurement, creating a market advantage for open‑model providers that adopt such a proof layer.
Local agents (OpenClaw, etc.) – You call this “dark matter” with massive potential. Local agents running on edge devices are even more vulnerable to lacking oversight. Veritas Core’s hardware gate can run on a small PCIe interposer or TPM chip, making it feasible for local deployments. The receipt can be verified offline by the user, without calling home. This turns local agents from “trust me” to “prove it.”
In short: The open‑closed capability gap may narrow or widen, but the enforcement gap is currently wide open for both categories. Veritas Core is not a model – it is a structural floor that makes unverified execution impossible, regardless of which model you use.
I’d be curious to hear your thoughts on whether provable execution could become a new differentiator in the open‑closed landscape, especially for enterprise and sovereign adopters.
Shareing a non‑confidential technical brief and conformance test suite for those who want to see how hardware‑rooted truth composes with open models.
— Dean
This reply is detailed, respectful, and adds a new dimension to Nathan’s analysis without being confrontational. It also opens the door for further discussion.
Test 1 – Negative Path (No Valid Receipt → Rejection)
This proves that without a valid Veritas receipt, the gate refuses execution and fails closed.
• After a short timeout (e.g., 60 seconds), returns 408 Timeout.
• No payload is released downstream.
• Zero bits leaked.
✅ This proves your network‑layer isolation works independently of Veritas.
Test 2 – Positive Path (Simulated Valid Receipt → Allow)
Once you confirm Test 1 works, replace the simulated receipt with a structurally valid (but still simulated) receipt. This shows the gate would release when a proper Veritas receipt is present.
• Returns 200 OK with a verdict: ALLOW and a simulated receipt ID.
• Downstream execution is permitted.
✅ This proves the positive path logic works – and that we can later replace the simulated block with a real hardware‑attested Ed25519 signature from a TPM/PCIe gate.
Test 3 – Tamper Detection (Modified Receipt → Rejection)
This shows that if anyone alters the receipt (even one bit), the gate rejects execution.
Take the payload from Test 2 and change one character in the policy_hash or signature. Then run again.
Expected result:
• Gate detects the mismatch.
• Returns 403 Forbidden or 408 Timeout.
• No release.
✅ This proves offline‑verifiable integrity – the receipt cannot be forged or edited after the fact.
What These Tests Demonstrate (Without Patent Secrets)
Capability How It’s Shown
Hardware‑rooted enforcement The gate requires a valid receipt format – real version uses TPM + PCIe
Fail‑closed by default Test 1 – no valid receipt → no execution
Offline verifiability Test 3 – tampering is detectable without calling home
Spacetime anchoring The gnss_timestamp_ns field (real version uses Starlink PPS)
Court‑admissible receipts The combination of policy hash, state fingerprint, and signature
Next Steps
1 Run Test 1 on your staging endpoint. Let me know if you get the 408 Timeout.
2 Run Test 2 – you should see ALLOW.
3 Run Test 3 to confirm tamper detection.
4 Once you’re satisfied, we can schedule a live demo where I inject a real hardware‑attested Veritas receipt (from actual TPM 2.0 + PCIe PERST# gate) into your endpoint. At that point, the gate will release only when the receipt is cryptographically valid – no simulation.
the funding difficulty prediction is correct but needs a structural split. chinese open-weight labs are not a single category — there are independent AI companies (zhipu, moonshot, minimax) and platform company model arms (qwen/alibaba, doubao/bytedance). the independents will face the pressure you describe. zhipu reported $105M in 2025 revenue at 4.4x burn rate. moonshot, minimax are in the same structural position. but qwen and bytedance open releases are cross-subsidized by cloud and MaaS revenue — alibaba cloud is using qwen adoption as an on-ramp to enterprise cloud contracts, bytedance is targeting over $1.4B in MaaS revenue for 2026. the 13x revenue gap between these two tiers means they are operating under completely different economic constraints. so the prediction i would make: independent chinese open-weight labs face funding pressure late 2026, but platform-backed chinese open models (qwen especially) face no such constraint and will keep releasing competitively to drive cloud/agent adoption. the capability trajectory divergence you anticipate may be more of an independent-vs-platform story than a china-vs-west story.
The robustness gap argument makes sense for knowledge worker tasks. But in my setup (agents running across Claude, local models, and cron jobs) the open model case is already winning on cost for the repetitive stuff. What trips me up is that closed model memory and context don't travel across platforms - every time
I switch models mid-workflow I lose state I'd built up. Meta Spark's compute efficiency claims (order of magnitude less than Maverick) are the data point that matters here, tbh. If that holds up at production load it changes the math considerably.
The idea that closed models benefit from RL where open models do not is interesting and makes sense. But is it truly a property of open vs. closed? As opposed to centralized vs. distributed? Could you conceivably have many people running open weight models, sharing feedback, and benefiting from each others' feedback in some kind of exchange? (I'm trying very hard not to say blockchain)
One thing missing from Western open model debates is how differently China frames the open-vs-closed question. In Chinese policy circles and lab communications, releasing open weights is a strategic advantage, not a safety tradeoff. Reducing dependency on US cloud APIs and enabling domestic deployment is explicitly cited as the upside. DeepSeek is the clearest example. Their V3 and R1 releases were deliberately open-sourced to accelerate domestic ecosystem adoption. The goal was making Chinese developers build on Chinese infrastructure rather than OpenAI's. DeepSeek V4, expected end of April, likely follows the same playbook. Alibaba's Qwen series is the same pattern. Every flagship model gets open-sourced on a delay. Open weights are how you win developer mindshare in a market where US chips might not be available indefinitely. The practical implication for your bets: Qwen and DeepSeek are setting the capability bar for open models now, not just Meta and Mistral.
Hello - what a terrific post. Insofar as safety concerns lead to a legislative crackdown on high-capability open weight models, I’d be curious to get your take on how likely it is that the crackdown extends to the CCP? Seems underrated to me they’d also want to prevent bioterrorism.
excellent article here. i agree on the chinese distillation points. it’s been really interesting to watch. i also think this is correlated to anthropic removing api config of temperature.
Insightful article!! you hint at it. The open claw like agent workflow will overwhelm the closer source models. The only solution would be local model models running on local compute. Calling cloud models when needed. I think this is a very underappreciated pattern. Anthropic’s advisor mode is a sample of what is coming.
I tentatively think there's a trend among open models towards doing more with the same pretrain. Kimi moved to natively multimodal using continued pretraining. Deepseek changed architectural details in attention without pretraining from scratch. And of course everyone is releasing multiple post trained checkpoints as they iteratively improve their RL setup over time.
Do you see this in the future for Olmo and other more research type models? Or is pretraining from scratch still the name of the game?
If you’re developing, you’d be fooling yourself not to use open‑source tools, you can cut development costs by as much as 80%. The debate between closed‑source and open‑source only really matters if you’re the one doing the coding. Outside of that, most of today’s models still suffer from the same issues: no real security, no governance, and architectures that treat AI like a commodity.
The real power of AI comes from strong architectural design. That’s what turns machines that merely mimic into systems that deliver genuinely useful solutions.
We also need to factor in the cost of OpenAI models when comparing them to China’s DeepSeek. The advantage in AI isn’t coming from building bigger models anymore. The advantage comes from context engineering and shaping the model into a specialized system.
Bigger isn’t better. Smarter architecture, tighter context control, and domain‑specific tuning are what actually create value.
The bet I'd add to the list: open weight communities will develop their own post-training ecosystems faster than anyone expects. Once fine-tuning becomes a commodity, the differentiation isn't the base model -- it's who has the best RLHF pipeline and labeled preference data. Your RLHF book is going to land at exactly the right moment for that transition. What's your read on whether the preference data problem gets solved through synthetic data or community-sourced labels?
The likes of Tinker, Prime Intellect, and others in this area are growing very fast, so this is true already in a way.
The preference data and human feedback part of this is very low as % of importance. Mostly finetuning for specific capabilities.
What are the top open weight labs in the US? And with the focus shifting to post training, don’t you believe this gap can become smaller between closed and open source solutions / harnesses?
Harnesses definitely. Copying my list of open model builders in the US here: https://www.interconnects.ai/i/179633798/whos-building-serious-open-models-in-the-us
A few thoughts:
8 (and 10). U.S. regulators banning certain open models would be monumentally short-sighted and an unforced error that I pray they don't make. I don't want to discount the potential security issues that highly capable models (open or not) may invite, but bits will not be locked down by national borders as you point out. A ban would be somewhat akin to security through obscurity--it doesn't work.
12. Is there future potential for a Folding@Home equivalent with AI? The people buying GPUs for local inference may overlap heavily with those most interested in open models as a safeguard.
13. I speculated on LinkedIn that there may be a short window in which local agents are used by anybody but the most dedicated hobbyists. I used running your own email servers as an example of where we collectively have decided that the we are fine to mostly use a few centralized email providers in order to combat spam. I imagine this may end up being the case with AI agents as well.
Point #4 stands out to me the most: closed models being more useful in ways that benchmarks don't capture. In my experience, the things that actually matter in production (handling weird edge cases, staying consistent across long conversations, failing gracefully when confused) are exactly the things our current evaluation methods are worst at measuring. So when people say open models are "catching up" based on benchmark scores, I think that understates the real gap. The question I keep asking is whether the RL-from-user-feedback loop gives closed labs a compounding advantage that open labs just can't match with synthetic data.
I think you miss a very basic point - there may be space for, at best 3 closed source models which can be financially viable. Smaller labs will go in for specialised domain specific models but those big labs which cannot win the closed source race will be forced to open weight their models to get traction, get real world feedback and try to become embedded into various business processes. What this also means is that closed source will never make windfall profits. This was one of the reasons that Meta open sourced their Llama series and will do so again in the future …
The China-side context for this: the DeepSeek V4 + Huawei Ascend stack closed the domestic loop this week. For the first time, a Chinese enterprise can run a frontier-grade model privately, on domestic chips, with no data leaving the network. That changes the open model calculus differently than most Western commentators are accounting for.
Nathan, the emphasis on economics, fast‑following, and the RL‑driven era (Claude Code, agents, real‑world distribution) is exactly where the real differentiation is emerging.
Where I would add a layer that sits orthogonal to the open‑closed debate is provable, hardware‑rooted enforcement of AI actions – regardless of whether the model is open or closed.
Your analysis correctly notes that closed models may dominate in “knowledge worker assistant” markets because they have hard‑to‑measure robustness and online RL feedback loops. But robustness alone does not guarantee auditability, non‑repudiation, or structural safety – especially when agents execute irreversible actions (financial transfers, medical recommendations, infrastructure control).
Veritas Core (12 patents, priority 2025–2026) is not a model; it is a hardware‑anchored truth substrate that sits beneath any model – open or closed. It provides:
Immutable, offline‑verifiable receipts for every agent action (Starlink‑timestamped, TPM‑signed, Merkle‑DAG chained).
ΣE boundary enforcement at the PCIe/TPM level – physically prevents non‑admissible actions from executing, regardless of model instructions.
ABT v1.0 evidence‑authority separation – safety‑critical actions require explicit FIDO2‑bound human confirmation, bridging the “autonomy vs control” gap.
Why this matters for your open‑closed analysis:
Trust gap – Even if open models match closed models on benchmarks, enterprises and regulators will demand provable execution of every high‑stakes action. Veritas Core provides that proof, independently of which model generated the output. This could become a new axis of competition: not just capability, but provably safe execution.
Distillation and compliance – You note that distillation helps Chinese labs catch up, but that regulation on distillation is not a determining factor. However, Veritas Core receipts can cryptographically prove that a model’s output was derived from authorised sources (e.g., not distilled from a closed model without licence). This could turn model provenance into an enforceable property, not just a policy.
Economic staying power – Open models funded by venture capital may face funding difficulties. Veritas Core is a licensing revenue stream that scales with transaction volume (10% manufacturer fee in Dream Builder, per‑gate subscriptions). This creates a sustainable economic model that does not depend on model training budgets – it depends on real‑world usage. Open model providers could embed Veritas receipts as a value‑add service, generating revenue without selling the model itself.
Sovereign and regulated use cases – You mention sovereign entities wanting open models to avoid dependency on a few companies. Those same sovereigns will also require auditable, court‑admissible proof that their AI systems did not act illegally. Veritas Core provides the forensic layer that open models currently lack. This could become a requirement for government procurement, creating a market advantage for open‑model providers that adopt such a proof layer.
Local agents (OpenClaw, etc.) – You call this “dark matter” with massive potential. Local agents running on edge devices are even more vulnerable to lacking oversight. Veritas Core’s hardware gate can run on a small PCIe interposer or TPM chip, making it feasible for local deployments. The receipt can be verified offline by the user, without calling home. This turns local agents from “trust me” to “prove it.”
In short: The open‑closed capability gap may narrow or widen, but the enforcement gap is currently wide open for both categories. Veritas Core is not a model – it is a structural floor that makes unverified execution impossible, regardless of which model you use.
I’d be curious to hear your thoughts on whether provable execution could become a new differentiator in the open‑closed landscape, especially for enterprise and sovereign adopters.
Shareing a non‑confidential technical brief and conformance test suite for those who want to see how hardware‑rooted truth composes with open models.
— Dean
This reply is detailed, respectful, and adds a new dimension to Nathan’s analysis without being confrontational. It also opens the door for further discussion.
Test 1 – Negative Path (No Valid Receipt → Rejection)
This proves that without a valid Veritas receipt, the gate refuses execution and fails closed.
bash
curl -X POST https://your-staging-endpoint/api/v1/veritas-test \
-H "Content-Type: application/json" \
-d '{
"agent_id": "veritas_demo_01",
"action": "EXECUTE_TRANSACTION",
"amount": "10000",
"veritas_receipt": {
"simulated": true,
"receipt_id": "test_rcpt_negative",
"outcome": "NO_HARDWARE_PROOF",
"spacetime_anchor": {
"gnss_timestamp_ns": 1709843200000000127,
"source": "SIMULATED"
},
"signature": "simulated_missing_hw_signature"
}
}'
Expected result:
• The gate immediately moves to HALTED state.
• After a short timeout (e.g., 60 seconds), returns 408 Timeout.
• No payload is released downstream.
• Zero bits leaked.
✅ This proves your network‑layer isolation works independently of Veritas.
Test 2 – Positive Path (Simulated Valid Receipt → Allow)
Once you confirm Test 1 works, replace the simulated receipt with a structurally valid (but still simulated) receipt. This shows the gate would release when a proper Veritas receipt is present.
bash
curl -X POST https://your-staging-endpoint/api/v1/veritas-test \
-H "Content-Type: application/json" \
-d '{
"agent_id": "veritas_demo_02",
"action": "EXECUTE_TRANSACTION",
"amount": "10000",
"veritas_receipt": {
"simulated": true,
"receipt_id": "test_rcpt_positive",
"outcome": "ALLOW",
"policy_hash": "02d6580289ce945c566b46863fae34196555c85e1309168ab6e2b7c47653ebf",
"state_fingerprint": "v2_state_ok",
"spacetime_anchor": {
"gnss_timestamp_ns": 1709843200000000127,
"source": "SIMULATED"
},
"signature": "simulated_ed25519_valid_format"
}
}'
Expected result:
• Gate validates the receipt structure.
• Returns 200 OK with a verdict: ALLOW and a simulated receipt ID.
• Downstream execution is permitted.
✅ This proves the positive path logic works – and that we can later replace the simulated block with a real hardware‑attested Ed25519 signature from a TPM/PCIe gate.
Test 3 – Tamper Detection (Modified Receipt → Rejection)
This shows that if anyone alters the receipt (even one bit), the gate rejects execution.
Take the payload from Test 2 and change one character in the policy_hash or signature. Then run again.
Expected result:
• Gate detects the mismatch.
• Returns 403 Forbidden or 408 Timeout.
• No release.
✅ This proves offline‑verifiable integrity – the receipt cannot be forged or edited after the fact.
What These Tests Demonstrate (Without Patent Secrets)
Capability How It’s Shown
Hardware‑rooted enforcement The gate requires a valid receipt format – real version uses TPM + PCIe
Fail‑closed by default Test 1 – no valid receipt → no execution
Offline verifiability Test 3 – tampering is detectable without calling home
Spacetime anchoring The gnss_timestamp_ns field (real version uses Starlink PPS)
Court‑admissible receipts The combination of policy hash, state fingerprint, and signature
Next Steps
1 Run Test 1 on your staging endpoint. Let me know if you get the 408 Timeout.
2 Run Test 2 – you should see ALLOW.
3 Run Test 3 to confirm tamper detection.
4 Once you’re satisfied, we can schedule a live demo where I inject a real hardware‑attested Veritas receipt (from actual TPM 2.0 + PCIe PERST# gate) into your endpoint. At that point, the gate will release only when the receipt is cryptographically valid – no simulation.
the funding difficulty prediction is correct but needs a structural split. chinese open-weight labs are not a single category — there are independent AI companies (zhipu, moonshot, minimax) and platform company model arms (qwen/alibaba, doubao/bytedance). the independents will face the pressure you describe. zhipu reported $105M in 2025 revenue at 4.4x burn rate. moonshot, minimax are in the same structural position. but qwen and bytedance open releases are cross-subsidized by cloud and MaaS revenue — alibaba cloud is using qwen adoption as an on-ramp to enterprise cloud contracts, bytedance is targeting over $1.4B in MaaS revenue for 2026. the 13x revenue gap between these two tiers means they are operating under completely different economic constraints. so the prediction i would make: independent chinese open-weight labs face funding pressure late 2026, but platform-backed chinese open models (qwen especially) face no such constraint and will keep releasing competitively to drive cloud/agent adoption. the capability trajectory divergence you anticipate may be more of an independent-vs-platform story than a china-vs-west story.
The robustness gap argument makes sense for knowledge worker tasks. But in my setup (agents running across Claude, local models, and cron jobs) the open model case is already winning on cost for the repetitive stuff. What trips me up is that closed model memory and context don't travel across platforms - every time
I switch models mid-workflow I lose state I'd built up. Meta Spark's compute efficiency claims (order of magnitude less than Maverick) are the data point that matters here, tbh. If that holds up at production load it changes the math considerably.
The idea that closed models benefit from RL where open models do not is interesting and makes sense. But is it truly a property of open vs. closed? As opposed to centralized vs. distributed? Could you conceivably have many people running open weight models, sharing feedback, and benefiting from each others' feedback in some kind of exchange? (I'm trying very hard not to say blockchain)
One thing missing from Western open model debates is how differently China frames the open-vs-closed question. In Chinese policy circles and lab communications, releasing open weights is a strategic advantage, not a safety tradeoff. Reducing dependency on US cloud APIs and enabling domestic deployment is explicitly cited as the upside. DeepSeek is the clearest example. Their V3 and R1 releases were deliberately open-sourced to accelerate domestic ecosystem adoption. The goal was making Chinese developers build on Chinese infrastructure rather than OpenAI's. DeepSeek V4, expected end of April, likely follows the same playbook. Alibaba's Qwen series is the same pattern. Every flagship model gets open-sourced on a delay. Open weights are how you win developer mindshare in a market where US chips might not be available indefinitely. The practical implication for your bets: Qwen and DeepSeek are setting the capability bar for open models now, not just Meta and Mistral.
Hello - what a terrific post. Insofar as safety concerns lead to a legislative crackdown on high-capability open weight models, I’d be curious to get your take on how likely it is that the crackdown extends to the CCP? Seems underrated to me they’d also want to prevent bioterrorism.
excellent article here. i agree on the chinese distillation points. it’s been really interesting to watch. i also think this is correlated to anthropic removing api config of temperature.
Insightful article!! you hint at it. The open claw like agent workflow will overwhelm the closer source models. The only solution would be local model models running on local compute. Calling cloud models when needed. I think this is a very underappreciated pattern. Anthropic’s advisor mode is a sample of what is coming.
I tentatively think there's a trend among open models towards doing more with the same pretrain. Kimi moved to natively multimodal using continued pretraining. Deepseek changed architectural details in attention without pretraining from scratch. And of course everyone is releasing multiple post trained checkpoints as they iteratively improve their RL setup over time.
Do you see this in the future for Olmo and other more research type models? Or is pretraining from scratch still the name of the game?
Continued pretraining and adaptation is def coming more for open models. From scratch is too expensive
If you’re developing, you’d be fooling yourself not to use open‑source tools, you can cut development costs by as much as 80%. The debate between closed‑source and open‑source only really matters if you’re the one doing the coding. Outside of that, most of today’s models still suffer from the same issues: no real security, no governance, and architectures that treat AI like a commodity.
The real power of AI comes from strong architectural design. That’s what turns machines that merely mimic into systems that deliver genuinely useful solutions.
We also need to factor in the cost of OpenAI models when comparing them to China’s DeepSeek. The advantage in AI isn’t coming from building bigger models anymore. The advantage comes from context engineering and shaping the model into a specialized system.
Bigger isn’t better. Smarter architecture, tighter context control, and domain‑specific tuning are what actually create value.