标签：#software

markdown Hello Dev Community! 👋 I’m Anshul Raturi , a Full-Stack Software Developer and 2nd-year Computer Engineering student at Pithuwala Polytechnic in Dehradun, Uttarakhand, India. Today, I want to share my journey of building and launching two AI platforms from scratch: RaturiHub AI and MAX AI Assistant . 💡 The Problem As a developer, I use AI tools daily for coding, brainstorming, and research. However, I found that most mainstream AI wrappers are either cluttered with unnecessary features or lock their best performance behind expensive enterprise paywalls. I wanted a sleek, blazing-fast, and distraction-free AI workspace for my daily coordination and private Q&A. When I couldn’t find the perfect tool, I decided to engineer it myself. 🛠️ Building RaturiHub AI & MAX AI Over the past few months, I poured my skills in JavaScript, Python, C++, and Web Development into creating two distinct AI applications: RaturiHub AI (RaturiGPT) : An intelligent, highly responsive AI platform focused on smart chat and seamless admin coordination. MAX AI Assistant : Designed for a premium, secure, and highly optimized conversational experience. I focused heavily on the UI/UX, ensuring that the interface feels glass-like, modern, and completely intuitive. Performance optimization was key—I wanted the response latency to be as minimal as possible. ### 🚀 We Are Live on ProductHunt! Building these platforms solo was a massive learning curve, from handling API integrations to perfecting the frontend design. Today, I am thrilled to announce that RaturiHub AI is officially live on ProductHunt! 🎉 I would love for the developer community here to check it out. Your feedback on the UI, speed, and overall experience means the world to me. 🔗 Check out RaturiHub AI : [Link to your ProductHunt page or App] 🔗 My Official Portfolio : https://anshulraturi2009.github.io/portfolio/ ### 🤝 Let's Connect! I am always looking to connect with fellow developers, tech enthusiasts, and mentors. Let’s talk ab

Instead of immediately opening pull requests when newer dependency versions are released, Dependabot now waits three days before suggesting upgrades, thus increasing the likelihood that malicious releases are identified and removed before they can be integrated. By Sergio De Simone

If you have ever tried to find a new physician through a search box, you already know the frustration: outdated phone numbers, doctors who left the practice two years ago, and "accepting new patients" labels that turn out to be fiction. Anyone who has read the candid breakdown in Online Doctor Directories: A User's Guide to a Very Imperfect Tool will recognize the pattern immediately, because the core problem is not laziness on anyone's part — it is a data engineering problem hiding inside a healthcare product. And for those of us who build software for a living, it is a fascinating case study in what happens when stale data meets high-stakes decisions. The Root Cause Is a Data Pipeline, Not a Design Flaw Most doctor directories aggregate information from insurance networks, state licensing boards, hospital affiliations, and self-reported provider profiles. Each of these sources updates on its own schedule, uses its own identifiers, and defines fields differently. One system records a physician under her maiden name; another lists the clinic's billing address instead of the practice location; a third still shows a specialty she stopped practicing in 2019. The result is a classic entity-resolution nightmare. Without a reliable primary key shared across sources, merge logic has to guess whether "J. Martinez, Internal Medicine, Suite 400" and "Julia Martinez-Reyes, IM" are the same human. Get it wrong in either direction and the user suffers: duplicates erode trust, while over-aggressive merging attaches one doctor's malpractice history to a stranger with a similar name. If you have ever built a CRM deduplication service or wrestled with customer identity graphs, you have fought this exact battle — just with lower stakes. Staleness compounds the problem. Physicians change practices constantly. A directory that syncs quarterly is, by definition, wrong about a meaningful slice of its records at any given moment. Harvard Health has pointed out that an ongoing physician sh

Ben Greene discusses how software engineers can adapt and thrive in an era of rapid AI code automation. Drawing on his startup experience, he explains key mindsets like starting simple, maintaining code comprehension, attacking hard problems first, and focusing on customer impact. He shares why human empathy, agency, and practical problem-solving remain irreplaceable when code is automated. By Ben Greene

