mirai 0.4.6 (new cask)

[alexxale]

---

After making any changes to a cask, existing or new, verify:

• The submission is for a stable version or documented exception.
• brew audit --cask --online <cask> is error-free.
• brew style --fix <cask> reports no offenses.

Additionally, if adding a new cask:

• Named the cask according to the token reference.
• Checked the cask was not already refused (add your cask's name to the end of the search field).
• brew audit --cask --new <cask> worked successfully.
• HOMEBREW_NO_INSTALL_FROM_API=1 brew install --cask <cask> worked successfully.
• brew uninstall --cask <cask> worked successfully.

---

• AI was used to generate or assist with generating this PR. Please specify below how you used AI to help you, and what steps you have taken to manually verify the changes, including zap stanza paths.

---

[bevanjkay]

Do you have any insight into why the repository name is uzu, but the rest of the branding is Mirai?

[alexxale]

Do you have any insight into why the repository name is uzu, but the rest of the branding is Mirai?

Hi @bevanjkay! Thank you for the review. Mirai is the company name. We have a bunch of products, like an inference engine and a model conversion toolkit, but for end-user products, we prefer to use the company name for branding reasons.

Regarding the other suggestions, what’s the proper way to handle them, should I make a separate commit, or open a new PR?

[SMillerDev]

but for end-user products, we prefer to use the company name for branding reasons.

What if you need to add one of the other projects to brew? I think this should be called mirai-uzu in this case.

[bevanjkay]

Regarding the other suggestions, what’s the proper way to handle them, should I make a separate commit, or open a new PR?

You can add commits to this PR. I also agree with the comment above about using a prefixed token like mirai-uzu.

[alexxale]

but for end-user products, we prefer to use the company name for branding reasons.

What if you need to add one of the other projects to brew? I think this should be called mirai-uzu in this case.

I actually think the "mirai-uzu" option is a bit misleading, since this cli itself doesn’t mention uzu anywhere.

For now, we’re going to have two user-facing products:

• mirai - cli tools for local model inference (this cask)
• mirai-chat - https://trymirai.com/chat-for-mac (we’ll submit this after a bit more polishing)

You can think of the uzu repo as a monorepo where, alongside the SDK, we also maintain a few user-facing products built on top of it. With each SDK release, those products are updated automatically as well.

[SMillerDev]

If people want to install what's in the repo called uzu, how will they know that nothing is called uzu and that they should search for the organization name instead?

[alexxale]

We will add an explicit brew install command to the README once it becomes available. In addition, the primary source for installation will not be GitHub, but the official website: https://trymirai.com

[SMillerDev]

We will add an explicit brew install command to the README once it becomes available.

From years of experience, that won't help. People will see the repo name and try and install it based on that. If you don't want something to be known under a certain name the best fix is not to name it that.

[alexxale]

@SMillerDev what do you think about combining both the CLI with Mirai branding and the Mirai macOS app into a single cask? The url would no longer point to GitHub release artifacts, but instead reference the installer from our S3 bucket. This way, the naming stays clear: people see the Mirai app on the website, install an app with the same name, and also get the CLI, which shows the Mirai logo when launched.

[bevanjkay]

If the app and the binary are served by the same url and installed in one go, then yes it does make sense to combine them into one cask.