Glaze by Raycast

Glaze is Raycast's attempt to turn natural-language descriptions into real desktop applications. Instead of generating a website or hosted web app, Glaze creates an app that lives on the user's Mac, can run offline after it is built, and can integrate with operating-system capabilities such as the filesystem, keyboard shortcuts, the menu bar and background processes.¹²

Raycast introduced Glaze in private beta in March 2026 and opened it to everyone on July 1. That timing matters: this review is evaluating a public product that has existed for less than two months, not a mature developer platform with years of independent reliability data.²

The core proposition is simple. Describe a personal utility, internal tool or workflow app in chat; Glaze's coding agent creates it; iterate conversationally; then run the resulting application locally. Apps can also be published to a public store or shared privately with a team.¹²

This is an AiToolMap desk review. We have not built or installed a Glaze application ourselves and do not imply that we did.

Raycast emphasizes that Glaze apps live on the user's computer, launch like desktop software and can work without a server or internet connection.¹ That is a material distinction from a generated web frontend.

A desktop app can respond to keyboard shortcuts, appear in the menu bar, work with files and continue background work. Those are exactly the capabilities that make small personal utilities useful.

MacGeneration's early analysis adds an important technical nuance. It notes that “desktop app” should not automatically be read as “pure Swift/SwiftUI native code”: the visible generation flow writes TypeScript and uses a managed application runtime rather than simply producing a conventional hand-written native Swift project.⁴ That does not erase the product advantage—Glaze still produces installable local desktop applications—but it makes the implementation claim more precise.

This distinction matters for buyers. The useful promise is local desktop integration, not ideological purity about programming language.

One concern with AI app builders is whether the generated result becomes trapped inside the vendor's editor.

The independent `glaze-coder` project shows that Glaze applications are ordinary projects stored on disk and can be edited and built with outside coding agents such as Claude Code, Codex, Gemini or other tooling. The project's purpose is specifically to continue development without consuming Glaze credits and then publish back to the Glaze Store.⁵

This is not an official Raycast project and should not be read as a vendor guarantee. It is nevertheless strong practical evidence that the generated source is accessible enough for third-party tooling to take over.

That materially improves Glaze's value proposition for technical users. A non-programmer can start conversationally; a developer can inspect or continue the generated source if the project becomes important.

AI coding is expensive because each iteration consumes model inference. Glaze packages that cost into credits rather than exposing raw API tokens.

The product's pre-public pricing page described a free tier with daily credits, paid access starting at $20/month and purchasable top-ups.⁶ Current independent July sources continue to report a $20 individual plan and warn that iterative app building can consume the included credit allowance quickly.⁷

The practical issue is not simply whether $20 is expensive. It is whether a user can predict how many useful build/repair cycles a credit bundle buys.

Vibe coding is iterative by nature. A first draft rarely ends the job. If debugging and polishing consume credits every time the agent touches the project, effective project cost can differ substantially between a simple timer and a complicated internal tool.

The `glaze-coder` community project is interesting partly because it exists to route later development through a user's own Claude or other coding subscription instead of Glaze credits.⁵ That is evidence that credit economics matter to power users even at this early stage.

Glaze's local execution means user data does not inherently need to live on a hosted application server. Raycast's product page explicitly frames local execution as a privacy and capability advantage.¹

But local-first does not mean risk-free. The generated app can potentially access the filesystem, network and OS capabilities the user grants it.

Raycast's broader security architecture offers some useful context. Raycast itself is code-signed and notarized, stores sensitive values in local encrypted storage/Keychain, and prompts for macOS permissions where the operating system requires them.³

Raycast's extension security documentation also acknowledges an important limitation: its extension runtime is not fully sandboxed for ordinary file I/O and networking. Extensions run in isolated JavaScript workers, but the Node runtime can still access capabilities allowed by the OS and extension design.³

A Glaze-generated app is not identical to a Raycast Store extension, so those exact controls should not be mechanically transferred. The broader lesson is the relevant one: local automation software needs explicit permission design, reviewability and update controls because it can interact with real user files and services.

For Glaze, this deserves extra weight precisely because generation makes software creation easier. More people can create apps without fully understanding the security implications of every dependency or permission.

Very little.

The fixed AiToolMap panel produced zero current exact-product results. That means there is no meaningful G2/Capterra population, no established enterprise-review corpus, no current mainstream testing from the standard consumer-tech panel and no benchmark that measures “quality of a Glaze-generated app.”

Beyond the panel, several July reviews describe the product positively and confirm the core local-app proposition. TeqVolt highlights native/local output, Mac-only support and credit economics as the main caveats.⁷ Other small specialist reviews make similar claims, but their scale and editorial track record are not strong enough to substitute for mainstream independent evidence.

MacGeneration is more useful because it scrutinizes implementation details rather than repeating the product pitch. It confirms the vibe-coding workflow while correcting simplistic “native Swift app” assumptions.⁴

The absence of stronger evidence should reduce rating confidence, not automatically reduce the product's qualitative potential.

Glaze makes the most sense for Mac users who repeatedly encounter small workflow problems that are too specific to justify buying or commissioning conventional software.

It is particularly attractive for people who can describe what they need but do not want to start from an IDE. Technical users may also like it as a fast bootstrap tool because the generated project can remain editable.

It is a weaker fit for production-critical software where formal testing, dependency review, cross-platform support and predictable long-term maintenance matter more than speed of creation.

Teams considering internal Glaze apps should treat generated code like other internal software: review permissions, secrets, network calls and dependencies before distributing it broadly.