Last updated: June 24, 2026
GLM-5.2 (Z.ai) and Kimi K2.7 Code (Moonshot AI) are large open-weight coding models released in the same June 2026 window. Their licenses are permissive, their API prices sit far below the US frontier, and the launch timing made them look like a sovereignty answer after Anthropic’s Fable 5 and Mythos 5 access was restricted. The real buyer question is narrower: can you run the model inside your own boundary, and what happens to your code when you cannot?
Here is what most launch coverage skipped. Running GLM-5.2 in its FP8 build takes around 744GB of GPU memory by independent testing, and the full model runs past a terabyte. Kimi K2.7 Code ships natively quantized to 4-bit and still lands near 640GB. The licenses are permissive in a way that holds up to reading the files. And if you use the hosted API, your contract is with a Singapore company under Singapore law, not Chinese law as much of the panic assumed. The binding constraint is not where the loudest takes are pointing.
Use GLM-5.2 or Kimi K2.7 Code for non-sensitive coding work after your own evaluation. Do not treat either as sovereign infrastructure unless you can self-host the build you rely on and verify the data path. If you cannot self-host, this becomes an API governance decision, not an open-source one.
The license is real. The sovereignty story is conditional. Both models ship downloadable weights under permissive licenses, but a license grants permission, not operation.
The hardware is the catch. GLM-5.2 in FP8 needs around 744GB by independent testing and runs past a terabyte at full precision. Kimi K2.7 Code, which ships at native 4-bit, still lands near 640GB. Most teams cannot self-host, so they land on the vendor API.
Your code does not obviously go to China, and that is not the same as safe. Both APIs are contracted through Singapore companies under Singapore law. Singapore has no EU adequacy decision, so for EU teams this is still a third-country transfer, and privacy terms still allow sharing with affiliates, service providers, and authorities.
The data terms split by tier, and they favor Z.ai on the API. Z.ai’s API will not train on your content unless you agree. Kimi’s API trains by default and restricting it requires an enterprise arrangement. Both API terms bar protected health data.
The benchmarks describe a build you may not run. Vendor scores come from full-precision or specific-mode runs. The build that fits affordable hardware has a quality gap nobody has published. FSR has not run either model yet.
What happened
Moonshot AI released Kimi K2.7 Code on June 12, 2026, with the model repository on Hugging Face dated June 11. Z.ai announced GLM-5.2 on June 15 through its official account on X, followed by a co-authored Hugging Face blog on June 16, with some coverage describing an earlier rollout to coding-plan subscribers. Two large coding releases in the same news window.
That window did the framing. Anthropic’s own launch page now reads that access to Claude Fable 5 and Claude Mythos 5 was removed for all users, with an update dated June 12. Reporting on a letter obtained by Bloomberg describes the US Commerce Secretary directing Anthropic to restrict the models over an “unacceptable risk” of military-intelligence end use, requiring export licenses worldwide. The primary directive has not been published. Into that gap, developers and the press started calling GLM-5.2 and Kimi K2.7 Code the open alternative for anyone shut out of the US frontier.
The timeline created a narrative the vendors never stated. Neither Z.ai nor Moonshot said, in any source FSR could find, that their release was a response to the export restriction. That connection is built on timing, not on a vendor claim. It matters because the rest of this review depends on separating what the companies actually committed to from what the internet decided they meant.
Best for, not for
Verified key facts
Facts, vendor claims, and unverified community signals should not share a row. The table tags each one. Figures read directly from primary sources are marked VERIFIED, vendor assertions are OFFICIAL CLAIM, and deployment numbers from non-vendor write-ups are THIRD-PARTY.
| GLM-5.2 (Z.ai) | Kimi K2.7 Code (Moonshot) | Status | |
|---|---|---|---|
| License | Standard MIT, no added clauses | Modified MIT: MIT plus one UI-display clause above 100M MAU or $20M/month revenue | VERIFIED (license files) |
| Architecture | Sparse MoE. Vendor pages disagree: 753B vs 744B total / ~40B active. Context 1M | MoE, 1T total / 32B active, 256K context, 400M vision encoder, native INT4 | OFFICIAL CLAIM |
| API price (per 1M tokens) | $1.40 input / $4.40 output | $0.95 input / $4.00 output (cache hit $0.19) | VERIFIED (pricing pages) |
| Self-host memory | FP8 ~744GB, 8×H200 class. INT4 ~372GB, 4×H200. Full precision past 1TB | Native INT4 ~630 to 640GB, 8×H200 class. Higher precision toward 2TB class | THIRD-PARTY (not measured by FSR) |
| API contracting entity | JINGSHENG HENGXING TECHNOLOGY PTE. LTD (Singapore) | Moonshot AI PTE. LTD. (Singapore) | VERIFIED (terms of service) |
| Governing law | Singapore, SIAC arbitration | Singapore, SIAC arbitration | VERIFIED (terms of service) |
| API training on your content | Off unless you explicitly agree | On by default; restrict only via enterprise arrangement | VERIFIED (terms of service) |
| Protected health data (API) | Barred for US users (HIPAA, plus GLBA and COPPA categories) | Barred (HIPAA Protected Health Information) | VERIFIED (terms of service) |
| Published DPA | References a Data Processing Addendum for API Services (full text not obtained) | No public DPA located in the OpenPlatform terms checked | VERIFIED reference / NOT FOUND |
| US Entity List | Zhipu’s Beijing entity listed (Jan 16, 2025). Commercial entity is separate; full structure not mapped by FSR | Not found on the list in sources checked; needs a manual screen | VERIFIED / NEEDS CHECK |
For reference, GPT-5.5 lists at $5 input and $30 output per million tokens at standard context, and Claude Opus 4.8 at $5 and $25, with frontier long-context tiers running higher. The two Chinese models price API access at roughly a sixth of the US frontier on input. That gap is real and it is why both are getting attention.
The real catch is not the license
A common complaint after launch was that these models are not “really” open. One developer argued GLM-5.2 fails the open-source definition and that Z.ai had only opened an older model. On the license itself, that does not survive reading the files.
FSR opened both LICENSE files. GLM-5.2 ships standard MIT, headed “Copyright (c) 2026 Zhipu AI,” with the canonical permission grant and warranty disclaimer and nothing added. There is no regional limit, no commercial cap, no field-of-use clause.
Kimi K2.7 Code ships “Modified MIT,” headed “Copyright (c) 2026 Moonshot AI.” It carries the full standard MIT text and then one extra paragraph, which the file itself introduces with the words “Our only modification part is that.” The modification: if your product or service crosses 100 million monthly active users or 20 million US dollars in monthly revenue, you must display “Kimi K2.7 Code” on the user interface. For teams below hyperscale, the clause functions as UI attribution, not a commercial-use blocker.
So the license is not the binding constraint. Both are open weight in the practical sense that you can download, modify, and ship them commercially. The harder question is the one underneath: can you actually run the weights, and if you cannot, where does your code go instead?
That is not always true of Chinese open-weight models; MiniMax M2.7 carries a license catch most buyers never read.
Self-host or API: the floor that decides for you
This is the structural finding. Open weights only deliver data control if you can run them inside your own boundary, and the hardware says most teams will not.
| Build | GLM-5.2 (744B, ships FP8/BF16) | Kimi K2.7 Code (1T, ships native INT4) |
|---|---|---|
| Full precision | BF16 past 1TB, community reports near 1.5TB | FP16 roughly 2TB class by deployment math |
| FP8 | ~744GB, 8×H200 class | Not the shipped format |
| INT4 / 4-bit | AWQ ~372GB, 4×H200 class | Native ~630 to 640GB, 8×H200 class |
| 2-bit (extreme) | ~238GB at a reported 82% accuracy retention | ~325GB at ~40 tokens/sec |
The memory column is the buyer boundary. An 8×H200 node is not a normal startup, agency, or mid-market inference footprint. There is a tier difference between the two as well: GLM-5.2 can be squeezed down to roughly 372GB at INT4 or lower at 2-bit, while Kimi K2.7 Code already ships at native 4-bit and still needs around 640GB, with no lighter production path short of community 2-bit builds. One engineer reported fitting GLM-5.2’s full one-million-token context on an 8×H200 node only after quantizing further, which means even reference-class hardware trades precision to hold the advertised context. For most buyers, the honest options are a quantized build on hardware they own, or the vendor API. That is the first finding in one line: open weight does not equal self-hostable, and the path that stays open for most teams runs back through the vendor.
The second finding follows. The benchmark numbers in the launch posts describe a build many buyers will not run, and the gap is shaped differently for each model. Kimi ships at native 4-bit, so its scores may have been produced on the same build a self-hoster runs, which would narrow the gap, except that the model card does not state the benchmark precision. GLM-5.2’s headline scores are full-precision claims, so the quality drop from the benchmark build to an INT4 self-host build is more likely to be real and is not published anywhere. One community report put GLM-5.2’s 2-bit build at 82% accuracy retention. For Kimi K2.7 Code, no comparable INT4 retention figure surfaced, and some practitioners have said its benchmarks do not reproduce. The point is not that the models are weak. It is that the advertised score and the score you can self-host are two different numbers, and the second one is missing.
FSR has not run either model. The gap stays unmeasured here, and section 9 explains why the hardware that creates it also keeps most reviewers from measuring it.
Data, terms, and the EU angle
This is where the panic narrative and the hype narrative both come apart, so it is worth being exact. FSR read the live terms for each surface rather than relying on summaries.
Contracting and governing law. Z.ai’s developer terms name JINGSHENG HENGXING TECHNOLOGY PTE. LTD, a Singapore company, as the contracting entity, governed by Singapore law with arbitration at the Singapore International Arbitration Centre. Kimi’s OpenPlatform terms name Moonshot AI PTE. LTD., also a Singapore company, on the same Singapore-law and SIAC footing, and the consumer Kimi terms at kimi.com name the same Singapore entity. Whatever is true about either company’s headquarters, the API contract a customer signs is Singaporean. FSR did not verify any China-domestic consumer service that may operate under different terms.
Where the data sits, stated carefully. Both privacy policies describe processing or storage in Singapore. That is not the same as “your code does not go to China,” and it is not the same as safe. Privacy terms on both sides retain the usual sharing categories with affiliates, service providers, and authorities, and Z.ai’s developer terms reserve the right to process individual-user content outside the user’s jurisdiction. A stated processing location is a starting point for a transfer assessment, not a guarantee.
Training on your prompts. Here the two diverge by surface, and the direction is the opposite of what a price-first read suggests. Z.ai’s API terms state that it will not use your content to develop or improve services unless you explicitly agree, which is the stronger position for a developer. Kimi’s OpenPlatform terms state that content may be used to develop and improve the services, and that a customer who wants restrictions must contact Moonshot to discuss an enterprise arrangement or a separate written agreement, with the default being that content may be used. Kimi’s consumer terms are softer than its API terms here, offering an email opt-out, but the consumer service is not the procurement surface. On the path a serious team would use, the cheaper API is the more exposed one on training.
Regulated data. Both API terms close the door on protected health data. Kimi’s OpenPlatform terms prohibit processing HIPAA Protected Health Information outright. Z.ai’s terms bar US users from processing HIPAA, GLBA, and children’s data categories, and from moving export-controlled technical data through the service. For healthcare, financial, or children’s-data workloads on the self-serve API, both are out by their own terms.
The EU layer. There is no EU adequacy decision for China, and none for Singapore either, so transfers of personal data to either vendor fall under the GDPR’s Chapter V and require a lawful transfer mechanism plus, by European Data Protection Board guidance for China-bound data, a transfer impact assessment with supplementary safeguards. On the EU AI Act, open-weight general-purpose models do receive a partial exemption under Article 53(2) from the technical-documentation and downstream-information duties, but the copyright-policy and training-data-summary obligations still apply, and if either model crosses the systemic-risk compute threshold the exemption falls away. Neither vendor discloses training compute, so that classification cannot be confirmed.
The Entity List, stated carefully. Zhipu AI appears on the US Entity List as “Beijing Zhipu Huazhang Technology Co., Ltd.,” effective January 16, 2025, with a presumption-of-denial license policy. That is a real procurement signal for US federal and contractor use. Two qualifications keep it accurate. The commercial Z.ai API is operated by the separately named Singapore entity above, and FSR did not independently map the corporate structure linking the listed Beijing entity, the Singapore operating entity, and the Hong Kong-listed issuer associated with Zhipu. Moonshot did not appear on the Entity List in the sources checked, and that absence should be confirmed against the current screening lists rather than assumed.
On the DPA. Z.ai’s developer terms reference a Data Processing Addendum for API Services, though FSR did not obtain its full text. No equivalent public DPA or subprocessor list was located in Kimi’s OpenPlatform terms. For a regulated buyer, that difference matters: one vendor at least points to a processing addendum, while the other leaves a standard procurement document missing from public view.
Who this affects, and who it doesn’t
The right buyer split is not China versus the US. It is sensitive data versus disposable code.
The teams that should slow down are the ones whose prompts or repositories carry something they cannot afford to leak or to feed into training: regulated data, client-confidential source, anything under an NDA. For them the API path is a third-country transfer through a Singapore-contracted, China-headquartered provider, with default-on training on the Kimi side and no public DPA on either side that a procurement team could file. FSR reached the same posture on DeepSeek V4: a tool to rent for a task, not a vendor to marry into your stack. US federal and contractor buyers carry the added Entity List question on the Zhipu group’s Beijing entity. EU teams carry the no-adequacy transfer problem regardless of which vendor they pick.
The teams that can ignore most of this are the ones working on code that does not matter if it leaks: hobby projects, public repositories, throwaway agents. So can any team with the hardware to self-host the exact build it depends on, and any team that treats benchmarks as a screening signal and runs its own evaluation before trusting either model. The license is clean enough that none of these users needs to think hard about it.
The blind spots most coverage misses
Two opposite errors are circulating at once, and both are wrong.
The hype error treats open weights as a free sovereignty switch. Download the model, escape the vendor, own the stack. The hardware floor breaks that for most teams, and the moment they fall back to the API the dependency moves from Anthropic to Z.ai or Moonshot. It did not disappear. It changed address. FSR drew the same line on Sakana Fugu, which reads as an orchestration hedge rather than sovereign AI.
The panic error is the mirror image: your code goes to China. The terms point elsewhere. Both APIs are contracted through Singapore companies under Singapore law, with disputes routed to arbitration in Singapore, and both privacy policies describe Singapore processing. The Entity List flag attaches to Zhipu’s Beijing research entity, which is separately named from the company a customer contracts with for the API. That does not make the data risk zero, but “China” is the wrong word for it.
The real risks are narrower. Singapore has no EU adequacy decision, so an EU team is still making a third-country transfer. The Kimi API trains on customer content by default and asks you to negotiate an enterprise deal to stop it. Neither vendor publishes a subprocessor list. The advertised benchmarks describe a build the buyer may not run. And Kimi forces thinking mode on with no way to disable it, while its docs confirm that reasoning content counts toward your token quota, so the bill on a long agentic run climbs in a place the headline price does not show.
A smaller blind spot, but a telling one: the vendor’s own documentation cannot agree on GLM-5.2’s size. The model page says 753B parameters. The model table says 744B. Z.ai has not reconciled the two. When the basic spec sheet contradicts itself, treat every single-source number on that page as provisional.
What FSR checked, and what it didn’t
This is a Tier C research briefing. No hands-on testing was performed. Saying so plainly is part of the method.
Read at primary source: both LICENSE files on Hugging Face; the Z.ai developer terms and the Kimi OpenPlatform API terms, including contracting entity, governing law, training-use, and regulated-data clauses; the Kimi consumer terms; Z.ai’s published API pricing; Moonshot’s published API pricing; the Hugging Face model cards; and the EU adequacy and AI Act provisions cited. The US Entity List entry for Zhipu’s Beijing entity was confirmed through the Federal Register listing and corroborating sanctions trackers.
Treated as a visible sample, not as fact: the self-host memory figures and quantization quality numbers come from independent deployment write-ups and developer posts. They are consistent across several sources but were not measured by FSR.
Not verified, and flagged rather than asserted: the corporate-structure mapping between Zhipu’s listed Beijing entity, the Singapore operating entity, and the Hong Kong issuer; the full text of Z.ai’s referenced data-processing addendum; whether Moonshot appears anywhere on the current screening lists; training-compute figures for either model; and, most importantly, the quality of the quantized self-host builds against the vendor benchmark builds.
The follow-up, split by what is reachable. One part is cheap. Running the same repository-scale task through both APIs and reading the returned usage objects would set the displayed price per million tokens against the real per-task cost once Kimi’s forced reasoning tokens are counted. That is an API governance number, not a sovereignty one, and it is the next thing worth checking.
The self-host quality gap is the part that does not close easily, and the reason is the finding restated. Measuring how far an INT4 or 2-bit build drifts from the vendor benchmark means standing the model up on 4 to 8 H200-class GPUs, the same 372GB to 744GB floor that pushes most teams onto the API to begin with. The hardware that gates self-hosting also gates independent verification of the self-hosted build. The only parties who can measure that drift cheaply are the vendors, and neither has published it. So this review leaves the number where it found it, unmeasured, and out of reach for almost any reviewer working without a funded GPU budget. If access at that scale opens up, FSR will run it and report declared hardware, build source, and quantization method. Until then the launch benchmarks are a ceiling, not a forecast.
FAQ
Is GLM-5.2 really open source? GLM-5.2 ships under a standard MIT license with no added clauses, read directly from the license file. MIT is an OSI-approved license, so GLM-5.2 is open source in the strict sense, and it allows commercial use, modification, and self-hosting without regional limits.
Is Kimi K2.7 Code open source or just open weight? Kimi K2.7 Code uses a modified MIT license. It keeps the full MIT permissions and adds one requirement: display “Kimi K2.7 Code” in your interface if your product passes 100 million monthly active users or $20 million in monthly revenue. That makes it open weight under a near-MIT license, permissive for almost every team but not identical to plain MIT.
Can I self-host either model on normal GPUs? Not on consumer hardware. By independent testing, GLM-5.2 in FP8 needs around 744GB of GPU memory and Kimi K2.7 Code lands near 640GB at native 4-bit, both 8×H200-class. Aggressive 2-bit builds drop GLM-5.2 toward 238GB but trade away quality the vendors have not quantified.
Does using the API send my code to China? Not by the terms. Both APIs are contracted through Singapore-registered companies under Singapore law, and both privacy policies describe Singapore processing. The real concerns are different: Singapore has no EU adequacy decision, Kimi’s API trains on your content by default, and both terms still allow sharing with affiliates, service providers, and authorities.
Can a healthcare team use the Kimi or GLM API with patient data? No. Both API terms prohibit it. Kimi’s OpenPlatform terms bar processing HIPAA Protected Health Information, and Z.ai’s terms bar US users from processing HIPAA, GLBA, and children’s data categories through the service. PHI workloads are out of scope on the self-serve API for both.
Which model should a startup choose? It depends on constraints, not on a benchmark. GLM-5.2 self-hosts smaller at INT4 and its API will not train on your content unless you agree. Kimi K2.7 Code is cheaper per token but trains by default on the API. Independent head-to-head quality data is still thin, so run your own evaluation first.
Why aren’t the benchmarks enough? The published scores come from full-precision or specific-mode runs, and most teams will run a quantized self-host build or an API with different settings. The quality gap between the benchmark build and the build you actually run has not been measured or published, so the launch numbers are a ceiling, not a forecast.
FSR verdict
GLM-5.2 and Kimi K2.7 Code are two of the most visible open-weight coding releases in this window, and the open part is real. The licenses hold up, the API pricing undercuts the US frontier by a wide margin, and the claim that your code goes to China is not supported by either company’s API terms.
The sovereignty story is the part that does not hold. Open weights buy data control only if you can run the inference yourself, and a floor of roughly 640GB to 744GB, past a terabyte at full precision, pushes most teams onto the vendor API. There the dependency moves to a Singapore-contracted, China-headquartered provider, with a third-country transfer, no public subprocessor list, default-on training on the Kimi API, and an Entity List flag on the developer’s Beijing entity. The license risk is the small risk. The infrastructure, data-use, and token-accounting risks are the real ones.
Use them for non-sensitive code, and self-host if you have the hardware. Pause before routing regulated or confidential data through the self-serve API, get enterprise terms in writing, and prefer the vendor whose default does not train on your content. Do not treat the launch benchmarks as your buying number; The build you can self-host carries an unmeasured quality gap, and the same hardware floor that creates it keeps it unmeasured for everyone but the vendors.
Sources
Primary and official, read directly:
- GLM-5.2 LICENSE file (standard MIT): huggingface.co/zai-org/GLM-5.2 (LICENSE)
- Kimi K2.7 Code LICENSE file (Modified MIT): huggingface.co/moonshotai/Kimi-K2.7-Code (LICENSE)
- Z.ai Terms of Use and Additional Terms for API Services: docs.z.ai/legal-agreement/terms-of-use
- Kimi OpenPlatform (API) Terms of Service: platform.moonshot.ai/docs/agreement/modeluse
- Kimi consumer Terms of Service: kimi.com/user/agreement/modelUse
- Z.ai API pricing: docs.z.ai/guides/overview/pricing
- Kimi API pricing: platform.moonshot.ai
- Z.ai GLM-5.2 announcement: x.com/Zai_org and the Hugging Face GLM-5.2 blog
- US Entity List (Zhipu Beijing entity): US Federal Register, effective January 16, 2025
- EU adequacy decisions and EU AI Act provisions: European Commission and the EU AI Act text
Independent testing and reporting, treated as a visible sample:
- FP8, INT4, and 2-bit memory figures: independent GPU-hosting and quantization write-ups
- Field reports on self-hosting and benchmark reproducibility: developer posts, treated as a visible sample
- Anthropic Fable 5 and Mythos 5 restriction: Anthropic’s launch page and reporting on the Bloomberg-obtained Commerce letter