Native macOS · Open Source · Developer ToolingOpen source

OpenRouter Menu

A native menu bar utility that makes OpenRouter account health and model activity visible without opening a dashboard.

OpenRouter Menu overview showing account balance, spend and recent usage in a native macOS panel.
The overview prioritises the account signals that are useful during day-to-day model work.

A repeated check should not require a dashboard.

OpenRouter makes a broad model catalogue available through one account, but checking balance, spend and recent model activity usually means returning to a browser dashboard.

For frequent use, the useful question is smaller: is the account healthy, what has been used recently and does anything need attention?

The problem

The dashboard contained more information than was needed for a quick account check, adding friction to a repeated task.

A menu bar utility still had to protect API credentials and explain account data without creating false precision.

The useful signals were few and recurring.

01

Direct OpenRouter use showed that balance, spend, model mix and recent activity were the recurring signals worth surfacing.

02

The macOS menu bar provided an appropriate home for short, glanceable checks without creating another persistent window.

03

The public repository makes the implementation and current product status independently inspectable.

A glanceable utility could stay separate from account management.

A compact native surface could make account monitoring faster while leaving detailed investigation in OpenRouter itself.

Clear grouping and restrained visual hierarchy would make model activity understandable at a glance.

Security and menu bar scale kept the product small.

  • Credentials needed to remain in the macOS Keychain rather than application preferences or logs.
  • The utility had to stay useful at menu bar scale instead of reproducing the full web dashboard.
  • Account data needed honest labels and safe empty, loading and error states.

The utility exposes account health without reproducing OpenRouter.

Every decision protects the narrow account-check job rather than expanding into a general dashboard.

01

Keep the product glanceable

The overview concentrates on balance, spend and recent activity instead of mirroring every dashboard control.

02

Use the native platform

A macOS menu bar app keeps the account check close to the work without adding another browser tab.

03

Separate overview from detail

Model and activity views add depth only when it is needed, preserving a quiet default state.

04

Make the implementation inspectable

Publishing the repository keeps the utility's scope, security choices and current status transparent.

Account, model and cost signals stay legible.

Recent account activity

A dedicated activity view turns raw usage records into a compact chronological account of model calls.

OpenRouter Menu activity view showing recent model usage in a native macOS panel.
Recent activity remains available without overwhelming the account overview.

Model mix made legible

The models view groups usage into a form that is easier to compare than a raw request log.

OpenRouter Menu models view summarising recent model usage.
Model usage is presented as supporting context rather than a vanity dashboard.

Why it remains intentionally small.

Open-source macOS utility

The working application and its source are available publicly on GitHub.

Faster account check

Balance, spend, model mix and recent activity are brought into one native, glanceable workflow.

Deliberately bounded scope

The product supports everyday monitoring while sending deeper account management back to OpenRouter.

How the utility stayed bounded.

  • The first useful slice focused on the account overview rather than broad dashboard parity.
  • Activity and model views were added as supporting layers once the glanceable hierarchy was clear.
  • The public repository remains the source of truth for the utility's current implementation and availability.

What the implementation demonstrates.

  • Product restraint applied to a small repeated workflow.
  • Hands-on native development across data, security and interface states.
  • Open-source delivery that makes technical capability inspectable.