We're Byte Me , a software agency from Alkmaar, the Netherlands. The most valuable advice we give clients is usually not "Let's build something new"; it's "Let's not touch the thing that works." Here's why and how. The rebuild reflex Every company running a 15-year-old ERP has had this meeting. Someone opens the ancient interface on the big screen, everyone groans, and a decision crystallizes: "We need to replace this." We understand the reflex. The UI looks like Windows XP. The one person who understands the database retired. Adding a field takes a change request and three weeks. Every new hire asks why orders live in a system older than they are. And yet, when companies come to us with "We want to replace our legacy system," our first answer is almost always: you probably don't. Not because rebuilds are impossible but because the odds are terrible. Big-bang legacy replacements are among the highest-risk projects in software. They take longer than planned, cost more than planned, and the scariest part isn't the code: it's the twenty years of business rules buried in that old system that nobody documented. The weird discount logic for that one big customer. The field that means something different depending on which decade the record was created in. The nightly job everyone forgets exists until you turn it off. That old system isn't just software. It's your company's institutional memory, compiled. Ugly ≠ broken Here's the reframe that changes these conversations: most legacy systems don't have a functionality problem. They have an access problem. The ERP still processes orders correctly. It's been doing so, reliably, for fifteen years, a track record your rebuild won't have on day one. What's actually painful: Customers can't see their own orders, so they email and call Sales can't check stock from the road Data has to be retyped into the accounting tool, the webshop, the planning board Reporting means exporting to Excel and praying None of those problems require r

Neander has no exceptions. No try , no catch , no finally . A call to one of the host application's APIs returns something closer to Rust's Result : either the answer, or the reason there is no answer. In place of a catch block there is one type marker, three operators, and a guarantee that every submission comes back in the same shape no matter what happened. Last time the foundational series closed with isolation. This is the first of two encores, and it takes the subject that came up in nearly every entry without ever being laid out in full: what happens when something goes wrong. There are two answers, because there are two audiences. An error is a value while the program runs, and a verdict once it has stopped. The two are made of the same parts, on purpose. The failable type Every call returns a failable type, written T! . It carries either a value of type T or an error with a code, a message, and the name of the function that produced it. T! is the mirror of the nullable type T? . Same shape, different question: one asks whether a value is there at all, the other asks whether obtaining it worked. The mirroring runs deeper than the notation, because the same three operators serve both types. A failure gets no unwrapping vocabulary of its own. Those three are =? , ?? and is : // narrow, or throw the error out of the enclosing block let order : Order =? call orders .get ( id : 42 ) // or substitute a default let order : Order = call orders .get ( id : 42 ) ?? emptyOrder // or inspect it and decide let result : Order! = call orders .get ( id : 42 ) if result is error { if errorCode ( result ) != 404 { throw result } return emptyOrder } A standalone call statement, one without a let , narrows implicitly: the error is thrown and the success value is discarded. One property does the heavy lifting throughout the rest of this post: T! originates only from a call . No expression picks up a ! along the way, and no widening rule introduces one. The marker means exactly o

An Agent Harness is a comprehensive application layer that securely wraps a Large Language Model (LLM) to govern its memory, tools, execution boundaries, and deterministic policy enforcement. When engineers first transition from building simple conversational chatbots to fully autonomous AI agents, they typically make a critical mistake: they treat the Large Language Model (LLM) as the entire system. The reality is quite different. The LLM is not an agent. The LLM provides a reasoning engine, and nothing else. Everything else we build around that engine—the memory, the execution of tools, the planning capabilities, the routing of context, and the security boundaries—is the Agent Harness . Why an Agent Harness is Important If an LLM is the engine of a car, the harness represents the steering wheel, the brakes, the transmission, and the dashboard. When you give an agent access to your production database, cloud infrastructure, or private customer records, relying purely on the model's internal prompt instructions to keep it safe is insufficient. Models hallucinate, they are susceptible to adversarial inputs (like prompt injection), and they are inherently non-deterministic. If your only defense against a rogue action is a sentence in a system prompt that says "Do not drop the database," your system is not ready for production. A robust Agent Harness provides the deterministic guarantees that the non-deterministic LLM lacks. It acts as the application layer that securely wraps the model, governing exactly what context the model is allowed to see, what tools it is authorized to call, and what policies constrain its overall execution. The Architecture of an Enterprise Agent Harness In enterprise environments, defining a complete Agent Harness goes far beyond what a single developer can implement in an application codebase. A full-scale enterprise harness intersects with massive infrastructure components, such as: Cloud IAM (Identity and Access Management) Corporate Data

