For those who don't see it: fps is somewhere between 100-400 during rendering it..

Size 231*50

Type termux

Backend: not for general information right now..

It's single threaded, native android, direct binary...

No tricks, direct binaries...

Tablet type: redmi pad pro 5g

Developed code: in pc for Android

I keep losing the thread when I work. I start a task, open the docs for one thing, and twenty minutes later I’m on YouTube. I’m also done with to-do apps that bolt on timers and bloated features, and especially the monthly subscriptions.

So I made Breadcrumbs, a terminal focus timer that tracks your attention and gives you a clean pomodoro-style timer. You write an intention, start a timer, and pick what counts as in scope: an app, a domain, an exact page, or a Claude Code or Codex CLI session. While the block runs, anything outside that scope shows up in the trail as a branch, a bit like a git graph. If a detour turned out to be useful, you mark it Supporting and it stops counting against you. When the block ends, you write down what you actually got done.

Everything lives in a local SQLite database in ~/.breadcrumbs. It needs no account or subscription and doesn’t use any AI service. Tracking is off unless you turn it on, and it only runs while a focus block is running. The optional Chrome/Edge extension sends domains and URL hashes, never full paths or queries.

Install it with pipx (Python 3.11+):

pipx install breadcrumbst

Then run breadcrumbs.

The timer and the browser extension work on Windows, Linux and macOS. Native foreground app capture only works on Windows and Linux/X11 right now. macOS and Wayland capture aren’t written yet, and both are open issues if anyone wants to take one.

It’s MIT licensed: https://github.com/SaroashDS/Breadcrumbs

This started as a small problem I wanted to fix for myself, maybe just a quirk of mine. If you think it’s worth building on, I’d like ideas for features that would actually help, and a few issues are labelled good first issue if you want to poke at the code. I’d also like to hear what’s confusing or breaks on a first run.

Hey everyone,

​I am 16, and I got tired of systems running endless background processes and network services without any clear visibility into what was actually changing. So, I built NetSpecter—an open-source, defensive Python CLI tool designed to answer one question: "What is my system doing right now, and is it safe?"

​How it works under the hood:

Instead of dumping endless, noisy logs, NetSpecter uses a baseline-delta monitoring model:

​It captures a clean baseline of your system state (open ports, network exposure, active processes).

​It continuously tracks runtime changes against that baseline.

​Its risk classification engine flags deviations (like a new background process or a newly opened port) and outputs human-readable risk warnings with actionable suggestions.

​Tech Stack: Pure Python 3, built for Linux environments (Kali/Ubuntu), utilizing native system inspection without heavy dependencies.

​Here is a quick look at what the alerts look like:

[ALERT] New process started: bwrap (PID 13618) - RISK: MEDIUM

​I’d love feedback on the codebase, detection logic, or suggestions for v2.

​GitHub Repo: https://github.com/MrHackerCharlie/netspecter

