release(provider): v0.6.30 — roll back Gemma4 compiled decode (revert to 0.6.28 engine)

[Gajesh2007]

Incident rollback

v0.6.29's compiled-decode engine (mlx-swift-lm 5d0a084: compile() graph trace + bf16 weight conversion) has a heavy cold start. During the 00:00 UTC surge the fleet-wide v0.6.29 rollover cold-started into peak load — the ~26 GB Gemma model couldn't load + convert + compile within the TTFT deadline, so Gemma dropped to ~2% success (503 provider_error / 504 first_chunk_timeout), an effective outage. gpt-oss survived (smaller, warms fast).

Change

• Revert libs/mlx-swift-lm 5d0a084 → e5d0a94 (v0.6.28's known-good engine — no compiled decode, no bf16 conversion, no cold-start penalty).
• Bump ProviderCore.version + coordinator LatestProviderVersion 0.6.29 → 0.6.30 so the fleet auto-updates forward out of the broken 0.6.29.
• Kept perf(provider): precompute DH shared key — 75x faster per-chunk encryption #483 (DH-key chunk-encryption precompute) — unrelated to the breakage, proven safe since 0.6.29.

v0.6.30 = 0.6.28 decode engine + version bump (+ #483).

Before / After

flowchart LR
  subgraph "v0.6.29 (broken)"
    A1[Gemma req] --> B1[cold box: load 26GB + bf16 + compile] --> C1[TTFT deadline blown -> 503/504] --> D1[~2% success]
  end
  subgraph "v0.6.30 (rollback)"
    A2[Gemma req] --> B2[0.6.28 engine: load 26GB, no compile] --> C2[first token in ~1.8s] --> D2[serves normally]
  end

Loading

Follow-up

Compiled decode returns only after DAR-378 (pre-warm / pre-compile at load, off the request critical path) so the cold-start cost is amortized during load, not paid on a live deadline-bound request.

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
d-inference	Building	Preview	Jul 1, 2026 12:48am
d-inference-console-ui-dev	Building	Preview	Jul 1, 2026 12:48am
d-inference-landing	Ready	Preview	Jul 1, 2026 12:48am

[ethenotethan]

Automated Code Review — Layr-Labs/d-inference#

Verdict: COMMENT

Security — ⚠️ SKIPPED

Error: OpenRouter HTTP 402: {"error":{"message":"Insufficient credits. Add more using https://openrouter.ai/settings/credits","code":402}}

Performance — ⚠️ SKIPPED

Error: OpenRouter HTTP 402: {"error":{"message":"Insufficient credits. Add more using https://openrouter.ai/settings/credits","code":402}}

Type_diligence — ⚠️ SKIPPED

Error: OpenRouter HTTP 402: {"error":{"message":"Insufficient credits. Add more using https://openrouter.ai/settings/credits","code":402}}

Additive_complexity — ⚠️ SKIPPED

Error: OpenRouter HTTP 402: {"error":{"message":"Insufficient credits. Add more using https://openrouter.ai/settings/credits","code":402}}

✅ All four passes clean. No issues found.

🤖 Automated review by Centaur · DAR-186

[github-actions]

No files in this PR match any affected_files pattern in the threat model, but two of the three changed paths warrant brief inspection before closing this review.

---

Trust boundaries touched

None formally. The changes sit adjacent to TB-001, TB-002, and TB-007 but are not currently mapped.

---

Per-file assessment

coordinator/api/server.go
This file is the route-registration and middleware-chain entrypoint for the entire coordinator API. It is directly adjacent to TB-001 (consumer→coordinator) and TB-002 (coordinator→provider WebSocket) and is referenced by name in the threat model narrative for requireAuth, rateLimitConsumer, and the WebSocket upgrade path — yet it is not listed as an affected_files entry under any threat.

Action required: This file should be added to the affected_files lists for at minimum T-001, T-004, T-006, T-021, and T-024. If this PR registers new routes, re-orders middleware, or changes the WebSocket upgrade logic, a security reviewer must manually confirm that:

• Every new route passes through requireAuth (or an explicit exemption is documented).
• No admin/release endpoint is accidentally reachable via the consumer key path.
• The WebSocket upgrade still applies the 10 MB per-message cap.

libs/mlx-swift-lm (submodule bump or library change)
This is the in-process MLX inference engine sitting squarely inside TB-007. Changes here affect A-001 (consumer prompts in GPU memory) and the cancellation/residual-data risks called out in T-028 and T-010. The library is not currently listed under any threat's affected_files.

Action required: Add libs/mlx-swift-lm to T-028, T-010, and T-029. For this specific PR, confirm whether the bump changes buffer allocation/reuse semantics (residual GPU data risk), the cancellation API surface, or tokenizer input handling (prompt injection / oversized input risk). If the diff is non-trivial, request a dedicated review of the MLX-side changes.

provider-swift/Sources/ProviderCore/ProviderCore.swift
This is likely the top-level coordinator for the Swift provider process — initialization order matters here because PT_DENY_ATTACH (T-014), SIP check (T-015), binary hashing (T-013), and SE key load (T-033/T-034) all run at startup. It is not listed under any threat.

Action required: Add this file to T-013, T-014, T-015, and T-033. For this PR, verify that no security-critical startup step (anti-debug, SIP assert, binary hash, persistent SE key load) has been deferred, made conditional, or moved after any code that touches network or disk.

---

New threat-model surface introduced

None confirmed from file paths alone, but the gap is real: coordinator/api/server.go is effectively the single chokepoint for every trust boundary in the coordinator and the omission from affected_files means automated coverage is blind to route-level regressions there. Recommend opening a threat-model maintenance ticket to add it.

---

SEC-* findings resolved

None — this PR makes no changes to files currently mapped to open findings.

---

🔐 Threat model: docs/threat-model.yaml · Updates on each push to this PR