DEV Community: Sueun Cho

exchange-listing-sniper: a Telegram to Bybit KRW listing signal automation project

Sueun Cho — Tue, 23 Jun 2026 02:30:39 +0000

Source-backed facts

The verified source for this article is the GitHub repository: https://github.com/sueun-dev/exchange-listing-sniper

The repository describes exchange-listing-sniper as a low-latency Telegram → Bybit listing sniper. It is designed to detect new KRW spot listing signals from Upbit and Bithumb, then market-buy the same coin on Bybit within milliseconds. The repository description also mentions a C++/Rust hot path, MTProto ingest and money-safety guards.

Why Telegram → Bybit

For this kind of market-flow automation, Telegram is the event intake layer. Listing announcements and monitor feeds can reach Telegram quickly, so the system can treat each message as a candidate event instead of waiting for a slower manual workflow.

Bybit is the execution layer in this project. That separation matters: the source event is a Korean exchange KRW listing, while the order route is a different venue. The hard engineering work is not just speed. It is verifying that the parsed ticker maps to a tradable Bybit symbol and that guardrails allow the order.

A practical pipeline view

A developer can read the architecture as a sequence of small decisions:

ingest Telegram messages with very low latency
classify whether the message is related to Upbit or Bithumb
detect whether it is specifically a KRW spot listing signal
extract and normalize the ticker
deduplicate repeated or mirrored messages
map the ticker to the Bybit instrument
apply money-safety checks and order limits
submit the market order and record the result

The middle of the pipeline is where most failures hide. A fast parser that confuses a maintenance notice, an event notice or a non-KRW market for a new KRW spot listing would be dangerous.

Why low latency matters

New listing windows are crowded public events. Market makers, bots and manual traders can all react at once, and the order book may change faster than a human can verify the announcement and click through an exchange UI.

Low latency can reduce delay, but it does not remove market risk. A market order can face slippage, partial liquidity, symbol mismatch, API rate limits or exchange-side rejections. Speed is useful only when the signal is correct and the allowed order size is controlled.

What I would inspect before using code like this

I would review API permissions, allowed order size, symbol allowlists, idempotency, duplicate-message handling, logging, failure paths and exchange terms. I would also keep the system observable, because an automated order path should be easy to stop and audit.

This is a technical project note, not financial advice. It is not a buy or sell recommendation for any asset.

Source

https://github.com/sueun-dev/exchange-listing-sniper

Start AI-assisted development by finding similar GitHub projects first

Sueun Cho — Mon, 15 Jun 2026 18:53:18 +0000

Practical developer interpretation

The first AI prompt should not be: write the code.

A better first prompt is: find similar GitHub open-source projects and explain how they are built.

When you ask for code first, the model has to invent structure. It may produce something that runs, but the architecture can be arbitrary. When you ask for comparable repositories first, the model has to reason from existing product and code patterns before it generates anything.

That shift matters because most early build mistakes are not syntax mistakes. They are boundary mistakes. State lives in the wrong place. API routes grow without a clear domain model. Configuration spreads across the app. Deployment assumptions leak into application code.

The opening prompt

I want to build [service description].
The main users are [user type], and the core features are [feature list].
Find similar GitHub open-source projects and compare them.
For each project, summarize the problem it solves, main features, directory structure, data storage approach, authentication boundary, deployment shape, license, maintenance signals, useful design ideas, and parts I should not copy directly.
Do not write code yet. Start with a comparison and a recommendation.

The important line is: do not write code yet.

That line keeps the model in analysis mode. It also gives you a chance to inspect architecture before implementation begins.

What to compare before code

I usually ask the AI to compare the repositories across a few practical dimensions:

Where the user flow starts
How client and server responsibilities are separated
Whether the data model follows domain concepts or UI screens
Where auth, permissions, and environment configuration live
How async work is separated from request handling
Whether tests and seed data explain real usage
How deployment assumptions shape the codebase

This is not about copying a repository. It is about building a map of decisions.

The second prompt

After the shortlist, I ask:

From these projects, extract the repeated architectural patterns.
For my service, separate what is necessary now from what is overbuilt.
Propose the smallest vertical slice for version one.
Explain the folder structure, data model, API boundary, and screen flow before writing code.

At that point, code generation becomes much more useful. The AI is no longer filling an empty page. It is implementing inside a structure that has already been compared.

Implementation framing

A good AI-assisted build can follow this sequence:

Ask for comparable open-source projects.
Compare architecture, product scope, and boundaries.
Choose the smallest useful vertical slice.
Ask the AI to generate only that slice.
Review the generated code against the comparison, not against vibes.

This gives you a practical review checklist. If a generated module does not match the chosen boundary, you can push back. If a feature appears that was not in the first slice, you can remove it. If the AI creates a clever abstraction too early, you have a reason to simplify it.

CoinHelio as a Listing Flow Lens: Modeling Post-Listing Transfer Arbitrage by EV

Sueun Cho — Thu, 11 Jun 2026 17:15:42 +0000

CoinHelio as a Listing Flow Lens

The verified source for this note is the CoinHelio homepage: https://coinhelio.com/

From that source, CoinHelio is presented as a free coin analysis and coin information analysis platform. The homepage says it analyzes Bithumb holder metrics, circulating supply, and influence indicators in real time, while tracking snapshots and listing flows for 600+ coins including Bitcoin and Ethereum.

That is the source-backed part.

What is not verified from the homepage alone: whether CoinHelio provides exchange-by-exchange deposit status, withdrawal status, transfer ETA modeling, order book depth, fee simulation, slippage modeling, API endpoints for arbitrage bots, or actual historical win-rate data for transfer arbitrage. Those details need separate validation before being used in production.

The developer mistake: treating spread as profit

Post-listing arbitrage often starts with a visible gap between exchanges. Exchange A prints lower. Exchange B prints higher. A bot sees the spread and marks it as an opportunity.

That is too thin.

In transfer arbitrage, the asset has to move. During that time, the destination bid can disappear, deposits can remain closed, the network can congest, and the book can thin out. A last traded price or top-of-book quote is not the same as executable profit.

For developers, the core object should not be price_gap. It should be route_expected_value.

A better route model

For a route from source exchange S to destination exchange D at size Q, I would separate the model into gates and calculations.

Gate variables:

Withdrawal open on S for the exact asset and network
Deposit open on D for the exact asset and network
Address, memo, tag, and network compatibility confirmed
Transfer ETA distribution available, not just a single average
Exchange maintenance and listing restrictions checked

Pricing variables:

Buy VWAP on S for size Q using the ask book
Sell VWAP on D for size Q using the bid book
Expected sell VWAP after a transfer-time haircut
Maker or taker fee assumptions, depending on execution style
Withdrawal fee, network fee, conversion fee, and funding cost if relevant
Slippage buffer based on recent book movement

Risk variables:

Probability that the spread survives until arrival
Probability of delayed transfer
Probability of partial execution
Operational failure cost

This turns the problem from a screen-watching spread detector into a market-structure model.

Net profit formula

A simple version is:

Net profit = Q × expected destination sell VWAP - Q × source buy VWAP - trading fees - withdrawal fees - network fees - conversion costs - slippage buffer - operational failure cost

The important words are expected and VWAP.

Expected means the destination price is not the current visible price. It is the price after the expected transfer window, adjusted for the possibility that the post-listing premium decays.

VWAP means the bot does not assume the best bid or best ask fills the whole order. It walks the book for the intended size.

Win rate is not enough

A raw win rate can be misleading. If 80 percent of routes make a small amount and 20 percent lose a large amount due to delayed transfers or collapsed liquidity, the expected value can still be negative.

A cleaner historical definition is:

Win rate = comparable listing routes with realized net profit above zero ÷ total comparable listing routes

Then expected value should be estimated separately:

EV = p_win × average net gain - p_loss × average net loss - fixed monitoring and operating costs

This requires real historical data: listing time, deposit and withdrawal status, transfer completion time, order book snapshots, fill logs, and fee records. Without those, win rate is only a story, not a measurement.

Where CoinHelio fits

Based on the verified homepage, CoinHelio can be read as a market-flow dashboard for coin information, Bithumb-related metrics, circulating supply context, snapshots, and listing flow tracking. For a developer, that can be useful as the upstream awareness layer: what is moving, what has been listed, and which assets deserve closer monitoring.

But production transfer arbitrage needs a second layer: exchange status data, network data, order books, fee schedules, and realized execution logs. I would not treat any platform as an execution engine unless those functions are explicitly verified and tested.

Risk framing

This is public market-structure commentary, not financial advice. I am not suggesting any coin, route, trade, exchange, or execution decision. The point is analytical: post-listing transfer arbitrage should be judged by executable net profit and expected value, not by headline price gaps.

Source: https://coinhelio.com/

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에서 처음 인사드립니다.