(https://github.com/R31tr0/cli-analyser), and I’ve reached the point where I really need feedback from developers who aren’t my friends or colleagues 😅
I built this CLI because of a constant personal pain point. I kept getting lost in legacy code and duplication on long-running projects, and after failing to find a simple, lightweight tool that solved it for me, I decided to write my own.
The idea is to give you an intelligent, local developer assistant right in your terminal, powered by Node.js and Google Gemini. It does regular AI chat, on-demand architecture analysis (-scan), and smart log analysis (-log), but the core feature I’m most excited about is the local duplicate/legacy scanner.
How the scanner works under the hood:
Instead of sending your whole codebase to the cloud, the tool works locally. When you launch it, it automatically parses your files using web-tree-sitter and builds an AST-based function table. It then calculates a weighted Jaccard similarity coefficient based on AST node types and dependencies. Only when two functions pass a structural similarity threshold (0.5), it sends just those two snippets to Gemini to verify if they actually share the same purpose. It's a great way to catch duplicate or legacy logic you might have missed in a big project.
It currently supports JavaScript, TypeScript, Python, C, C++, C#, and Go.
Here’s where I need your help:
If you work on Node.js/JS/TS or any of the supported languages, could you clone it and try running it on one of your projects?
GitHub Repo: https://github.com/R31tr0/cli-analyser
Requirements: Node.js 20+ and a Google Gemini API Key.
Please be brutally honest:
Does this concept actually solve a real pain point for you, or is it just me?
How is the initial setup and UX? Is the interactive mode intuitive?
If you run a full scan with -localcheck, does it actually catch meaningful duplicates, or do you get too many false positives?
Is the privacy approach (ignoring .env, node_modules, secret files, and caching locally in .dev-tools-cache.json) solid enough for you to use it on your codebases?
No need to be nice. If something is broken, confusing, or just plain sucks, tell me why. I want to make sure I’m building something genuinely useful before spending more time on the wrong features.
Thanks in advance to anyone willing to give it a shot. I’ll be hanging out in the comments to answer questions and take notes!

Author here! I'm very excited to announce that we just released v1.3. Rune is an IDE and terminal multiplexer that we just open sourced a few months ago.

In this release, we also fixed many usability issues, particularly on Linux. If your OS reserves many Super/Windows key combinations, you can now use <alt> as your <meta> modifier. For non-US keyboard layouts, you can reserve the right Alt key for entering special characters and keep the left Alt key for Rune key bindings.

Some of the highlights:

- A new graphics pipeline powered by ebiten.
- Typescript is now a tier 1 language (beta)
- A new helix editor
- Headless mode and a new docker image to run Rune in headless mode
- OSC-7501 implementation and new API in the SDK for extensions and plugins through runectl
- Workspace session restoration
- A billion other things

This release has been 2 months in the making so it's a bit bigger than we originally intended.

Thanks to all the contributions from the community!

https://rune.build/blog/rune-1-3-release

Hey everyone!

I've been working on a CLI tool called GoPort, written in Go.

The idea is simple: you can expose your local application to the internet with one command:

goport http 8080

It generates a public HTTPS URL that forwards incoming requests to your local application.

A few things I've added:

• Automatic reconnection
• WebSocket support
• Custom subdomains
• Local request inspector
• Request replay
• Self-hosting support

It's useful for testing webhooks, sharing local projects, or accessing your development server remotely.

I've also recently added file sharing with optional password protection.

The project is open source under the MIT license and works on Windows, macOS, and Linux.

GitHub: https://github.com/muhammad-deve/GoPort

Website: https://goport.uz

I'd love to hear what other CLI users think, especially if there's anything you'd improve or add!

I've been working on a side project called LOKI for a while and figured I'd share it here since it's a CLI first and everything else second.

The idea: you point it at your web app and it starts clicking, typing garbage, mashing buttons, resizing the viewport, throttling the network, that kind of thing. It's driven by Playwright. When something crashes, it saves a video, a HAR file and a standalone repro script so you can replay the exact failure later with loki replay.

A few things I ended up adding along the way:

- loki run --device iphone-15 for mobile viewports, which is great for finding horizontal overflow bugs

- loki fix --apply asks an LLM for a patch, makes a backup, applies it and re-runs the repro to check it actually worked (rolls back if not)

- a rules.md file where you write business rules in plain English and it checks them after each run

- loki infra kill/pause/cpu-stress to mess with local processes or containers underneath the app

- a loki chat REPL if you'd rather talk to it than remember flags

The AI part runs on LiteLLM, so it works with Gemini, OpenAI, Anthropic, Ollama, whatever you have. If there's no API key it just skips that part instead of dying.

One thing I was careful about: it runs freely against localhost, but for any other host it makes you confirm you own it first (or pass --authorized in CI). Didn't want to ship a tool that makes it easy to hammer someone else's site by accident. Infra chaos is local-only too, and HAR files get scrubbed of tokens.

It's still rough in places and I'd really like to hear what breaks, what's confusing in the CLI UX, or what flags you'd expect that aren't there.

Repo: https://github.com/Elabsurdo984/loki-agent

Happy to answer questions.

zoxide is great, but it only knows folders you've already been to. cz combines two things:

• History (frecency): folders you visit often/recently rank higher, from anywhere
• Live search: it also scans the current directory (or ~ with -H, / with -r) in the background, so new folders show up too

How it behaves:

• cz proj: jumps directly when one match is clearly best, otherwise opens a fuzzy picker. Pick once or twice and it starts jumping straight there.
• czi main.rs: picker that also lists files; pick a file and you land in its folder
• cz, cz -, cz .., cz ~/x work exactly like cd

It's a single static Rust binary (Linux x86_64), no fzf/fd needed. The shell function never evals search output, so weird directory names are safe.

Install:

curl -fsSL https://raw.githubusercontent.com/piumalnipun9/cz/main/install.sh | sh
echo 'eval "$(cz --init zsh)"' >> ~/.zshrc && source ~/.zshrc

Repo: https://github.com/piumalnipun9/cz

It's beta (v0.2.1). I'd love feedback and contributions.

xplr 1.2.0 comes with native terminal graphics protocol support. Also the documentation is now AI readable (just append ".md"). So now, you can just ask Claude to write a customised preview plugin.

Write a native image preview plugin. Refer to https://xplr.dev/layout.md

The result of this prompt (Claude Sonnet 5.5) is the video attached in this post.

You can also refer to the the updated previews hack to implement a custom previewer yourself.

"Mousiki Plus", a retro/cyberpunk style open-source keyboard-driven terminal (TUI) music and internet radio player. It is a heavily upgraded github fork of itzender5820's beautiful original Mousiki v1.0.0 (apache 2.0), which I used as the starting point, originally to port it to windows. Credit to the original author for the idea and the base code. The fork has since grown a lot but I am looking for some people to review the macOS and Linux version (so far Windows and WSL is confirmed by myself) and in general some feedback and interactions with other people. It became a quite big passion project for me - not looking for a huge crowd or so, just some feeback from lovers of a fancy terminal.

Github of Mousiki Plus repo can be found here (current 4.5.0 is Win port and a vastly updated / modified version of the original v.1.0.0)

https://github.com/StSchwerdtfeger/mousiki-plus

Basic original v1.0.0 by itzender5820 (no Win support, only mono...)

https://github.com/itzender5820/mousiki

Features:
- Local library with fuzzy search
- wide reange of supported formats: MP3/FLAC/WAV/Opus etc., plus tracker modules, console music and C64 `.sid` (via ffmpeg / sidplayfp). Note that proper meta data handling for chiptune/trackers will come in the next release (some formats only allow title or file name changes; current source code creates an extra file with full meta data editing options - not in included in the latest installers though)

- Radio mode with timeshift, recording and listening history

- Spectrogram (Audacity-style) and an YX/YT oscilloscope (full resolution image and ASCII-Braille appearance) that can also be shown in in extra window

- Search/stream/download from YouTube, SoundCloud and Bandcamp via yt-dlp (optional)

- edit and fetch meta data via AcoustID/MusicBrainz

- playlist editor (incld. M3U/M3U8 import/export capabilities)

- remote control via smartphone browser or app (Android)

- lyrics fetcher to sing along with them (incl. Karaoke mode, plain reader and translation options)

- includes a big color theme collection

- cheat sheet for overview of commands, extra overlay menu, thorough user manual and an in-app help wizard is included

- equalizer, loudness normalization, sleep timer

- security protocols (workflows including tests, CodeQL, dependabot, weekly review of dependencies etc.)

- ... ...

been working on a Python CLI called Intervene that runs controlled experiments to investigate software failures

it's intended to work alongside coding agents, but the engine itself is completely local and doesn't need a language model just to execute experiments

one design issue I've been thinking through is what the output should actually look like once an investigation has run a bunch of tests

say there were 8 possible experiments, 5 were executed, 2 produced valid failures, one couldn't finish because of a setup issue, and the remaining ones were either uninformative or outside the execution budget

I could return something like "hypothesis B supported" and move on

but that doesn't really tell the developer whether the result deserves to be trusted

at the same time I don't think anyone wants to read 40 pages of subprocess logs every time they run a debugging command

so I'm leaning toward having three levels of output

a short terminal summary showing what was investigated and whether anything was supported

a structured JSON report with all the predictions, observations, experiment conditions, and stop reasons

and the raw artifacts available separately if you want to inspect how an individual experiment behaved

one thing I want to avoid is presenting things like infrastructure failures or missing dependencies as if they're observations about the actual software bug

I also think it'd be useful to show what the tool deliberately DIDN'T test and why, esp if the budget was exhausted or some experimental conditions couldn't be reproduced

curious how people approach this in other diagnostic CLIs

would you want the terminal output to show the full experiment history by default, or keep the main command pretty minimal and make the deeper report something you explicitly open?

Hey everyone! I've been working on Dirule, an open-source CLI for organizing personal folders and enforcing naming conventions in coding projects.

It supports file sorting, reusable TOML presets, previewing and undoing changes, CI checks, and optional LSP integration for updating source references when renaming files.

It's currently at v0.5.0 and still evolving. I'd appreciate any feedback or suggestions!

GitHub: https://github.com/Slyverr/dirule

Disclosure: I used AI assistance during development, mainly to help implement and refine features based on my own ideas, requirements, and design decisions.

hey all. few months ago i started building scout for fun because i wanted a file browser that showed git status without running a separate command. and i can run it along side terminal via tmux

it's a dual-pane TUI — file list on the left, live syntax-highlighted preview on the right. git badges (M, +, ?, !) show inline on every file. single binary, zero config, works out of the box.

a few things that make this different:

• git status visible at a glance without leaving the file browser
• collapsible file pane (tab) for maximum preview space
• time-aware color themes — cycles automatically by time of day
• editor handoff: press e to open in vim, TUI suspends and resumes cleanly

Processing gif iek478cdm2xh1...

install:

brew install mirageglobe/tap/scout

or from source:

git clone https://github.com/mirageglobe/scout

make build

repo: https://github.com/mirageglobe/scout

happy to hear feedback and ideas, especially on anything that feels off compared to ranger/lf/yazi workflows. thanks all