I keep a shelf. Rules I haven't earned the pain for yet go on it — because my own rule says a rule is born from an incident, not from someone else's "best practice." Import a rule you haven't bled for, and you'll be the first one to route around it. On the shelf sat a rule with its trigger condition written down, word for word: The first merged PR with a green DoD checklist and a flow that doesn't actually work. I put it there a couple of weeks ago, thinking "this'll come in handy someday." It came in handy two days after I published an article about this very method. The trigger fired. Word for word. What happened The PR merged. CI green. Every DoD box checked. And the flow didn't work — not for one second, not in a single real stack. Three bugs in a cascade, and every one of them invisible to CI by construction. One. A module read a JSON registry from a shared/ folder at import time, on app startup. Works in CI — full checkout there, shared/ is present. But the production image is built from a narrow context that doesn't include that folder. The container crash-looped on its very first start. And you know the best part? CI never ran the image at all. It ran the tests on the host. Green. Two. Two migrations merged the same day and got the same version. And the version is the primary key in the applied-migrations table. A local db reset died on the second row: duplicate key . Columns never got created. CI didn't see this one either — it runs migrations through a bare psql loop, no duplicate check. Three was just a consequence: no columns, endpoints return 500. Every check was honestly green. All three bugs would've been caught by one attempt from a live human to hit the endpoint on a running stand. One. The lesson, one paragraph Deterministic checks catch structure: the test file exists, the status is set, migrations are listed, the linter is clean. What they can't see, by construction, is whether the flow works in the stack where the product actually lives. Green C

Hello Im Turbo i Want To Develop A Graphical App With "OpenGL" And "C++" My App Is The Simulator Of Gravity For Using The OpenGL I Need To Learn "GLSL" Language Or No And I Can Write All Program With The "C++" Language ؟ ؟؟؟؟؟؟

📺 Prefer to watch? 90-second YouTube Short · 💬 Telegram Originally published on software-engineer-blog.com . You already know the trick: add "think step by step" to your prompt and the model's answer gets better. Almost nobody explains why — and the real reason has nothing to do with motivation or effort. Mental model: A transformer spends a fixed stack of layers per token, so adding reasoning tokens doesn't make the model smarter — it buys it more compute passes and an external scratchpad to read from. The Problem: Fixed Compute per Token Here's the floor. When a transformer generates a token, it runs through the same neural network layers every time. The stack depth is fixed at model-creation time. Whether you ask it "2+2" or "Sara has 3 packs of 8 markers, gives 5 to each of 4 friends, how many left?", the model gets the same amount of layered computation to produce each output token. That compute budget never grows with problem difficulty. Now imagine you ask for just the answer: "Sara has 3 packs of 8 markers, gives 5 to each of 4 friends, how many left? Answer only the number." The model has to solve a three-step problem (multiply 3 × 8 = 24, multiply 4 × 5 = 20, subtract 24 − 20 = 4) in a single forward pass. It needs to hold "24" and "20" somewhere while computing the final step. But it's only got one forward pass, one set of layer outputs, and nowhere internal to stash intermediate values. So it guesses. It might say 19. It didn't get the math wrong because it's bad at math. It got it wrong because you handed it the wrong compute budget for the job. The Mechanism: Three Small Shifts Now ask the same question and let it write the steps: "Sara has 3 packs of 8 markers, gives 5 to each of 4 friends, how many left? Think step by step." Three mechanical things happen: 1. The model becomes a loop. Every token the model emits is appended to the input context and fed back in on the next forward pass. So if it writes "First, 3 × 8 = 24", that token sequence gets rea

I wrote about the Electricity Planning Engine a little while back, including a timezone bug that made a correct price look "not found" after a database round trip. A few days later, Alex Shev left this comment: Timezone bugs are brutal in planning engines because the result can look mathematically correct while being operationally wrong. Energy workflows especially need tests around boundaries, not just averages. That is a genuinely sharp way to put it, and it is not just a comment about the bug I already wrote about. It is a comment about how I test the project in general, and I did not like how well it applied once I went and checked. The part that stung a little "Looks mathematically correct while being operationally wrong" is exactly what the original timezone bug was. PriceSeries::priceAt() threw a clean "price not found" error, which is arguably the good version of that failure mode: loud, easy to catch, hard to ship. A quieter version of the same class of mistake, off by one hour instead of missing entirely, would not throw anything. It would just return a plan that looks completely reasonable and is wrong the entire time it runs. Alex's second point, boundaries over averages, is the one I actually had to go check rather than just agree with in the abstract. So I opened tests/Unit/Domain/Contract/PricingStrategyTest.php and looked at every hour used in every peak/off-peak assertion: new DateTimeImmutable ( '2026-07-18 14:00:00' ) // peak new DateTimeImmutable ( '2026-07-18 23:00:00' ) // off-peak new DateTimeImmutable ( '2026-07-18 05:00:00' ) // off-peak 14:00, 23:00, 05:00. Every single one comfortably inside its window. None of them anywhere near the actual transition. The off-peak slot in the config is 22:00 to 06:00 , and the comparison behind that lives in TimeSlot::contains() : // wraparound slot, e.g. 22:00 -> 06:00 return $minuteOfDay >= $this -> startMinuteOfDay || $minuteOfDay < $this -> endMinuteOfDay ; That >= versus < is exactly the kind of one-

