DEV Community: Sueun Cho

Introducing AICreditsBar: a macOS menu-bar quota widget for Codex, Claude, and Gemini

Sueun Cho — Sat, 06 Jun 2026 04:06:16 +0000

Introducing AICreditsBar

When I use more than one AI coding tool, checking remaining usage can become its own tiny task. Codex, Claude, and Gemini each fit different moments, but switching between them is easier when I can see quota state without opening another page.

AICreditsBar is an open-source macOS menu-bar widget for that workflow. It shows how much token quota is left for Codex, Claude, and Gemini, uses auto-detection, and makes no network calls.

Source: sueun-dev/AICreditsBar

Verified source facts

From the GitHub repository description, AICreditsBar is:

a macOS menu-bar widget
built to show remaining token quota for Codex, Claude, and Gemini
auto-detected
designed with no network calls
open source on GitHub

Those are the source-backed facts. The rest of this article is practical developer framing around how a small menu-bar utility can fit into day-to-day AI-assisted development.

Why this is useful

A quota check is not a large task, but it is a frequent interruption. If I have to open a terminal, visit a web page, or switch contexts just to see whether I still have usable capacity in a tool, that overhead adds up.

Putting the state in the macOS menu bar changes the interaction. Instead of stopping the current task, I can glance at the top of the screen, confirm the remaining state, and keep working.

Main characteristics

AICreditsBar focuses on a narrow surface area:

macOS menu-bar presence
Codex, Claude, and Gemini support
remaining token or quota display
automatic status detection
no network calls
a lightweight fit for developer workflows

The no-network-calls part is important to the shape of the tool. The point is not to create another remote dashboard. It is to surface local, automatically detected state in the place where macOS developers already glance during work.

How to use it

The practical flow is intentionally simple.

Open the GitHub repository.
Review the latest README and project instructions.
Run it on macOS according to the repository guidance.
Check the menu bar for the remaining Codex, Claude, and Gemini quota state.

I would use it during the normal loop of AI-assisted coding: ask one tool for implementation help, use another for review or explanation, then quickly check the menu bar before deciding which tool to use next.

Who it is for

AICreditsBar is a good fit for:

macOS developers who frequently use AI coding tools
people who switch between Codex, Claude, and Gemini
anyone who checks remaining quota often
developers who prefer small workflow utilities over heavier dashboards

Closing note

AICreditsBar is not trying to be a large platform. It is a small developer convenience: put the quota signal where it is easy to see, avoid extra network calls, and keep the workflow moving.

Source: GitHub - sueun-dev/AICreditsBar

chatgpt-oauth-bridge: local OpenAI-compatible experiments without API keys

Sueun Cho — Fri, 05 Jun 2026 19:37:30 +0000

What is chatgpt-oauth-bridge?

chatgpt-oauth-bridge is a developer bridge for local AI experimentation. Based on the GitHub repository description, it uses ChatGPT/Codex OAuth sessions for text, images, Realtime audio, embeddings, files, and local OpenAI-compatible routes. It is described with a clear constraint: no API keys.

Source: https://github.com/sueun-dev/chatgpt-oauth-bridge

Verified source facts

The confirmed source for this introduction is the GitHub repository description. From that source, the project is described as:

A bridge using ChatGPT/Codex OAuth sessions
A no API keys approach
A way to work with text, images, Realtime audio, embeddings, and files
A local OpenAI-compatible route surface

That is the verified layer. I am not adding install commands, exact endpoint names, or detailed usage flows here because those details are not part of the confirmed source material for this write-up.

Developer interpretation

The interesting part of chatgpt-oauth-bridge is the boundary it creates between authentication and local developer ergonomics.

A lot of AI application code is already organized around an OpenAI-compatible interface. Even when the underlying authentication or session model changes, developers often want to keep the local request shape familiar while experimenting.

chatgpt-oauth-bridge is useful to think about in that context: local app code can target OpenAI-compatible routes, while the bridge is described as using ChatGPT/Codex OAuth sessions rather than API keys.

Conceptually, the flow looks like this:

Local app or script -> local OpenAI-compatible routes -> chatgpt-oauth-bridge -> ChatGPT/Codex OAuth session

That is an interpretation of the project shape, not a claim about undocumented internals.

Why the capability range matters

The repository description names several capability areas: text, images, Realtime audio, embeddings, and files.

That range matters because modern AI prototypes are rarely text-only. A local experiment might begin with a text request, then add embeddings for retrieval, files for context, image handling for multimodal flows, or Realtime audio for interactive experiences.

A bridge that presents these areas through a local OpenAI-compatible route layer gives developers a consistent conceptual surface for experimentation.

What I would be careful about

I would not describe this as a drop-in replacement for every OpenAI API workflow unless the repository documents that behavior explicitly. I would also avoid assuming specific route names, request schemas, installation commands, or production guarantees from the short description alone.

The source-backed description is already strong enough: chatgpt-oauth-bridge is a no API keys developer bridge built around ChatGPT/Codex OAuth sessions, with local OpenAI-compatible routes for text, images, Realtime audio, embeddings, and files.

