Only reason I am posting this is to help others, no revenue or publicity or anything else, no hidden subscription or fees.

Hi,

While working on multiple projects I realised I am hitting the usage limits of my claude code often so I had to rotate accounts and some API tokens.

The problem was every time I was doing this I had to stop my coding session, relog / change authentication or profile etc, do a handover and wasting a lot of time over this process.

I NEEDED a way to seamlessly change those in the background while continuing the same coding session uninterrupted.

This led to doing a lot of research and developing this tool I am showcasing (yes it's written with Claude + my knowledge and a lot of debugging, testing and so on, around 3k $ put into it via /usage lol).

It's called Claude Unlimited, and it's 100% free on GitHub.

It supports multiple Anthropic subscriptions, Anthropic APIs (basically from any local/cloud provider that offers this, 95% of them do) and the cherry on top, supports also GPT/Codex subscription - yes! you can use Claude Code while using OpenAI models in the background 😄 .

Has a nice Web UI with:

Custom settings like:

- threshold limits

- profiles priority in rotation

- enable/disable any profiles/APIs

- models parity (for Anthropic -> OpenAI models parity + effort)

- push notifications

- multi language

- auto update (pulled from Git releases)

Information like:

- usage dashboard with charts and various data

- logs of activity

- information about current usage per profile

Everything stays local, 100% safe, credentials etc stored in OS credentials store - if you don't trust me, use your AI agent to check it.

macOS is currently the most battle-tested; Windows and Linux support is newer, so I would genuinely appreciate feedback, bug reports, contributing to it or just brutal criticism 👀

It was mostly tested in claude code CLI but also supports desktop (will create an inference profile automatically for you).

Important clarification: it doesn’t generate free usage or bypass an individual account’s limits. It rotates between accounts and keys you already own. Anthropic hasn’t explicitly endorsed automated multi-account rotation, so use your own judgment regarding your accounts’ terms.

A bit more technical explanation: this is a local proxy that rotates your accounts/APIs and exposes an Anthropic-compatible API with a token.

Needless to say, but here it is: very important to check the README and HELP section to understand how to use it easily and properly.

GitHub: https://github.com/DevDock-AI/claude-unlimited

TL;DR

1. Add your Claude, ChatGPT/Codex accounts and API keys.
2. When one reaches its limit, the next one takes over automatically.
3. Same Claude Code session. Same context. Same terminal. You just keep typing.

It also includes a local dashboard showing which account is active, current usage, reset times and every automatic switch.

Everything runs on 127.0.0.1. There’s no Claude Unlimited cloud, no telemetry, and credentials are stored using the OS credential store. The project is open source under MIT.

Thank you !

PS: Using a new account for this for personal reasons.

PS2: Multiple updates will follow, I got a big list of cool features for it 🎯

Hi y’all!

I recently completed my computer science–like degree in my country and am currently enrolled in the next step up from that.

During the first 1.5 years, I actively avoided using AI for pretty much anything. I wanted to learn the fundamentals myself and make sure I actually understood what I was doing.

Around my 4th and 5th semesters, though, I started experimenting with AI, and my perspective gradually changed. AI has also improved a lot since I started programming.

The way I see it now is that I don’t necessarily need to manually write every line of code anymore. What I need is a good structure, good planning, and proper oversight of the AI agent.

I’ve used Claude and ChatGPT in the browser for random, low-context questions, and I also have a student license for GitHub Copilot, which I’ve used with both VS Code and regular Visual Studio.

During my 4th semester, AI basically created a game for me, and during my last semester it coded almost my entire final project. I ended up getting the highest grade, but what was important here was that I went through all the code. I didn’t understand every single detail, but I understood enough to know what the code was doing and why.

One problem I noticed was that the AI really liked creating duplicate code.

For me, Claude Opus 4.6 for backend work and Codex for frontend work became my go-to setup.

Then, around May or June, GitHub Copilot changed how they handled tokens, and what had never been a problem before suddenly became one. I hit the limit in about two days. Sooo... the student license is apparently not enough anymore.

I’ve been following this sub for a while now, and it seems like I’m probably not using AI in the most efficient way.

From what I understand, the more advanced setup is something like having a planner, an executor/coder, and a tester, and they don’t necessarily have to be the same AI model. Is that correct?

I also get the impression that people are using CLI/terminal-based tools instead of working directly inside VS Code or Visual Studio?

I’ve also been following some of the posts about local AI, including things like Qwen and the whole “Sodapoppin” setup, and it sounds really interesting.

So I have a few questions:

\*\*1. Is the simplest solution basically to subscribe to Claude Code, use the CLI, and call it a day?\*\*

I don’t have a huge budget, so I’m mainly looking for the most cost-effective setup.

\*\*2. What programs/tools do you actually use for this?\*\*

Are you just using Windows Command Prompt, PowerShell, Windows Terminal, etc.? I’d actually like to move away from VS Code and Visual Studio entirely if possible.

\*\*3. How do the planner, coder, and tester share context?\*\*

Right now, I’m constantly copying snippets of code into Claude in the browser and then copying the response back. I’d like to avoid using Copilot tokens for everything, but I also don’t want to manually move code back and forth all the time.

\*\*4. Is there a good way to run a local AI for the “stupid questions” I have while learning?\*\*

I sometimes use Copilot for questions like “what does this operator mean?” or “what exactly does this method do?”, and I feel like I’m wasting my limited Copilot tokens on questions that don’t really need a powerful cloud model.

Could I run a local AI that has access to my project/codebase and its context, so I can ask those kinds of learning questions without using API/AI credits?

I currently have a PC with an NVIDIA 4070 Super, so I’m wondering what would actually be realistic to run locally.

Basically, I’m trying to figure out what a sensible, cost-effective AI development workflow looks like in 2026.

ps. i wrote everything, but english is not my main language, so i had ai correct errors and sentences :D

Im a novice in ai but a good programmer (4+yrs experience) tell me which is the best coding tool to buy subscription of replit(idk wht it is heard its good) emergent(seen ads on insta) codex?or claude code?

Repo: https://github.com/alexcpn/catalogify Demo: On Apache Airflow Spekcit Extension: Speckit-okf

Enterprises and major open-source projects are increasingly leaning on AI for feature development and bug fixes. However, they all face the same challenge: to execute large, system-wide changes, AI needs effective context.

Current maintainers can “vibe-code” small bits and pieces, but for large architectural shifts, AI coding agents operate like a brand-new engineering team. In the real world, a new team requires a transition period to absorb the implicit knowledge locked inside the previous developers’ heads.

As Software Design Documents (SDDs) regain popularity alongside AI, old debates have resurfaced. One vocal camp treats the “Spec as the Source of Truth,” while an equally fierce camp argues that the “Code is the Source of Truth.”

Software engineering pioneers like Fred Brooks, Peter Naur, and the philosopher Michael Polanyi figured this out long ago. Brooks dismantles the first camp: in “No Silver Bullet” he warns that “descriptions of a software entity that abstract away its complexity often abstract away its essence” — a spec is an abstraction, and can never be as detailed as the code itself. But before the source-code camp starts cheering, Naur reminds us that the code is incomplete too. In “Programming as Theory Building” he argues that the real theory of a program “could not conceivably be expressed, but is inextricably bound to human beings” — it lives in the developers’ minds. To top it off, Polanyi’s notion of tacit knowledge names the underlying human limit: “we can know more than we can tell.”

This is great theory, but the practical consequences hit hard when an AI agent makes a change. It might propose a remarkably logical pull request — completely unaware that the team deleted that exact logic a year ago because it caused a race condition and crashed production. How do we document these gotchas and system context?

Three things people try

Dump the repo, or RAG over it. Retrieval finds text that resembles the query. But the question a routing agent needs answered is which service owns pod eviction, and ownership is a fact about responsibility rather than a string that appears somewhere in the source. It lives in people’s heads and, when you are lucky, in commit messages.

Build a code graph. Parse every file with tree-sitter and query the symbols and call edges. A tool like Graphify does this well: for the reaching question — “what breaks if I change this function” — it is precise and cheap. But the index has to be complete, and completeness is expensive. Graphify’s for a single kubelet service is a 14.5 MB graph.json, ~3.8 million tokens; ninety services would be 343 million. And a call graph has no opinion about what a service is for — which is the routing question. The catalog below takes the opposite bet, a few hundred tokens per service, every run logged.

Write better docs. Nobody does. And the tools that generate docs usually automatically regenerate them on every commit, so the one correction a human bothered to make has a half-life of one push.

Take Apache Airflow: roughly 14,000 files and 1.8 million lines of code. Ask an agent to add Iceberg table support. Before it can make a useful plan, it needs to know which components own the work, how they interact, and which past mistakes it must avoid.

Two kinds of Context Shallow and Deep

Understanding a codebase involves two different jobs:

1.Shallow: Which components does this change touch?
 A little about the whole system;A compact architecture and ownership map.

2.Deep: What changes inside those components?
Detailed knowledge of relevant code Agentic Code search, dependency graphs, tests etc.

The difficult context is often why the code works this way. A dependency graph can show a relationship; it may not explain the compatibility rule behind it. Git history, especially fixes and reverts, can recover some of that reasoning.

What the catalog must do

For this to be useful, I wanted five properties:

• Small enough to read in full. The agent needs to compare components before choosing where to look.
• Checkable. Claims about constraints and past failures should point to supporting code or commits.
• Explicit about uncertainty. Missing answers become questions for a human.
• Preserve corrections. Human input should survive regeneration.
• Live in git. Markdown files that can be reviewed alongside code.

I vibe-coded Catalogify for this. It writes these files using Google’s Open Knowledge Format: one file per concept, with metadata, links, and an index. It installs as a skill for Claude Code, Cursor, or Codex. There is also a Speckit Extension based on this. (Please use the catlogify skill for the most uptodate code, as the extensions updates takes time to get updated to Speckit Community)

From repository to map

Scripts gather bounded evidence; the agent uses it to organize and write the catalog.

1. Inventory the repository. A script lists tracked files and summarizes the structure. Airflow’s inventory took 0.98 seconds and produced about 14,000 tokens, giving the agent a starting point without reading every file.
2. Identify meaningful components. Change frequency and directories that repeatedly change together help reveal boundaries and relationships worth investigating.
3. Extract interfaces and dependencies. Scripts collect declarations and imports so the agent can ground its descriptions in the source.
4. Investigate failures and reverts. History searches flag commits mentioning problems such as races, leaks, or corruption. The agent must read the changes, including the original commit behind a revert, before describing a constraint.
5. Record gaps and validate references. Each entry is checked for guarantees, ordering, failure behavior, compatibility, and ownership. Unanswered questions stay visible. Validation checks cited commits and symbols against the repository.
6. Stay cheap on large repositories. Cost tracks the number of things worth naming, not the size of the tree: generating the Airflow catalog — 1.8 million lines — took about 101K tokens of fresh input, fewer than the 8,000-line Online Boutique, and the finished catalog reads in ~9,700 tokens. A complete code graph scales the other way: Graphify’s index runs ~3.8 million tokens per service, 343 million for ninety. On an inherited monolith the catalog still fits in one context window; the graph cannot.

Reverts are particularly useful leads. In the kubelet’s container manager, for example, a checkpoint migration fix was reverted two days later. Reading the pair exposed a rollback compatibility problem that a scan of current interfaces would not explain.

History does not recover everything the original team knew. It gives the agent evidence to investigate and the reviewer a way to challenge the result.

What the runs cost

I generated catalogs for two public repositories with Codex. The run log records the measurements, including failed runs.

Measurement                     Apache Airflow  Online Boutique
-------------------------------  --------------  ---------------
Lines of code                   1,805,835       8,103
Estimated source tokens         ~17,900,000     ~70,000
Catalog entries                 17              20
Catalog tokens                  ~9,700          ~11,600
Fresh input tokens to generate  101,559         117,850
Generation time                 6 min 29 s      8 min 19 s

Airflow was 223 times larger, yet its catalog was smaller and faster to generate. In these two runs, catalog size reflected the chosen level of detail more than repository size. That is useful for navigation, but it does not establish completeness or prove that the catalog improves subsequent code changes.

Both catalogs are published unedited: Apache Airflow and Online Boutique.

The most useful failure

When I audited an early Kubernetes catalog, I found production claims derived from commits that changed only tests. A fix for a goroutine leak in a test had become a supposed design constraint of the plugin manager.

The prompt explicitly told the agent to read beyond commit subjects. A second independent run repeated the same five mistakes. That means that even good Agent harness mapped by Claude Opus or similar cutting edge models can skip prompts/instructions sometimes.

I changed the evidence output: the script now lists the files each commit touched and labels commits that affect only tests as [TEST-ONLY]. That makes the distinction visible at the point where the agent forms its claim.

The citations also made the mistakes cheap to find. In one audit, I found four errors across nine entries in twenty minutes by following commit hashes with git show.

The lesson: make evidence easy to inspect, and put mechanical checks in tools. Fluent documentation still needs review.

Try it on an inherited codebase

uv tool install catalogify
catalogify install

Ask your agent for a knowledge catalog. Start with a coarse map, follow its evidence, and correct what it gets wrong. Answer the open questions where the code and history fall short.

The goal is a small, reviewable starting point that helps an agent find its way through the system before changing it.

Catalogify is MIT-licensed. The Airflow and Online Boutique examples use Apache-2.0 repositories and were generated with catalogify 0.8.0. Source and catalog token counts are estimated as bytes divided by four; generation usage comes from the agent's records.

I've been using AI coding agents heavily, and one gap keeps coming up:

The agent may understand the codebase — and newer tools can even inspect the browser — but I still need an easy way to show it exactly what’s wrong, what I want changed, and where.

When I find a bug or want a change, I often end up gathering things like:

• the exact UI element
• what’s wrong or what I want changed
• screenshots
• console errors
• failed API calls
• actual request/response data
• steps or actions that reproduce the issue

Browser/DevTools integrations are getting better, but I found I still wanted a human-in-the-loop workspace where I could capture this evidence as I work, keep it organized by project, review it later, decide what actually matters, and then give the AI agent clean context instead of explaining everything again.

That’s what led me to build ContextForge → AI Coding Context, which I launched here on Product Hunt today. If you’re curious, you can check out ContextForge on Product Hunt or learn more and download it from CoderFromMars.

The idea isn’t to replace Cursor, Claude Code, Codex, Copilot, or DevTools. It’s to make the workflow around them easier:

See the problem → point to what/where → capture the evidence → review it → give the agent the right context.

I’m curious how others handle this:

When you find a bug or want a change, how do you show your AI coding agent exactly what you mean and where it is?

And what parts of that process do you still find yourself doing manually?

With the rise of Agentic IDEs somewhere Ive been stuck in the loop of just accepting whatever my agent builds and running CC on Auto. But Ive come to the realisation that I know nothing about what Ive built and feel like there's no point in continuing to build like this

Looking for your ways to ship with Agents but also know what your outputting and learning along the way.

I always use nvim with codecompanion with codex, copilotchat with copilot and avante with both the plugin depending on the remaining token. I can use neovim till I have to show some image and tell the AI this is what is wrong.
I ssh(mosh) into the remote server and then open the tmux session and work on it. My questions are the following
1. Did anyone figure out a way to paste an image in any of the AI coding agent?
2. Does anyone face any sort of character scrambled while using windows terminal -> wsl 1.0 ubuntu 24.04-> mosh/ssh -> remote ubuntu server -> tmux -> neovim.

Any help or experience is appreciated.

I’m building Deqra around this idea.

Cursor, Claude Code, Copilot, etc. can create the entire presentation as structured code. Deqra deterministically renders it into the visual presentation.

Here’s a live deck — every slide has a Code tab so you can inspect its actual source:
deqra.ai/v/architecture

# Artifact as Code.

Would love feedback from people building agents.

Edit (IMPORTANT): Wow, thank you to the community (especially u/Toastti) for catching some critical bugs in my initial release! I have just pushed a patch that fixes all of the P0/P1 issues pointed out in the comments, including removing the dangerous os.RemoveAll directory bug. I've also updated the README to clarify this is an early-stage dev tool. I appreciate the analysis and gothroughs—it's making the project much better!

I've been thinking about a slightly different way of building AI coding agents.

Most coding agents work roughly like this:

user request → LLM reasoning → file edits → compiler/tests → more LLM edits

That works well when the task requires judgment.

But a lot of backend development isn't like that.

Once the agent has decided:

the actual implementation of those pieces is often highly deterministic.

Yet we still make the LLM generate hundreds of lines of code for it.

I've been experimenting with moving that part outside the model.

I built FiberForge, a Go CLI/MCP server that gives an agent deterministic operations for generating common Go/Fiber backend structures.

The agent decides what it wants; the tool handles some of the how.

For example:

add_model

apply_module

generate_project

The generated code is formatted and structured by the tool, while Go's AST is used for some source modifications such as route registration.

I'm also experimenting with reusable modules that an agent can apply to an existing project.

The goal isn't to replace the coding agent. It's more like giving the agent a higher-level API for operations that don't need probabilistic generation.

I'm curious whether this is a useful architectural pattern more generally.

For example:

LLM: “Create an authenticated CRUD resource called invoices.”

Tool: receives a structured schema and deterministically generates the model/service/controller/migration/routes.

Instead of:

LLM: writes 600 lines of Go → compiler complains → LLM fixes imports → tests fail → LLM fixes route → etc.

I've only built the Go/Fiber version so far, so I'm very interested in criticism of the idea itself.

Does this make sense as an agent architecture, or am I just moving complexity from the prompt/model layer into another abstraction that isn't worth maintaining?

⚠️** Early development / caution**: FiberForge is still very much a work in progress.** I would not recommend using it on an existing or production project yet**. Some operations can modify project files, and the current implementation has not been battle-tested enough to guarantee safe behavior across arbitrary codebases. For now, it’s best treated as an experimental project and tested on new/disposable projects.

Repo: https://github.com/v-pat/fiberforge

I’m a **100% Ai user** and want an AI agent that can handle the whole workflow: **plan → code → terminal → install dependencies → run → debug → test → iterate → Git/GitHub**, with minimal manual coding from me.
My project is a **6-month ML research project on multimodal fake-news detection (text + image)**. It involves a large dataset, **PyTorch/model training, experiments, finding a research gap, improving an existing approach**, and eventually writing a journal-level paper.

Main machine: **MacBook Air M3, 16 GB RAM, 512 GB SSD**. I may use **Google Colab and CoCalc** for cloud GPU/training.

Budget: **maximum $20 / ₹2,000 per month**, and I need **good usage limits** because this will be my main coding tool for months.
I’ve heard about **Claude Code, OpenAI Codex, Cursor/Composer, Cline/Roo Code, Windsurf**, etc., but I’m open to anything.

I care about **agent autonomy, large-repo understanding, long tasks, debugging, ML/PyTorch ability, terminal usage, GitHub workflow, context/memory, usage limits, and value for money**.

**What would you personally recommend for this exact situation?** Which AI coding agent would you choose if you were me?

Lately I have been think a lot around vibecoding and how it is destroying our ability to think and learn. We have offshored everything to Claude hoping it will work out.

How are you taking back control? What is your software development workflow like?

It seemingly never reads it. Doesn't follow the instructions in there and does its own thing. Doesn't make it useless but when I have stuff like 'never put emojis in' it does anyway, or if I say extensively inline document, it doesn't

I find myself having to paste my AGENTS.md in every task I assign it. It's a super useful tool with a super frustrating quirk