MurphyA/hacker-news huggingface dataset:
Show HN: CC Usage Bar – Check Claude Code usage from your macOS menu bar
by root-cause | 2026-03-07 06:15:47+00:00
I built a small macOS menu bar app that lets you check your Claude Code subscription usage with a single click, without touching your terminal.

## The problem

If you use Claude Code heavily, you probably run multiple sessions across multiple terminal windows. When you want to check how much of your usage limit you've burned through, your only option is to type `/usage` inside a Claude Code session. That means either:

1. *Interrupting a running agent* mid-task to type a command, or
2. *Opening a new terminal and starting a new session* just to check a number

Both are disruptive. You lose flow, and the agent loses context.

## Why not just call the usage API?

A lot of community tools solve this by grabbing the OAuth token that Claude Code stores in the macOS Keychain and calling Anthropic's usage API directly. This works, but it has a real UX and security cost: *macOS will prompt you every time a third-party app tries to read that Keychain item.* You get a system dialog asking whether to allow access, sometimes repeatedly. It's not a smooth experience, and handing your OAuth token to another process is a legitimate security concern.

## How CC Usage Bar works differently

CC Usage Bar takes a simpler, zero-trust approach. It doesn't touch your Keychain, doesn't make any network calls itself, and doesn't parse or store any credentials. Instead, when you click the menu bar icon, it:

1. Spawns a real Claude Code session in a pseudo-terminal (PTY)
2. Sends the `/usage` command
3. Captures and renders the output with full ANSI color fidelity
4. Terminates the session immediately

It literally runs `claude` the same way you would, just in a hidden terminal. The data comes straight from Claude Code itself, so it's always accurate and reflects the latest state. No reverse engineering, no API scraping, no hacks.

## What it looks like

A single icon in your menu bar. Left-click to open a popover showing your current usage. Click outside to dismiss. That's it.

- Native Swift/SwiftUI app, runs as a lightweight menu bar agent (no Dock icon)
- macOS 14 Sonoma or later
- Requires Claude Code already installed and on your PATH

## Links

- GitHub: https://github.com/yilei-he/cc-usage-bar (MIT licensed)
- Download pre-built .app from the Releases page, or build from source with Xcode

Happy to hear feedback or ideas. If you've been annoyed by the same workflow interruption, give it a try.
by sdenton4 | 2026-03-07 06:17:08+00:00
Depending on how 'one-off' the query is, sequential read is the right answer. The alternative is indexing the data for ANN, which will generally require doing the equivalent of many queries across the dataset.

On the bright side, smart folks have already thought pretty hard about this. In my work, I ended up picking usearch for large-scale vector storage and ANN search. It's plenty fast and is happy working with vectors on disk - solutions which are /purely/ concerned with latency often don't include support for vectors on disk, which forces you into using a hell of a lot of RAM.

https://github.com/unum-cloud/USearch
by Animats | 2026-03-07 06:19:01+00:00
Clockmaking goes way back, but for a long time was off in its own technological niche. People with tiny files working brass made clocks by hand. The first mass produced clocks appeared in the late 1700s.

Precision didn't come to iron and steel until Maudsley's lathe, around 1800. It can be seen at the Science Museum, London. It looks like a modern lathe, but is quite different from its predecessors. It's on display, but not emphasized, and few people know its importance.

Today we think of engineering as a continuum, where you pull the technology you need from mechanics, electronics, materials science, and chemical engineering to get something done. That's a modern concept. For most of history, those groups barely talked.
For a long time, there was a huge distance between science and engineering. Science was sort of an aristocratic hobby, and engineering was done by people who worked in forges and shops. It wasn't until the era of the steam engine that both sides started talking much.
They had to figure out thermodynamics to get steam engines to work efficiently.
by XorNot | 2026-03-07 06:19:22+00:00
I will freely go on the record as saying that there's nothing wrong with exceptions for this exact reason: errors are so common that a function being "pure" is the exception, and that errors-as-value handling invariable turns into an endless chain of something like "if err; return (nil/zero, err)" in every language which tries it.

The same would apply to anytime you have Result types - ultimately its still just syntactic sugar over "if err then...".

