Show HN: Claude-ts – Translation proxy to fix non-English token waste in Claude https://ift.tt/FIh7UaS

Show HN: Claude-ts – Translation proxy to fix non-English token waste in Claude When you use Claude Code in Korean, Japanese, or any non-English language, two things happen: 1. You waste tokens — non-English text takes 2-3x more tokens than English for the same meaning. Every prompt, every response, every turn in context is inflated. 2. Claude reasons worse — it spends context budget on language switching instead of actually thinking about your code. I built claude-ts to fix this. It's a translation proxy that sits in front of Claude Code: You (any language) → Haiku/Ollama (→ EN) → Claude Code (EN) → Haiku/Ollama (→ your lang) → You Claude Code always works in English internally — better reasoning, fewer tokens. The translation costs almost nothing (Haiku) or literally nothing (local Ollama). pip install claude-ts - 8 languages supported (ko, ja, zh, th, hi, ar, bn, ru) - Free local translation via Ollama - Real-time agent tree visualization - All Claude Code features preserved https://ift.tt/DnTiAja February 22, 2026 at 02:43AM

Show HN: How to Verify USDC Payments on Base Without a Payment Processor https://ift.tt/cTstKQz

Show HN: How to Verify USDC Payments on Base Without a Payment Processor The Problem Nobody Talks About You want to accept a $10,000 USDC payment. You have two options: Option A: Integrate a payment processor like Coinbase Commerce. Set up an account, embed their checkout widget, handle their SDK. Pay $100 in fees (1%). Option B: Build your own blockchain listener. Learn ethers.js, subscribe to USDC transfer events, handle reorgs, confirmations, edge cases. Two weeks of work, minimum. There's no middle ground. No service that just tells you: "Yes, this specific payment arrived." Until now. https://ift.tt/nIHGaDd https://paywatcher.dev February 22, 2026 at 02:35AM

Show HN: Screenwright – Turn Playwright E2E tests into polished demo videos https://ift.tt/cwQEpL9

Show HN: Screenwright – Turn Playwright E2E tests into polished demo videos https://ift.tt/1sluNKq February 22, 2026 at 01:09AM

Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron https://ift.tt/RPKsyvt

Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron Hi HN. I am a programmer from Japan who loves Emacs. I am building elecxzy. It is a free (zero-cost), lightweight, Emacs-like text editor for Windows. I designed it to be comfortable and ready to use immediately, without a custom init.el. Here is a quick overview: - Provides mouse-free operation and classic Emacs keybindings for essential tasks (file I/O, search, split windows, syntax highlighting). - Drops the Lisp execution engine entirely. This keeps startup and operation lightweight. - Solves CJK (Chinese, Japanese, Korean) IME control issues natively on Windows. I never managed to learn Lisp. I just copy-pasted snippets to maintain my init.el. However, I loved the Emacs keybindings. I loved operating an editor entirely without a mouse. I wanted an editor I could just open and use immediately. Also, standard Emacs binaries for Windows often have subtle usability issues for CJK users. So, I thought about whether I could build an Emacs-like text editor using Electron, the same framework as VS Code. Building an editor inside a browser engine required thinking a lot about what NOT to build. To make it feel native, I had to navigate DOM limitations. I learned that intentionally dropping complex features improves rendering speed. For example, I skipped implementing "word wrap." For syntax highlighting, I did not use a full AST parser. Instead, I used strict "line-by-line" parsing. The highlight colors for multi-line comments are occasionally incorrect, but it is practically unproblematic and keeps the editor fast. Under the hood, to bypass browser limitations and handle large files smoothly, I implemented a virtual rendering (virtual scrolling) system. For text management and Undo/Redo, I use a custom Piece Table. I built a custom KeyResolver for Emacs chords. I also used koffi to call Win32 APIs directly for precise IME control. I respect Windows Notepad as one of the most widely used text editors. However, in my daily work or coding tasks, I often felt it lacked certain features. On the other hand, I found VS Code too heavy just to write a quick memo. Even with extensions, it never quite gave me that native Emacs flow. I do not want to replace Notepad, VS Code, or Emacs. If users want rich extensions and heavy customization, I believe they should use Emacs or VS Code. My goal is to fill the gap between them—to build a "greatest common denominator" editor for people who just want an Emacs-like environment on Windows without the setup. It is still in alpha (so it might not work perfectly), but you can test it on Windows by downloading the zip from the GitHub releases, extracting it, and running elecxzy.exe. For screenshots, basic usage, and keybindings, please check the README on the GitHub project page. I am looking for feedback: Is there a demand for a zero-config, Lisp-free, "Notepad-like" Emacs-style editor? What are the minimum standard features required to make it useful? I would love to hear your technical insights. https://ift.tt/wKMEq4v February 21, 2026 at 02:49AM

