Monospace Font

[AllDaGearNoIdea]

I believe the intention is to have specific fonts for brand identity.

Satoshi is already the main font, and I think it looks good. As an aside, I don't think it's the default priority on macOS. There should probably be a user option for Default (Satoshi) or Native (SF) where the fallback chain's top option flips.

JetBrains Mono (Regular + Medium) is the monospace font in the project. Are there any examples of where that is currently being used?

After doing some work on an extension that'd benefit from monospace, I found it difficult to read. After trying different opensource options, I found Commit Mono more legible, which is what I'd want from this kind of font. I use a similar (but not the same) font in my Terminals and IDEs after using A/B tools like Coding Font.

To me CM feels more like a font that'd be seen in a user-facing app. I can imagine JBM working well for programmers.

I know this is purely subjective, hence I'm kicking off a discussion about it. But if JBM isn't being particularly employed at this stage, nor consciously included, how would people feel about swapping the embedded mono default?

If people don't agree and are really attached to the existing, that's fine, and I can just embed my preferred within the extension, but this would start feeling wasteful going forward if a shared alternative is on the table, so thought now was the right time to ask.

Here's some mockups to show the difference. Note that in reality, I'm not using monospace for all of these elements, but thought applying the would help magnify differences.

JetBrains Mono

Commit Mono

[Xoshbin]

Thanks for opening this discussion and for the mockups, it helped me a lot to see the difference side by side.

Also, before anything else — i really like the idea of the extension you are building. The AI Meter one in your screenshots look very useful, i would use it myself every day.

Before i answer about the font, i checked the git history and i found one funny thing 🙂

The macOS rule that skip Satoshi is actually yours. It came in PR #262 (style/raycast-polish-pass), commit 04e359af, 2026-04-26:

/* macOS: use San Francisco system font (skip Satoshi). Other platforms
   keep the Satoshi-first stack defined in :root above. */
html[data-platform='macos'] {
  --font-ui: -apple-system, BlinkMacSystemFont, system-ui, 'Helvetica Neue', sans-serif;
}

Before that commit there was no macOS font override, so Satoshi was active everywhere. I am not saying this in bad way at all — i think your reason was correct at that time (make it feel native like Raycast), and i reviewed and merged it myself, so it is on me too. I just mention it so we both know where it come from.

It means on macOS Satoshi is never shown, but we still ship the file (85 KB) in every macOS build. So your idea of a user option (Default / Native) make sense to me, but please open it as separate issue, so this one stay only about monospace.

About JetBrains Mono

Small correction: it is used, and used a lot. I counted more than 50 places in 39 files. Some examples:

• Clipboard History preview
• Agent chat messages and code blocks
• Snippets code
• Calculator big result number
• The ⌘ K key chips in bottom bar
• Permission lists, MCP activity, shortcuts, file search, runs

So it is not a dead font. It is our secondary font for code and code-like text.

Why i choosed it: honestly the reason is personal. JetBrains Mono is easier for me to read for long time, same for Satoshi. That was my main reason, not a design reason.

But i don't think my personal comfort should force the app to have bad design. You are much better than me in UI and design, i am not good in this area, so i agree with you in any way you decide. If Commit Mono is better for a user facing app, let's take it. I already checked the license, it is SIL Open Font License 1.1, free to bundle in the app, so no problem there.

The bigger problem (this is the most important part for me)

The real issue is not which mono font we use. The real issue is how we apply typography in the app.

We do have a rule, i checked:

• docs/reference/design-system/tokens.md has the same font table for extension authors

But the rule for mono is only one line: "Code, monospaced content". It never say if IDs, file paths, keyboard keys, numbers, timers or labels count as "code". This is why in your own mockups mono is used for labels like "5h Limit" and "Weekly Limit" — the rule simply don't answer that question.

And the bigger problem is we apply mono in three different ways:

.text-mono                       18  ← the documented way
font-family: var(--font-mono)    40  ← raw, bypass the design system
tailwind font-mono class          8  ← third way
                                ───
                                 66  across 39 files

So only 18 of 66 (27%) follow the documented class. The rest bypass it. That is the real reason the app feel inconsistent, not the font itself.

