How much is your data worth? — Part 1 Assume your AI logs get stolen. Prompts. Responses. Tool calls. PII. Backups. Snapshots. What should the attacker get? Ciphertext. Today we're rolling out Post-Quantum Encryption for every request log, for every OrcaRouter user. No enterprise tier. No opt-in. No extra charge. Security shouldn't be an upgrade. Built for a simple threat: Harvest now. Decrypt later. A backup stolen today may still exist years from now. So we're protecting it for that future too.

This isn't a roadmap slide. Open User Console → Logs. Request payloads are encrypted before they hit storage: AES-256-GCM → payloads ML-KEM-768 + X25519 → long-lived key protection The application fleet gets a public capture key. It can encrypt new logs. It can't use that key to decrypt your historical logs. A database credential should not be a historical prompt-decryption credential.

Today we’re announcing OrcaSAQ-2 27B High-fidelity mixed-precision Qwen3.8 for long-horizon agents. 55.59 → 12.06 GB — 78.3% smaller / 4.61× 3.21 bpw · 93.2% Top-1 agreement 70.0 SWE-bench Verified 58.4 Terminal-Bench 2.1 262K context A 27B model for coding, terminal, browser, security and multi-tool agents — in a footprint you can actually deploy. SOTA agentic capability density among similarly sized models we evaluated. huggingface.co/orcarouter/Or…

The result that surprised us most: 58.4% on Terminal-Bench 2.1. Claude Sonnet 4.6 + Claude Code is reported at 58.5%. A ~12 GB 27B model lands within 0.1 point on this long-horizon benchmark. Different agent scaffolds, so not an apples-to-apples model comparison. But that’s a lot of capability inside 12 GB.

AI security has plenty of benchmarks. What it doesn’t have is enough ground truth. So we built the Orca AI Incident Archive — an open dataset of real-world AI security incidents. 340 records. 548 sources. 45 critical. 126 with confirmed real-world harm. Prompt injection. Agent hijacking. MCP/tool abuse. Credential theft. Supply-chain attacks. Sandbox escapes. AI-assisted intrusion. The important part: we separate capability from consequence. A jailbreak ≠ an exploit. An exploit ≠ an incident. A paper ≠ a victim. Every record tracks provenance, incident type, severity, AI involvement, real-world harm, and supporting evidence. No source → no entry. Conflicting evidence → marked disputed. New evidence → record updated. As agents gain browsers, shells, credentials, code execution and production access, security needs more than benchmarks of what models might do. It needs telemetry of what actually happened. Benchmarks measure capability. Incidents measure reality. The Orca AI Incident Archive is now open ↓ orcarouter.ai/incident-archi…

We spent the last few days testing JEV internally. We tried to reproduce it, break it, and improve it. 5 things we learned: 1. JEV’s core insight is simple - and probably right. If the answer space is bounded, don’t generate the answer token by token. Remove autoregressive decoding and you can remove 1–2 orders of magnitude of inference work. 2. RLCD isn’t the moat. Data might be. Laya already open-sourced the implementation + weights. The missing piece is the synthetic data recipe. And our experiments strongly point in the same direction. 3. “Open source already beat JEV” is a benchmark illusion. Same checkpoint: In-distribution: 0.769 OOD: 0.541 Change the distribution and the apparent breakthrough largely disappears. 4. Compute-optimal ≠ learnability-optimal. We moved state outside the problem sequence to save compute. Result: -27 points. Likely because we saved FLOPs while throwing away useful MLM pretraining priors. Then we tested 6 more ideas in one night: anchor selection, continuity smoothing, asymmetric windows, bucketed temperature, two-stage retrieval, full RLCD. All failed or failed to generalize. Only one thing consistently worked: More data. 1,200 → 123,475 examples OOD: 0.4069 → 0.5498 5. The weirdest result: A decoder with zero additional training still beat every trained small encoder: 0.5671 vs 0.5628 / 0.5411 / 0.4069 Our takeaway: JEV’s breakthrough may not be a particular architecture or training algorithm. It may be a much simpler idea: When the answer space is bounded, search it. Don’t generate it. And right now, the biggest bottleneck to making that work broadly doesn’t look like architecture. It looks like data.