Aikido Altar is the first open-weight security model from Aikido, released on September 21 and built for one specific job: bringing frontier-grade defensive security into infrastructure you control. The model powers Aikido Machine, the company’s autonomous pentesting appliance that runs entirely inside a customer’s environment, including fully air-gapped networks. For organizations that cannot send source code, architecture documentation or unremediated findings to a third-party inference service, Altar offers capable security AI without that data ever leaving the building.

The deployment gap between frontier and open-weight models

Closed frontier models run on somebody else’s infrastructure. Every request you send them carries your context with it. For a bank under a data-residency mandate, a hospital group bound by strict data-processing rules or an industrial operator whose OT environment has no route to the internet at all, that trade-off is off the table.

Open-weight models solve the jurisdiction problem, but they create a hardware problem. GLM-5.3, the Z.AI model Aikido chose as Altar’s parent and one of the strongest performers in its security evaluations, occupies 1.51 TB at full precision. Serving it requires hundreds of gigabytes of unified memory, and inference slows down quickly once you serve parallel conversations with large context windows.

Much of that weight comes from the architecture. Models like GLM-5.3 use a mixture-of-experts design: they consist of many small specialized neural networks, each called an expert. Only a handful of experts activate for each token, yet the entire pool has to be stored and served. You pay the full memory cost whether or not the capacity is relevant to your workload. Security work such as reviewing code for vulnerabilities, proposing patches or running a penetration test only calls on a small slice of that pool.

Agents raise the stakes further. Each agent keeps a running record of everything it has seen and done, and that record lives in GPU memory next to the model itself. The longer an investigation runs, the more it grows, and every parallel investigation multiplies the demand. Model and context draw from the same fixed pool of memory, so every gigabyte saved on the model frees room for the work happening alongside it.

How quantization and expert pruning shrank GLM-5.3

Aikido combined two compression techniques. Quantization stores the model’s learned numerical weights with fewer bits, trading some precision for a smaller footprint. The starting checkpoint used AWQ to store most expert weights in four bits instead of sixteen, with activations staying at 16-bit precision, a setup known as W4A16. That step alone brought the model down to 488 GB.

Expert pruning goes further by deleting entire expert weight blocks, so each token chooses among the experts that remain. The removal itself is mechanical. Deciding which experts to remove is the hard part, and the losses can be uneven. A pruned model might keep strong coding performance while losing much of its ability to understand a particular natural language, leaving it unable to interpret documentation or business rules written in that language.

To guide the selection, Aikido used traces from its own pentesting harness running internal benchmarks. These traces capture the code, tool calls and responses agents work through during a full pentest, providing representative inputs for expert selection without any customer data. Multilingual text was added on top, because investigating an application means understanding its features and workflows even when the documentation is written in French, Dutch or another language.

The pruning method is REAP, Router-weighted Expert Activation Pruning, developed by Cerebras. Rather than counting how often an expert gets selected, REAP estimates its contribution using both the router’s weighting and the magnitude of the expert’s output. Aikido paired it with a domain-preserving aggregation strategy, examining contributions across different groups of examples so that a capability that matters to a less common workload survives the overall average. Security, coding and language skills are distributed across experts, and there is no cleanly labeled set of “cyber experts” to keep. In Aikido’s supporting compression study, models retaining the same number of experts differed substantially in how closely their outputs tracked the reference model. Size alone did not determine what survived.

From 1.51 TB to 328 GB

The combined result is a 78.2% reduction compared with GLM-5.3 at full precision and a 32.8% reduction compared with the already-quantized AWQ checkpoint. Altar keeps 168 of the original 256 routed experts in each backbone expert layer, removing 88, or 34.4%. The router still selects eight experts per token, now from a smaller bank. Pruning stripped out another 160 GB after quantization had done its part, landing the final model at 328 GB.

How much security capability survived compression

Aikido evaluated Altar on its internal CVE benchmark, which tests a model’s ability to identify complex real-world vulnerabilities through the company’s AI Code Analysis harness. The benchmark covers 32 known vulnerabilities across 30 repositories, with three runs per case.

  • Altar averaged 60.4% recall per run and rediscovered 23 of the 32 vulnerabilities at least once across three runs.
  • The quantized GLM-5.3 AWQ parent averaged 61.5% recall and covered the same 23 vulnerabilities.
  • The original full-precision GLM-5.3 averaged 65.6% recall and covered 25 of 32.

In practical terms, cutting the quantized checkpoint by 32.8% cost roughly one percentage point of average recall while preserving all of its vulnerability coverage. Against the full-precision parent, Altar retained 23 of the 25 covered vulnerabilities, 92%, at 33% less storage. Aikido reports average recall and coverage separately because finding a vulnerability once differs from finding it consistently.

The early field signal adds some weight to the numbers. Shortly after Altar was deployed across the Aikido Machine fleet, it identified a valid critical-severity vulnerability during a client production pentest.

What the benchmark does not prove

The results deserve honest framing. The benchmark measures targeted rediscovery of known CVEs inside a pipeline where other models handle the surrounding stages. It says nothing about blind discovery across an entire codebase, about executing exploits to validate findings, or about the quality of the fixes proposed afterwards. The evidence so far comes from a single internal benchmark, so independent replication will matter before you treat the recall figures as settled.

The real question for your team is practical: can a smaller model on your own hardware produce findings reliable enough to justify the operational burden of hosting it? That answer will differ per organization, and it depends as much on your serving stack as on the model itself.

Running Altar on your own infrastructure

Altar’s weights are publicly available under Aikido’s organization, together with a model card, license, serving flags and deployment instructions. Aikido states the model serves comfortably on a node with four H200 GPUs running the latest version of vLLM. That is serious hardware, yet it is a realistic footprint for organizations that already operate GPU clusters, and it fits inside environments where an external API call is a non-starter.

The model is already expanding across Aikido’s product line, including Aikido Attack for AI pentesting, Code Security Audit and Deep PR Review. Credit for the underlying work goes to Z.AI for GLM-5.3, Cerebras for REAP, cyanwiki for the quantized model and 0xSero for the compression work. Aikido has also published a fidelity study, keep plans and a pruning toolkit for teams that want the technical detail.

What comes next for Altar

Compression work continues with lower-bit formats such as EXL3, which could allow more experts to be retained, alongside further H200 serving optimizations. The larger shift is from compression to training: fine-tuning models for security workflows, improving tool use and long-horizon reasoning, and building a self-learning pipeline informed by internal benchmarks. That work spans vulnerability research, code analysis, remediation and other defensive security workflows.