Source

GitHub: https://github.com/sueun-dev/chatgpt-oauth-bridge

Claude Opus 4.8 is showing up where developers work

Sueun Cho — Fri, 29 May 2026 21:07:34 +0000

Claude Opus 4.8 is showing up where developers work

The most useful way to read the Claude Opus 4.8 news is not as a pure model launch. I would read it as a placement signal.

Two verified updates matter here:

AWS says Claude Opus 4.8 is now available on AWS.
GitHub says Claude Opus 4.8 is generally available for GitHub Copilot.

That combination matters because it puts the model closer to two places where production work already happens: enterprise AI infrastructure and developer workflows.

1. Bedrock changes the question from can it chat to can it run in a system

The AWS announcement is important because Bedrock is not a demo surface. It is where teams think about production inference, security boundaries, model access, application integration and enterprise AI workloads.

For developers, this changes the practical questions:

What task should this model own?
What data is it allowed to see?
What tools can it call?
How do we evaluate failures?
What is the fallback path when the answer is uncertain?

A stronger model is useful, but the system around it is what makes it deployable.

2. Copilot puts Claude Opus 4.8 into the inner loop

GitHub says Claude Opus 4.8 is generally available for GitHub Copilot. The changelog also notes that early testing showed a clear step forward in code understanding and generation.

That is the part developers should pay attention to. Coding assistants are not just about producing snippets. The higher value work is often codebase understanding, refactoring support, test failure analysis and explaining the impact of a change.

When the model is inside Copilot, the unit of interaction can become closer to the actual developer loop: read code, propose a change, reason about tests, review the diff and repeat.

3. The agent reality check

The cautious part of the story comes from the ITBench-AA post by IBM Research and Artificial Analysis on Hugging Face. Its headline finding is that frontier models scored below 50% on agentic enterprise IT tasks.

That does not make Claude Opus 4.8 less interesting. It makes the implementation bar clearer.

Enterprise agents are hard because they need more than language ability. They need reliable tool use, state awareness, permission handling, auditability and safe recovery from partial failure.

What I would test first

If I were evaluating Claude Opus 4.8 in a developer or enterprise setting, I would start with scoped tasks:

Explain unfamiliar parts of a codebase.
Compare two implementation options.
Draft tests for an existing module.
Summarize logs or incidents for a human operator.
Propose an automation plan without executing it.

Then I would measure results against a small internal benchmark before expanding permissions.

Bottom line

Claude Opus 4.8 looks important because it is landing in real work surfaces: AWS for production AI paths and GitHub Copilot for developer workflows.

But availability is not the same as autonomy. The near term opportunity is better assisted work, not unsupervised enterprise agents.

Sources

AWS: https://aws.amazon.com/blogs/machine-learning/claude-opus-4-8-is-now-available-on-aws/

GitHub: https://github.blog/changelog/2026-05-28-claude-opus-4-8-is-generally-available-for-github-copilot

ITBench-AA: https://huggingface.co/blog/ibm-research/itbench-aa

AI Is Leaving the Chat Box

Sueun Cho — Wed, 29 Apr 2026 17:26:40 +0000

AI Is Moving Into Group Chats, Military Systems, and Field Infrastructure

The April 29 AI news cycle had a clear pattern.

The most interesting stories were not just about model capability. They were about deployment context.

1. AI inside group chats

TechCrunch reported that Shapes lets humans and AI characters chat together in shared group conversations. The company emerged from stealth with $8 million in seed funding, has more than 400,000 monthly active users, and says users have created three million Shapes.

The interesting part is the product surface. A private AI companion has one safety model. An AI participant inside a group chat has another. The system now affects a shared social environment, not just one user's private thread.

Source: https://techcrunch.com/2026/04/29/meet-shapes-the-app-bringing-humans-and-ai-into-the-same-group-chats/

2. AI models trained for military autonomy

Scout AI raised a $100 million Series A and is training AI systems around autonomous military ATVs, according to TechCrunch. The company is building Fury to operate and command military assets.

This is a reminder that "agentic AI" is not only browser automation. In physical environments, the cost of bad behavior changes. Evaluation has to include sensors, uncertainty, latency, permissions, rollback limits, and auditability.

Source: https://techcrunch.com/2026/04/29/coby-adcocks-scout-ai-raises-100-million-to-train-models-for-war-we-visited-its-bootcamp/

3. Drone factories that move closer to the field

Firestorm Labs raised $82 million and makes xCell, a containerized manufacturing platform that can print drone systems in under 24 hours, TechCrunch reported.

This is interesting because AI-adjacent systems are increasingly tied to operational loops: design, manufacturing, deployment, feedback, and redesign.

Source: https://techcrunch.com/2026/04/29/firestorm-labs-raises-82m-to-take-drone-factories-into-the-field/

Takeaway

The AI question is shifting from "what can the model generate?" to "where is the model allowed to participate, decide, and act?"

That is a harder engineering problem.

안녕하세요

Sueun Cho — Tue, 28 Apr 2026 04:22:00 +0000

안녕하세요. DEV에서 처음 인사드립니다.