So what i really want from this discussion is bigger than a font swap:

1. Make the mono rule concrete — say exactly what is mono (code, paths, IDs, keyboard keys?) and what is not (labels, titles, descriptions, buttons?)
2. We need to Pick one mechanism, killing the other two, so mono is applied the same way everywhere
3. Going through the 39 files and fix the wrong usage
4. Checking sizes and weights too, not only families
5. Then decide the final mono font, with the rules already in place

If we only swap the font now, the app still stay inconsistent, just with a nicer font.

Two technical notes if you make a PR

1. The font is declared in two places, not one:

   • asyar-launcher/src/resources/styles/style.css (main window)
   • asyar-launcher/src/lib/themeFonts.ts (base64 injected into extension iframes)

   If you only change one, extensions will still show the old font.

2. --font-ui and --font-mono are already themeable (themeVariables.ts), and a theme extension can ship its own font files (themeService.ts). So a third option exist that nobody mentioned: ship Commit Mono as a theme instead of changing the default. I don't prefer this one, i think the default should be good by itself, but i wanted to tell you it is possible.

My answer

Yes from me. Please go ahead. But if you have time, i would be very happy if you take the typography part too, not only the font swap. You are the right person for this.

Thank you 🙏

[Xoshbin]

Hey @AllDaGearNoIdea Quick update before you start a PR (if any planned) — I merged a design-language pass that changes the ground this sits on, but does not answer the mono question.
Being clear about which is which so you don't duplicate work.

What landed: the design language is now a set of lookup tables (.agents/skills/design-language/SKILL.md), and the mechanical half is enforced by pnpm check:design in CI — undefined tokens, var() fallbacks, hardcoded colours, raw pixels on scaled properties, bare z-index. Every font-size in the app is now a scale token, so your ask # 4 is largely done for sizes.

What did NOT change: the three-way split. I re-counted against the previous commit:

	before	after
.text-mono	18	18
raw font-family: var(--font-mono)	50	49
Tailwind font-mono	8	8

Still ~24% through the documented class. Your asks # 2, # 3 and # 5 are completely open.

But I found the reason, and it changes the order of work.

.text-mono sets family and --font-size-sm (12px). Of the 48 raw font-family: var(--font-mono) blocks:

• 26 need a different size (15 at xs, 5 at 2xs, 3 at md, one each at lg / display / 0.9em)
• 13 set no size and inherit from their parent
• only 9 are already at 12px

So more than half the app physically cannot use .text-mono without a visual change. The class is the bug.

That means the sequence should be:

1. Split .text-mono into family-only, with size stated separately — then the class is usable everywhere
2. Write the concrete rule (what is mono, what is not)
3. Migrate the 48 + 8 to the one mechanism
4. Add a check:design rule so raw font-family: var(--font-mono) fails CI the enforcement hook already exists, it just needs the rule
5. Then swap the font, which becomes a one-line change

Step 4 is what stops this coming back in six months.

Correction to my technical notes above: the font name is in three places, not two. I missed one:

• asyar-launcher/src/resources/styles/style.css (main window)
• asyar-launcher/src/lib/themeFonts.ts (base64 into extension iframes)
• asyar-sdk/src/styles/tokens.css (the static fallback extension authors import at dev time)

Still a yes from me on Commit Mono. If you want to split it — typography consolidation first, font swap second — I am happy to review them as two PRs.

Please let me know if you want to work on it, or assign it to myself.

[Xoshbin]

Hey @AllDaGearNoIdea another update is, with claude I have made a design language that I think may cover most of the problems Asyar have regarding ui/ux design. The pr is in #603 it may need a review from your side too. I mostly like it, as the new design language standardizes the spacing and sizes and colors and typography which I like it myself. but as said it may need a review, so please whenever you had time take a look at it.
You may find the design-language.md file useful while reviewing the pr as it holds the guidelines.
And the last commit of the pr is reverting to the original colors used, so you may checkout into it to see the difference between the last commit colors (original colors) and it's previous commit (new colors) that uses a different set of colors.
The pr may not answer your proposal completely, but with your review and your addition we may have a design language specific to Asyar that is used as a guideline.