What's far more common in real programs is that an error can occur somewhere where you do not have enough context to handle or resolve it, or you're unaware it can happen. In which case the concept of exceptions is much more valid: "if <bad thing here> what do I want to do?" usually only has a couple of places you care about the answer (i.e. "bad thing happened during business process, so start unwinding that process" and many more where the answer is either "crash" or "log it and move on to the next item".
by root-cause | 2026-03-07 06:20:01+00:00
Author here. I vibe-coded this entire app with Claude Code, which is also how I ran into the problem in the first place. When I'm deep in a coding session, I typically have 2-3 Claude Code instances running across different terminal windows — one working on a feature, another writing tests, maybe a third refactoring something. As you get into flow, you start burning through your usage quota fast, and the only way to check how much is left is to type `/usage` inside a session. That means either interrupting an agent that's mid-task (and losing its train of thought), or opening yet another terminal to start a fresh session just to see a number. I kept getting surprised by hitting the limit at the worst possible moment. So I built this to scratch my own itch — one click in the menu bar, see the usage, get back to work.
by lukaslalinsky | 2026-03-07 06:20:04+00:00
I'm much younger, just 42, but due to other medical problems, my attention span was being reduced. I've been programming profesionally for about 25 years, but the last years I was putting myself more into other roles, because being able to focus on code for a few hours uninterrupted is a luxury that I don't have anymore. I was honestly thinking I'll have to retire early. That was until I've tried Claude Code last year. It feels like a superpower. I can guide it, I can review it, I don't need it for thinking, I need it for writing code and under very strict guidance, it does that well. I feel like this extends the years I can do software well into to the future. In a way, I welcome masses thinking AI can produce software on it's own, it gives me hopes for more earning in the future for me.
by reflectt | 2026-03-07 06:20:44+00:00
The handoff visibility problem jlongo78 describes is the core issue. We ran into it building a 9-agent team and solved it differently: instead of modeling cross-agent dependencies as pod bindings at the infrastructure layer, we model them at the task layer.

When agent A completes a task, it posts to a shared task board and transitions state to 'validating'. Agent B polls for tasks in validating state that match its domain. The dependency is in the task state machine, not the agent infrastructure. Deadlocks become visible because the task sits in validating with no owner claim.

The tradeoff: this works when you can model your work as discrete tasks with clean state transitions. It breaks down for continuous / streaming work where tasks don't have clear completion signals.

We open-sourced this as reflectt-node (Apache 2.0). Complementary approach — AgentsMesh handles the infrastructure/session layer, reflectt-node handles the coordination protocol layer above it.
by Nevermark | 2026-03-07 06:21:21+00:00
> It is a shame that Twitter's algorithm is so damn easy to manipulate that it's basically owned by propaganda firms now.

Not "basically" owned. Manipulation is the explicitly optimized and financed purpose.

The feed is a two-directional manipulation competition, with both directions enhancing each other, with a conflict of interest afterburner, for all parties to maximally control users. Neutrality doesn't exist.

(1) An auction for ads/influence to get your manipulative content in front of the most likely vulnerable users.

(2) A never ending competition to create addictive content, funded in direct proportion to successful impact on users.

(3) And the value in both directions is magnified by the "personalized" leverage manufactured through pervasive logging, beyond service surveillance, dossier collation, psychology hacking and real time feed manipulation.

(4) None of this is impeded by any "standards", neutrality, or a concern about external damage.

Admittedly great things for users and society, except for the four on that list that are not.
by JKCalhoun | 2026-03-07 06:21:40+00:00
You're right, as I say, I no longer have skin in the game.

Retired, I have continued to code, and have used Claude to vibe code a number of projects—initially I dod so out of curiosity as to how good LLM are, and then to handle things like SwiftUI that I am hesitant to have to learn.

It's true then that I am not in a position of employment where I have to consider a performance review, pleasing my boss or impressing my coworkers. I don't doubt that would color my perception.

But speaking as someone who has used LLMs to code, while they impress me, again, I don't feel the threat. As others have pointed out in past threads here on HN, on blogs, LLMs feel like junior engineers. To be sure they have a lot of "facts" but they seem to lack… (thinking of a good word) insight? Foresight?

And this too is how I have felt as I was aging-out of my career and watched clever, junior engineers come on board. The newness, like Swift, was easy for them. (They no doubt have rushed headlong into Swift UI and have mastered it.) Never though did I feel threatened by them though.

The career itself, I have found, does in fact care little for "grey beards". I felt by age 50 I was being kind of… disregarded by the younger engineers. (It was too bad, I thought, because I had hoped that on my way out of the profession I might act more as mentor than coder. C'est la vie!)

But for all the new engineer's energy and eagerness, I was comfortable instead with my own sense of confidence and clarity that came from just having been around the block a few times.

Feel free to disregard my thoughts on LLMs and the degree to which they are threatening the industry. They may well be an existential threat. But, with junior engineers as also a kind of foil, I can only say that I still feel there is value in my experience and I don't disparage it.
by reflectt | 2026-03-07 06:22:57+00:00
The Symphony model is interesting — it pushes task management up to Linear, keeping agents focused on execution.

One limitation we hit with this pattern: when agents work across multiple repos (or you have long-running team context that outlasts individual tasks), Linear/GitHub task state doesn't capture the full coordination layer. Things like:

- Which agents are currently active (presence)
- Post-task reflections that surface team-wide patterns
- Human review queues between agent phases
- Activity feed that shows the team's full history

We ended up building reflectt-node as a lightweight REST API layer that sits above the execution orchestrator (whatever that is — Symphony, Stoneforge, your own setup). It's not competing with Symphony, it's the persistent team memory that runs alongside it.

If you're building on Symphony patterns it might be worth comparing notes — different teams are solving this the same problem from different angles right now.
by ipdashc | 2026-03-07 06:23:11+00:00
I'm not sure how you're getting that from their post? None of the four things mentioned (book publishing, web publishing, open-source software, computer hardware) involve stealing someone's property, he's saying that the ability to produce those things widened and the cost went down massively, so more people were able to gain access to them. Nobody stole your bike, but the bike patents expired and a bunch of bike factories popped up, so now everyone can get a cheap bike.
by ehnto | 2026-03-07 06:23:32+00:00
I think this could be the key difference in how people are experiencing the tools. Using Claude in industries full of proprietary code is a totally different experience to writing some React components, or framework code in C#, PHP or Java. It's shockingly good at the later, but as you get into proprietary frameworks or newer problem domains it feels like AI in 2023 again, even with the benefit of the agentic harnesses and context augments like memory etc.
by wvenable | 2026-03-07 06:25:56+00:00
I don't think it was clear at the time that UTF-8 would take off. UCS-2 and then UTF-16 was well established by 2000 in both Microsoft technologies and elsewhere (like Java). Linux, despite the existence of UTF-8, would still take years to get acceptable internationalization support. Developing good and secure internationalization is a hard problem -- it took a long time for everyone.

It's now 2026, everything always looks different in hindsight.
by reitzensteinm | 2026-03-07 06:27:47+00:00
It would have been a super reasonable reply to talk about the history of TypeScript, why fundamentally its types exist to retroactively describe complicated datastructures encountered in real world JavaScript. And why when TypeScript overstepped that by creating enums, which require code generation and not mere type erasure to compile, it was decided to be a mistake that they won't repeat.

But instead your rebuttal was pointing out that TypeScript can compile OP's example code, which OP presented as valid TypeScript that they disliked. I'm not defending their position, I'm just saying that it didn't appear you had even properly read their comment.
by ipdashc | 2026-03-07 06:29:55+00:00
Not all of us have cell plans with hotspots ($$$), hotspots often have data caps, cell is often slower or congested, and there are some areas without cell signal. It's also kind of silly from a wider perspective to shove everyone onto the cellular network when most businesses have perfectly decent fiber internet nowadays.

Sure, I'm usually on hotspot, but I personally appreciate when businesses have wifi. Either way, there are always going to be shared networks somewhere.
by Fire-Dragon-DoL | 2026-03-07 06:30:08+00:00
Wait, can you expand on the ammonia odor? Is it constant?

My sweat when I exercise very intensely, smells like ammonia. Probably since I was 18 (before I played waterpolo, so I can't tell).
Normally it does not, only with very intense exercise (zone 4 or 5).

Edit: a kagi search suggested this is normal
by ehnto | 2026-03-07 06:31:37+00:00
As the benefactor of an extremely rare disease, it's not exactly unfair when you look at it from a societal view. If you solve a higher probability problem, you are helping far more people.

The real tragedy isn't the allocation of the resources we have spare, it's that so many of our resources are not spare because billionares and corporations have hoarded it.

Without changing the percent of allocation, and only changing input resources by capturing it back from billionaires as taxes, we could be helping far more people including super rare diseases.
by didibus | 2026-03-07 06:31:51+00:00
> The people getting pushed out are the intermediates and seniors who aren't high performers.

It's almost impossossible to screen for "high performers" though. When interviewing, you just don't know who you are getting, short of like, they can solve your leetcode questions well, and they had good answers to pretty high-level "work experience" questions.

So I don't think this can be true on the hiring side. Maybe on choosing who they let go when cutting down the workforce, they can look at general performance reviews and such, but I doubt it plays a role in hiring.
by evolve2k | 2026-03-07 06:33:07+00:00
> I just want to help, throw a task at me!

> Great! We always need help. In order to find something that you find fun and rewarding to work on, a good first step is to find out which itch you have with Plasma Bigscreen, and how it can be scratched. What's nagging you? Now give us a shout-out, best via the Plasma mailing list. You can also make yourself known in the Matrix channel. There's plenty to do, tasks for every skill and level, and you'll find it's fun to work on and learn from each other.

https://plasma-bigscreen.org/contributing

1. Open issues on Gitlab:

https://invent.kde.org/plasma/plasma-bigscreen/-/issues

2. Join the Plasma mailing list here:

https://mail.kde.org/mailman/listinfo/plasma-devel

3. Join the Matrix channel and say you want a task here:

https://matrix.to/#/%23plasma-bigscreen:kde.org
Show HN: Stopping OpenClaw from breaking your mails
by HalfEmptyDrum | 2026-03-07 06:33:49+00:00
This project puts a lightweight layer in between your gmail-account and OpenClaw. When OpenClaw sends an e-mail, it can only send drafts. You can then in your e-mail program either send the mail or adjust the draft and send it back to OpenClaw.
This makes OpenClaw much more usable.
by JKCalhoun | 2026-03-07 06:35:35+00:00
My "taste" (like perhaps all other "tastes") comes from experience. Cliche, I know.

When you have had to tackle dozens of frameworks/libraries/API over the years, you get to where you find you like this one, dislike that one.

Get/Set, Get/Set… The symmetry is good…

Calling convention is to pass a dictionary: all the params are keys. Extensible, sure, but not very self-documenting, kind of baroque?

An API that is almost entirely call-backs. Hard to wrap your head around, but seems to be pretty flexible… How better to write a parser API anyway?

(You get the idea.)

And as you design apps/frameworks yourself, then have to go through several cycles of adding features, refactoring, you start to think differently about structuring apps/frameworks that make the inevitable future work easier. Perhaps you break the features of a monolithic app into libraries/services…

None of this is novel, it's just that doing enough of it, putting in the sweat and hours, screwing up a number of times) is where "taste" (insight?) comes from.

It's no different from anything else.

Perhaps the best way to accelerate the above though is to give a junior dev ownership of an app (or if that is too big of a bite, then a piece of a thing).

"We need an image cache," you say to them. And then it's theirs.

They whiteboard it, they prototype it, they write it, they fix the bugs, they maintain it, they extend it. If they have to rewrite it a few times over the course of its lifetime (until it moves into maintenance mode), that's fine. It's exactly how they'll learn.

But it takes time.
by nchmy | 2026-03-07 06:35:50+00:00
It's a nice article about a topic I care a lot about (the need for rediscovering hypermedia, and about the magnificent Datastar library/framework).

But I fear that the comparison is less SPA vs Hypermedia than a specific nextjs app on vercel versus a specific php app on a vps. And that people will justifiably give people reason to dismiss the whole thing outright.

If anyone is inclined to do that, I really urge you to look at Datastar's website and examples to see what it is capable of.

Also to read infrequently.org for far more about spa (especially react) vs hypermedia + progressive enhancement.
by silisili | 2026-03-07 06:36:46+00:00
Absolutely.

And if you take a step back and look at Covid spending, what it was spent on, and how much fraud was involved, it's absolutely maddening that the government isn't instead spending money on solving actual problems its constituents face. We basically just shoveled free money at anyone who claimed to have a business, to no real effect.

C'est la vie, I guess.
by jqpabc123 | 2026-03-07 06:36:58+00:00
yes, llms can produce bad code, they can also produce good code, just like people

Over time, you develop a feel for which human coders tend to be consistently "good" or "bad". And you can eliminate the "bad".

With an LLM, output quality is like a box of chocolates, you never know what you're going to get. It varies based on what you ask and what is in it's training data --- which you have no way to examine in advance.

You can't fire an LLM for producing bad code. If you could, you would have to fire them all because they all do it in an unpredictable manner.
by tkgally | 2026-03-07 06:37:47+00:00
Thanks! The strength of my dictionary, I hope, is how the information on each word is chosen and presented with the needs of English-speaking learners in mind, especially the explanations of meanings, usages, and nuances. Dictionaries that mainly give glosses can mislead learners, as it is rare for the meanings of words to map one-to-one between languages.

Compare the following pairs of entries from TKG and Jisho.org:

https://www.tkgje.jp/entries/03000/03495_chousen.html

https://www.tkgje.jp/entries/11000/11013_charenji.html

https://jisho.org/search/挑戦

https://jisho.org/search/チャレンジ

While the two from Jisho.org have more information, they do not make clear the important differences between challenge in English and the two Japanese words. Claude, meanwhile, added this note:

‘In English, "challenge" often implies confrontation or difficulty. In Japanese, チャレンジ carries a strongly positive connotation of bravely attempting something new or difficult. It is closer in meaning to "attempt" or "try" than to "confront." ’

The entries for my dictionary are being written one at a time by Claude based on guidelines for the explanations, the length and vocabulary of the example sentences, etc. Those guidelines (which you can see in the prompts and Claude skills in the GitHub repository) were developed by me and Claude with a particular purpose in mind: helping a learner encountering a new word get a good basic understanding of what it means and how it is used. In my experience, at least, it is very helpful at that stage to get explanations, not just glosses.

The Jisho site does do a good job of linking together a lot of different databases. They are welcome to add links to entries in my dictionary, too, if they like.
Show HN: I built a tool to manage work and personal Git repos
by tomquirk | 2026-03-07 06:38:36+00:00
I finally got fed up with making work + personal Git repos work on my machine.

Ever clone a work repository and accidentally make commits using your personal email? Or forget how to make your work repos use your work SSH key? Yeah... same.

So I built the tool I've always wanted. GitPersona - a CLI tool for managing many git profiles on a single machine.

Shoutout to my boy Codex for helping me finally ship this.
by hrmtst93837 | 2026-03-07 06:39:41+00:00
Adding UUID to the standard library is defensible for a server-focused language, but making it part of the stdlib binds maintainers to long-term compatibility and support, so the debate should focus on API surface and long term maintenance rather than whether third-party packages exist.

If added, keep the scope small: implement RFC 4122 v4 generation using crypto/rand.Read with correct version and variant bit handling, provide Parse and String, MarshalText and UnmarshalText, JSON Marshal and Unmarshal hooks, and database/sql Scanner and Valuer, and skip v1 MAC and time based generation by default because of privacy and cross-platform headaches.
by schnebbau | 2026-03-07 06:40:03+00:00
I had my real-deal moment recently.

I was getting Claude to implement a popular TS drag and drop library, and asked it to do something that, it turns out, wasn't supported by the library.

Claude read the minified code in node_modules and npm patched the library with the feature. It worked, too.

Obviously not ideal for future proofing but completely mind blowing that it can do that.