---
title: "Comment by Yunus Emre Vurgun on \"Jira Local LLM Integration: LM Studio per Project\" | Hashnode"
description: "Really appreciated that you deliberately broke the token to show the FAIL-OPEN row instead of only showing the happy path. For a privacy check like the HR examp"
url: "https://hashnode.com/posts/jira-local-llm-integration-lm-studio-per-project/6acf6079f93371d7c79c5e02/comment/6ad3afc8b7520de4c43aac6a"
---

[Discussion](https://hashnode.com/posts/jira-local-llm-integration-lm-studio-per-project/6acf6079f93371d7c79c5e02)

Comment [Jira Local LLM Integration: LM Studio per Project](https://hashnode.com/posts/jira-local-llm-integration-lm-studio-per-project/6acf6079f93371d7c79c5e02)

[Yunus Emre Vurgun](https://hashnode.com/@yunusemrevurgun)

[Oct 17](https://hashnode.com/posts/jira-local-llm-integration-lm-studio-per-project/6acf6079f93371d7c79c5e02/comment/6ad3afc8b7520de4c43aac6a)

Really appreciated that you deliberately broke the token to show the FAIL-OPEN row instead of only showing the happy path. For a privacy check like the HR example, fail-open means a Mac Studio reboot quietly lets sensitive requests through, so I'd be tempted to make that one project fail-closed and just block Send for Review with a clear message. How has the 35B-A3B MoE been on latency for the validator step? Keeping the model pinned in memory (no idle unload in LM Studio) seemed to matter a lot for first-request times in my experience.

[Mihai\_LeanZero](https://hashnode.com/@mihaileanzero)

[Oct 17](https://hashnode.com/posts/jira-local-llm-integration-lm-studio-per-project/6acf6079f93371d7c79c5e02/comment/6ad3afc8b7520de4c43aac6a#reply-6ad3b5b9075e8f48e3d4911d)

Agreed on the HR project. 1.34.0 has an opt-in switch for part of that, under Slow self-hosted providers in Settings: with it on the move is refused with a "check is still running" message instead of going through. I haven't tested it, and it only covers a slow model. I didn't find anything for a plain error like a wrong token, that still fails open.

On latency, the model's own answers took 0.6 to 0.8 s at about 100 to 110 tok/s, and Send for Review took roughly 2.3 to 3.4 s end to end, apart from one 6.4 s first refusal I couldn't explain. I only ran that one model, so no MoE vs dense comparison.

Pinning I didn't test. All I have is 2.8 s for the first call of my session and 12 s on an idle model in our video run. Your guess that it matters is plausible, and 12 s against a 20 s validator limit is close enough to be worth checking.