NewSovereign AI: private AI infrastructure on hardware you rent or own, fully managed.
NewSovereign AI: private AI infrastructure on hardware you rent or own, fully managed.
Oct 29, 2026
Written by: Blake Kinnan
Migrating from OpenAI to open models: same code, from our cloud to your air gap.
It is a familiar scene on a space program. An engineer has ChatGPT open in one tab and a thermal-vacuum test report in the other. The report is exactly the kind of work AI is good at: forty pages of anomalies, deviations and retest notes that need a summary before tomorrow’s review. But the report is export-controlled technical data, so it cannot go into a public AI service. So the engineer closes the tab and starts reading.
In short, that is where most space teams are with AI today. It helps with email, meeting notes and code that has nothing to do with the vehicle, and it stops exactly where the mission starts.
There is a way through that does not need a ban, a policy exception or a year-long infrastructure project. Open-weight models are now strong enough for most day-to-day engineering work, and they can run behind an OpenAI-compatible API: the same interface your team’s code and tools already use. Run them in a private cloud first, then on a self-hosted LLM platform inside your own walls, and the code does not change along the way.
This guide covers what that migration looks like for an aerospace or space team: what changes in the code (very little), what to test before you switch, which model fits which job, and how to get from a first API call to an air-gapped system.
Technical data about launch vehicles, spacecraft and their subsystems is often controlled under ITAR or the EAR. Sharing it with a foreign person counts as an export, even inside the United States, and Department of Defense contracts add their own rules for Controlled Unclassified Information (CUI). Government editions of some AI services exist for agencies and qualified contractors. Unless you qualify and have access to one authorized for your data, a public AI service processes your prompts on servers, and with staff, that you do not control. And even with a government edition, the model and its roadmap still belong to someone else. That is why most export-control policies keep controlled data off those services entirely.
So teams end up choosing between two bad options.
Ban it – Keep AI away from anything controlled. In practice, the work falls behind teams that use AI, and engineers under deadline pressure start wondering whether a paragraph or two really counts. In other words, a ban without an alternative creates the risk it was meant to prevent.
Build it – Stand up private GPU infrastructure, choose and serve models, and wire everything into your tools. That usually means hiring HPC and MLOps engineers the market barely has, then six to twelve months of setup and testing. Every month spent building is a month your program waits.
Side by side, the options look like this:
| What matters | Public AI service | Build it yourself | Hoonify |
| Time to running | Minutes, on their servers | 6 to 12 months | Same day in our cloud, weeks on your hardware |
| Where your data lives | On their servers | Inside your walls | Our cloud, or inside your walls |
| Air-gapped option | No | Only after you build it | Yes |
| Runs AI and HPC | AI only | Two separate builds, two teams | Yes, fully managed |
| A model you own | No | Yes, but you tune and maintain it | Yes, tuned on your data |
| Expertise needed in-house | Some, plus a support queue | An HPC and MLOps team | None: it is our team |
The third option is the subject of this guide: open-weight models behind an OpenAI-compatible API, running where your data is allowed to be. Engineers get a secure ChatGPT alternative that works with the tools they already use. Your export-control officer gets a system where the data, the model and the logs stay on infrastructure you control.
One caveat up front: this is an engineering guide, not legal advice. Your export-control officer decides which data can go where. Still, the architecture below is designed to make that decision easy to enforce.
OpenAI’s API has become the common language of AI software. For example, SDKs, agent frameworks, coding assistants and RAG tools all speak it. An OpenAI-compatible API accepts the same requests and returns the same responses, so anything written against OpenAI can talk to it.
As a result, for most code, the migration is three lines: the base URL, the API key and the model name.
import os
from openai import OpenAI
client = OpenAI(
+ base_url="https://api.hoonify.ai/v1",
- api_key=os.environ["OPENAI_API_KEY"],
+ api_key=os.environ["HOONIFY_API_KEY"],
)
response = client.chat.completions.create(
- model="gpt-5",
+ model="zai-org/GLM-5.2",
messages=[
{"role": "system", "content": "You are a test engineer's assistant."},
{"role": "user", "content": "Summarize the anomalies in this report: ..."},
],
)
print(response.choices[0].message.content)
Many tools need no code change at all. The official OpenAI SDKs read the OPENAI_BASE_URL and OPENAI_API_KEY environment variables, so pointing those at a different endpoint redirects every call. Likewise, most AI tools that let you set a custom endpoint work the same way.
The savings show up quickly. Joel Long of Rook compared it with what he had built before on OpenAI’s Codex:
“I rebuilt a dashboard that ties together my accounting, my CRM, everything – far more complex than what I’d built before with Codex, and it cost about $60 instead of $600 in tokens. If not less.”
Compatibility covers the interface, not the model’s behavior. Open models are strong, but they are not GPT, and a production workload deserves a day of testing before it moves. Check these:
zai-org/GLM-5.2 or Qwen/Qwen3.6-27B. IDs are case-sensitive.
There is no single best model, only a best model for each job. When it comes to code generation, I talked about this in, Best Open-Source LLMs for Coding in 2026: How to Choose. For this article, these are our starting recommendations for common aerospace and space work, matched to the models in the Hoonify Catalog today:
The job on an aerospace program
Use case
Runs great on
A private assistant for every engineer: drafting, summarizing, reviewing
Secure AI
GLM-5.2
Answers from test reports, anomaly and nonconformance history, requirements and interface control documents
Search & Retrieval (RAG)
Qwen3.6-27B
Agents that pull telemetry, draft reports and wait for a human sign-off
Agentic Workflows
Inkling-Small
Work on a disconnected or classified network
Air-Gapped AI
GLM-5.2 or Qwen3.6-27B
A model that knows your formats, acronyms and edge cases
Fine Tuning
Qwen3.6-27B
Two of these deserve a closer look.
The fastest win is usually the plainest one: an assistant engineers will actually use, because it is allowed to see their real work. After all, enterprise AI assistants stall on data privacy far more often than on model quality. When the assistant runs on infrastructure you control, with zero data retention and no training on your prompts, the policy question has a clear answer.
RAG lets a model answer from your own documents instead of its training data, and cite where each answer came from. For a space program in particular, the corpus writes itself: test reports, failure review board records, nonconformance reports, requirements, interface control documents and lessons learned. An enterprise RAG platform built inside your walls turns years of program history into answers in seconds. That matters most when the person who remembers the last anomaly has moved to another program.
The lineup changes as better open models ship, so check the Catalog for current models, context windows and pricing.
The path from a first API call to an air-gapped system has three stages. You move up when the volume, the model or the data demands it, and apart from one URL, the code your team writes in the first stage is the code it runs in the last.
Each stage keeps the same models and the same OpenAI-compatible code. What changes instead is where it runs.
Create an account and point your code at the API. You pay per token on shared capacity, with zero data retention by default and no training on your prompts. First, use work that is not export-controlled to prove the workflow: public documentation, internal tools, and code and procedures that carry no controlled data. Within days you will know which models fit which jobs, and you will have the evaluation set from the checklist above.
When volume grows, when you need a specific model, or when the data needs stronger protection, move to dedicated compute: GPUs reserved for your team in our cloud. You still get the same API and the same code, on capacity nobody else shares. Our engineers size it with you, from how many GPU servers for LLM inference you need to which models run on them.
When the data is export-controlled, our engineers scope the system with you: the mission, the data and the security requirements. We size the private AI infrastructure, decide with you whether HPC simulation should share it, and deliver it on your hardware, on-prem or fully air-gapped. Same models, same code: the only change is the base URL, which now points at an endpoint inside your network. Nothing leaves your walls and nothing calls home. This is where controlled technical data finally meets AI.
An enterprise self-hosted LLM usually implies a team to run it. Here, however, it is self-hosted on your hardware and fully managed by our engineers, who come from the DOE national labs that ran the world’s fastest computers. On your own hardware, that means a working system in weeks rather than the six to twelve months of hiring, testing and setup an in-house build usually takes.
A closed API rents you someone else’s intelligence. Open weights, on the other hand, let you own it.
Once the system runs inside your walls, you can fine-tune an open model on your own data: your report formats, your acronyms, your part numbering, your edge cases. As a result, the model writes like your team and knows what your team knows, and you keep the weights. What your engineers learn stays in a model your company owns, not on a provider’s roadmap.
Open weights also mean no lock-in. If a better model ships next quarter, you can move to it. And if you ever leave Hoonify, you still leave with your code.
Space programs do not only run AI. They run computational fluid dynamics (CFD) for launch and re-entry, structural and vibration analysis for launch loads, thermal models, and radiation transport for shielding and dose. Most teams buy that compute separately from AI, with a separate team, separate hardware and data copied between the two.
Hoonify’s software products bring the flexibility of having both sovereign AI and HPC together, removing that split. It stands up a full HPC environment in about an hour, tying CPUs and GPUs into one system for modeling and simulation. Pre-validated modules include Ansys Fluent, STAR-CCM+, OpenFOAM and MCNP, and you bring your own application licenses.
Running AI and HPC on one system opens workflows that are hard to build any other way: an assistant that searches simulation results next to the test reports they predicted, or a model fine-tuned on years of analysis history. Start with either one and then add the other, with no second vendor to manage.
If you are a developer ready to try the code change, start in our cloud. New accounts currently get $10 in credits, and the base URL swap takes minutes. Then bring a workload that is not export-controlled and run your evaluation set against GLM-5.2, Qwen3.6-27B and Inkling-Small.
If your data is export-controlled, talk to an expert. Bring the mission, the data and the security requirements, and our engineers will map the path from our cloud to a system inside your walls. You can also see how we support aerospace and defense programs.
Your engineers already know what AI can do for them. A model you own, on infrastructure you control, lets them use it on the work that matters. You bring the mission. We handle the rest.
No. It uses the same request and response format, so your code and tools keep working, but the model is open-weight and runs on infrastructure that we or you control. Your prompts never go to OpenAI.
Yes, on the Enterprise stage, where the system is yours alone: on-prem, air-gapped, or a private cloud we host for you and your team reaches through a VPN tunnel. Talk to an expert to find the right fit. Your export-control officer has the final say.
Not for Serverless or Dedicated: we run the GPUs. For Enterprise, we size the GPU servers with you and our engineers manage the system on your hardware, so you do not need to hire an HPC or MLOps team.
Yes. Talk to an expert at Hoonify. We’ll learn about your use cases and help you narrow down the models worth testing.
Blake Kinnan is Co-Founder and VP of Strategic Intelligence at Hoonify, where he tracks the AI infrastructure landscape – models, silicon, licensing, and deployment economics – to inform product and go-to-market decisions across the executive team.
Hoonify runs AI and HPC for organizations that can’t afford to get it wrong. Our founders come from Cray and Sandia National Laboratories, and our team brings more than 100 years of national lab engineering to every system we build. We learned our standards in places where a wrong answer is worse than no answer: national labs, defense programs, energy research, and life sciences. For five years, we’ve run TurbOS, our HPC software, in production for customers including Los Alamos and Sandia National Laboratories. Now we bring that same discipline to AI. Customers choose Sovereign AI, Sovereign HPC, or both, fully managed by our engineers. They can start in our cloud and move on-prem or air-gapped when they’re ready, with open models, standard APIs, and no lock-in along the way. You keep the data, the hardware, and the roadmap. We keep it running.