Show HN: DomeAPI (YC F25) was acquired. pmxt is the open-source equivalent https://ift.tt/xAteDbp

Show HN: DomeAPI (YC F25) was acquired. pmxt is the open-source equivalent Hi HN, I'm the maintainer of pmxt. With Polymarket's recent acquisition of DomeAPI to bring their infrastructure in-house, there is a sudden gap for developers building cross-market arbitrage bots, tracking whale wallets, or running quantitative models across prediction markets. If you are trading across Polymarket, Kalshi, or Limitless, you need a unified API to avoid getting locked into a single exchange's ecosystem. pmxt is stepping in to fill that void. https://ift.tt/S0HOoBP February 20, 2026 at 10:02PM

Show HN: GenPPT AI – Turn any idea into professional slides in seconds https://ift.tt/kBTQdhl

Show HN: GenPPT AI – Turn any idea into professional slides in seconds https://genppt.ai/ February 20, 2026 at 10:47PM

Show HN: A native macOS client for Hacker News, built with SwiftUI https://ift.tt/MaFWVou

Show HN: A native macOS client for Hacker News, built with SwiftUI Hey HN! I built a native macOS desktop client for Hacker News and I'm open-sourcing it under the MIT license. GitHub: https://ift.tt/h1R2Lrx Download (signed & notarized DMG, macOS 14.0+): https://ift.tt/u0Oxp4A Screenshots: https://ift.tt/RfUr2q7 I spend a lot of time reading HN — I wanted something that felt like a proper Mac app: a sidebar for browsing stories, an integrated reader for articles, and comment threading — all in one window. Essentially, I wanted HN to feel like a first-class citizen on macOS, not a website I visit. What it does: - Split-view layout — stories in a sidebar on the left, articles and comments on the right, using the standard macOS NavigationSplitView pattern. - Built-in ad blocking — a precompiled WKContentRuleList blocks 14 major ad networks (DoubleClick, Google Syndication, Criteo, Taboola, Outbrain, Amazon ads, etc.) right in the WebKit layer. No extensions needed. Toggleable in settings. - Pop-up blocking — kills window.open() calls. Also toggleable. - HN account login — full authentication flow (login, account creation, password reset). Session is stored in the macOS Keychain, and cookies are injected into the WebView so you can upvote, comment, and submit stories while staying logged in. - Bookmarks — save stories locally for offline access. Persisted with Codable serialization, searchable and filterable independently. - Search and filtering — powered by the Algolia HN API. Filter by content type (All, Ask, Show, Jobs, Comments), date range (Today, Past Week, Past Month, All Time), and sort by hot or recent. - Scroll progress indicator — a small orange bar at the top tracks your reading progress via JavaScript-to-native messaging. - Auto-updates via Sparkle with EdDSA-signed updates served from GitHub Pages. - Dark mode — respects system appearance with CSS and meta tag injection. Tech details for the curious: The whole app is ~2,050 lines of Swift across 16 files. It uses the modern @Observable macro (not the old ObservableObject/Published pattern), structured concurrency with async/await and withThrowingTaskGroup for concurrent batch fetching, and SwiftUI throughout — no UIKit/AppKit bridges except for the WKWebView wrapper via NSViewRepresentable. Two APIs power the data: the official HN Firebase API for individual item/user fetches, and the Algolia Search API for feeds, filtering, and search. The Algolia API is surprisingly powerful for this — it lets you do date-range filtering, pagination, and full-text search that the Firebase API doesn't support. CI/CD: The release pipeline is a single GitHub Actions workflow (467 lines) that handles the full macOS distribution story: build and archive, code sign with Developer ID, notarize with Apple (with a 5-retry staple loop for ticket propagation delays), create a custom DMG with AppleScript-driven icon positioning, sign and notarize the DMG, generate an EdDSA Sparkle signature, create a GitHub Release, and deploy an updated appcast.xml to GitHub Pages. Getting macOS code signing and notarization working in CI was honestly the hardest part of this project. If anyone is distributing a macOS app outside the App Store via GitHub Actions, I'm happy to answer questions — the workflow is fully open source. The entire project is MIT licensed. PRs and issues welcome: https://ift.tt/h1R2Lrx I'd love feedback — especially on features you'd want to see. Some ideas I'm considering: keyboard-driven navigation (j/k to move between stories), a reader mode that strips articles down to text, and notification support for replies to your comments. https://ift.tt/h1R2Lrx February 20, 2026 at 04:02AM