Herodotus wrote of a bird that lived five hundred years in Arabia, and when its life came to an end, it did not wait to be surprised by death. It built its own nest of cinnamon and myrrh, set the nest and itself alight, and let a new bird rise from what the fire left behind. The Hestia argued for tending a fire that must never go out. That’s true, and it isn’t the whole truth. Teams end. People leave. Companies get acquired, reorganized, shut down, and five years from now some part of this whole model will probably look as dated as the practices it was written to replace. No amount of tending prevents that. Pretending otherwise is its own kind of Alexandria , a slow decline dressed up as continuity, right up until the fire goes out anyway and nobody chose the moment. The bird in Herodotus doesn’t get caught by surprise. It builds the pyre itself. Chooses the moment, gathers what matters, and burns deliberately, trusting that what rises afterward carries the shape of what came before, not because the fire preserved the old bird whole, but because starting over was never the same thing as starting from nothing. That’s the part tending alone can’t promise. A team that’s about to be split up can hand its shared model to whoever inherits the work on purpose, the way a rep in the Boule carries a decision back instead of leaving it to travel however it happens to travel. A team about to lose its most experienced person can spend the weeks before that departure making sure the framing, not just the conclusions, made it into someone else’s head, the way the Mimesis argued a junior actually learns. None of that stops the ending. It decides what the ending leaves behind. This series doesn’t get to end with a fire that never goes out. Nothing does. It gets to end with the only thing actually inside anyone’s control. Build the pyre on purpose. Choose what goes into the fire. References The Myth of the Phoenix: Rebirth and Renewal : Greek Mythology, on Herodotus’s original accoun

There's a deceptively simple bug hiding in plain sight on almost every government form, university portal, and job application site: "Upload a photo under 50KB." No API, no error message explaining why, no tolerance — just silent rejection if you're 2KB over. It sounds like a trivial constraint until you actually try to satisfy it programmatically. File size in bytes isn't a variable you can set directly; it's a derived value — a function of pixel dimensions, image entropy, and compression quality — which makes "resize this to exactly 51,200 bytes" a surprisingly nontrivial optimization problem, not a one-line canvas.toBlob() call. A few months ago, my cousin ran into this on a state exam portal that capped passport photos at 50KB. She spent two hours bouncing between random "photo compressor" sites, most of which just apply a fixed compression ratio and let you deal with whatever number comes out. None of them actually solve for a target size. By the time she landed on something that worked, the registration window had closed for the day. So here's the actual technical problem underneath this UX annoyance — and how to solve it properly instead of guessing quality percentages by hand. It's Not You. File Size Is Genuinely Unpredictable. Here's the thing nobody tells you: file size in kilobytes isn't something you can just "set." It's the result of several things happening at once — how detailed the image is, what dimensions it's saved at, and how aggressively it's compressed. Change any one of those, and the final number shifts unpredictably. A plain white background compresses down to almost nothing. A busy, detailed photo — a face with visible texture, a signature with lots of fine ink strokes — resists compression much harder, because there's more actual information in the pixels. Two photos that look similarly sized on your screen can land at wildly different file sizes once compressed, simply because of what's in them. Then there's the format problem, which trip

Every few weeks I'd end up rewriting the same 10 things from scratch: rate limiter middleware, webhook signature check, retry-with-backoff, connection pool config. So I built AutoSnippets. 50 snippets across Python, JS, TS, Java, C#, C++, Go, PHP, Rust, and SQL. All production-ready, and even more are being made. Favorites of mine: Go channel-based worker pool (snippet #32) Rust Arc + Mutex safe counter (#41) SQL recursive CTE for org charts (#50) PHP RBAC in like 8 lines (#38) Free, no signup. Bookmark it if you find it useful.

AI-Driven Development: How Machine Learning is Reshaping Software Workflows in 2026 The software development landscape of 2026 looks almost unrecognizable compared to just a few years ago. Artificial intelligence has moved from being a novel assistant to a core pillar of the development workflow. Today, AI doesn't just autocomplete a line of code; it helps architect entire systems, automatically detects and fixes bugs before they reach production, and continuously learns from the organization's codebase to accelerate every phase of delivery. This article explores the key transformations and practical examples of how AI is reshaping software development in 2026. AI-Powered Code Generation and Completion By 2026, AI-powered code assistants have evolved far beyond simple autocomplete. Modern systems understand natural language requirements, project architecture, and even business logic. Developers can describe complex features in plain English, and the AI generates multi-file implementations, including dependency management, configuration, and tests. Example: Generating a REST API with AI A developer might request: "Create a FastAPI endpoint for user registration with email verification, rate limiting, and an asynchronous database call." The AI would produce: from fastapi import APIRouter , HTTPException , Depends from sqlalchemy.ext.asyncio import AsyncSession from app.database import get_async_session from app.models import User from app.schemas import UserCreate , UserResponse from app.services import create_user , send_verification_email from app.rate_limiter import rate_limit router = APIRouter ( prefix = " /auth " , tags = [ " auth " ]) @router.post ( " /register " , response_model = UserResponse ) @rate_limit ( max_requests = 5 , window_seconds = 60 ) async def register ( user_data : UserCreate , db : AsyncSession = Depends ( get_async_session )): existing_user = await User . find_by_email ( db , user_data . email ) if existing_user : raise HTTPException ( statu

Hey Techie 🌸 Before I continue my go series, I wanted to share a personal project that I'll be working on alongside my learning. What is IRIS? IRIS is an adaptive accessibility companion meant to help people with invisible disabilities navigate the media in ways preferable to them. Most websites and systems are one-size-fits-all and do not take user preferences into account in depth. The assumption is that every user views technology the same way, and that's not true at all. This is where IRIS shines her glory. The goal of creating IRIS is that it adapts to the user's needs rather than the user adapting to it. She will be able to personalise things like text-to-speech, colour themes, layouts, and other accessibility features based on their needs. As I continue learning Go and backend development, I'll also be sharing the progress of building IRIS, from designing the database and API to developing the backend and, eventually, the complete application. I look forward to sharing my progress and the challenges I will face and having discussions with you, my dear techie friends 🌸

A private company can release a flawed AI feature, roll it back, apologise, and move on. A government agency doesn't have that option. When AI is used to determine benefits eligibility, detect fraud, or prioritise citizen services, the consequences are much bigger. People affected by those decisions usually can't opt out, can't easily challenge the outcome, and can't switch to another provider. That's exactly why responsible AI in the public sector can't be treated as a compliance exercise added at the end of a project. It has to be built into the system from the very beginning. Having worked with public sector teams adopting AI frameworks, I've seen these discussions firsthand. Many conversations start with a simple question: Should this process be automated at all? In my experience, the biggest challenge isn't a lack of good intentions. Most teams genuinely want to improve services while protecting citizens. The real problem is that the development practices, delivery timelines, and engineering patterns that work well for consumer applications often don't translate to government systems. In the public sector, the person on the other side isn't just a customer using an app. They're a citizen whose access to essential services may depend on that decision, and in most cases, there isn't an alternative provider they can turn to. That's what makes building AI for government fundamentally different. Why Public Sector AI Is a Different Problem, Not a Harder Version of the Same One It's easy to think of government AI as enterprise AI with a few extra approval steps and a lot more paperwork. In reality, the differences run much deeper. In a commercial product, an inaccurate recommendation might mean a lost sale or a frustrated customer. In government, the consequences are far more significant. An incorrect decision could delay disability support, deny someone housing assistance, or wrongly flag an individual for fraud. The level of error that might be considered acceptable

When you need process orchestration — approval workflows, business rules, data pipelines — the usual answer is a heavyweight engine: BPMN 2.0 XML, database schemas, a management UI, and a framework that drags in half of enterprise Java. Solon Flow takes a different approach. It's a ~200KB engine that treats process definitions as flat YAML or JSON, runs without a database, and lets you resume interrupted processes from a JSON snapshot. You can embed it in any JVM framework — Solon, Spring Boot, Quarkus, or even a plain main() method. This article walks through the core API, node types, context persistence, and driver customization — all verified against the official documentation at solon.noear.org . Getting Started Add the dependency: <dependency> <groupId> org.noear </groupId> <artifactId> solon-flow </artifactId> </dependency> Define a flow in YAML ( flow/demo1.yml ): id : " c1" layout : - { id : " n1" , type : " start" , link : " n2" } - { id : " n2" , type : " activity" , link : " n3" , task : ' System.out.println("hello world!");' } - { id : " n3" , type : " end" } Load and execute: FlowEngine engine = FlowEngine . newInstance (); engine . load ( "classpath:flow/demo1.yml" ); engine . eval ( "c1" ); That's it. No database, no XML schema, no deployment step. In a Solon application, you can inject the engine directly and let it auto-load flow definitions: solon.flow : - " classpath:flow/*.yml" @Component public class DemoCom implements LifecycleBean { @Inject private FlowEngine flowEngine ; @Override public void start () throws Throwable { flowEngine . eval ( "c1" ); } } The engine scans all matching files on startup, so adding a new flow is just dropping a YAML file. Node Types Solon Flow supports seven node types via the NodeType enum: Type Description Task Condition Parallel In Out start Entry point — — — 0 1 activity Default node Yes — — 1..n 1..n exclusive Exclusive gateway (if/else) Yes Yes — 1..n 1..n inclusive Inclusive gateway (multi-select) Yes Yes — 1

Originally published on hexisteme notes . I was about to harden a new agent whose whole job is to turn "should I adopt this library, model, or tool" into a deterministic, auditable verdict instead of a vibe — gates, grades, falsifiers, a learning ledger. Before trusting it with that job, I wanted a design review nobody could dodge. My default pattern was "ask my main coding assistant to look it over," which has the same structural problem as a same-family writer reviewing its own writing: builder and checker share the same blind spots. So this time three roles — Questioner, Answerer, and adversarial Verifier — rotated through three reviewer groups in every possible assignment, across six rounds. Three roles into three groups is exactly six permutations, and I used all of them, so no group ever sat as the permanent judge. The setup: eight targets, six dimensions, three groups The system under review had eight discrete pieces worth judging, pulled from its own codebase rather than picked after the fact: identity and boundaries (what separates a verdict-making agent from a plain fact-gathering one), four type-level invariants blocking an unverified claim from being laundered into a confirmed fact, five deterministic scoring gates that only score fact-labeled evidence, the grade decision and hard-gate demotion logic built on those gates, automatic derivation of the conditions that would prove a verdict wrong, a provenance parser with a host whitelist for fact-grade sources, a learning ledger checking whether its own confidence is honestly calibrated, and the CLI/bus/config surface a human touches. Each got judged on six dimensions: interesting to judge, useful downstream, complete against its own spec, coherent with its docs and siblings, reliable — reproducible, tested, falsifiable — and actually serving the system's purpose. Going in: eight open verdicts on record, zero recorded outcomes, 677 lines of tests. Zero outcomes matters more than it sounds — a learning ledge

Every time I wanted to paste a whole project into Claude or ChatGPT, I ended up guessing whether it would even fit — and often found out the hard way, mid-conversation, that it didn't. So I built Tokenazire, a small CLI tool that solves exactly that. What it does Scans a local folder or a GitHub repo (just pass the URL, it clones it for you) Counts tokens per file using tiktoken (the same tokenizer OpenAI models use, a solid approximation across most LLMs) Shows a color-coded breakdown (green → yellow → orange → red) so you instantly see which files are "heavy" Calculates what percentage of a model's context window (default 200k, configurable) your whole project takes up Ignores .git, venv, node_modules, and other noise automatically Has an --export flag that bundles the entire project — folder structure plus every file's content — into a single text file, ready to paste straight into an LLM chat I kept hitting the same annoying loop: copy a project into a chat, get cut off or told the input's too long, then manually trim files and try again. This automates the "will it fit, and if not, what's taking up the most space" question up front. The --export step came later — once I knew what would fit, I still had to manually copy-paste files one by one into the chat. Now it just spits out one clean file with a project tree on top and clearly separated file contents, ready to paste. Tech stack Plain Python, tiktoken for tokenization, rich for the terminal output (tables, colors, progress bar). No config files, no external services beyond git for cloning. Try it Repo: https://github.com/DeKlain4ik/token-counter (MIT licensed) Still early — feedback, issues, and PRs are welcome.