I Built My Own Claude Code

Amar Kumar Thakur
5 min read · October 2026

I built my very own Claude Code.

That is what CleoCode is to me.

It started as a personal challenge. I wanted to see if I could take a complex idea from a rough sketch all the way to working software without a team behind me.

Months later, CleoCode is a live terminal coding agent that I actually use and continue improving every week.

I Wanted to Build the Hard Thing

For a long time, I believed serious developer tools were only possible for large teams.

Real coding agents with memory, authentication, billing, streaming, saved sessions, and everything else that makes a product feel complete seemed out of reach for a solo builder.

I kept telling myself to stay small.

Build a wrapper.

Ship something simple.

Do not try to build the complicated system.

Eventually, I decided to ignore that voice and build the hard thing anyway.

That decision became CleoCode.

What CleoCode Does

CleoCode is intentionally simple for the person using it.

You stay in your terminal, open a chat, and keep coding without constantly switching between different tools.

You can switch between GPT and Claude with one command when you want a different model to approach the problem.

You can start in Plan mode when you want to think through a problem before making changes, then switch to Build mode when you are ready to actually work on the code.

Your sessions are saved, so you can leave and come back without losing the context of what you were doing.

You can also check your usage, log in once, and upgrade without leaving the terminal workflow.

From the outside, this feels simple.

Building that simplicity was anything but simple.

The Hardest Part

The hardest part of CleoCode was not getting a model to generate code.

The difficult part was making all the systems work together.

I had to figure out how streaming, authentication, billing, saved history, sessions, and the actual coding workflow could stay in sync without breaking in the middle of a run.

When you are building alone, there is nobody else to hand a bug to.

If something breaks, you have to understand it.

If the architecture is wrong, you have to rebuild it.

If you shipped something too early, you have to fix it.

That process taught me more than any single feature I built.

It showed me that I could design, build, debug, and maintain a complete system from end to end.

One Mistake Changed the Architecture

One of the biggest lessons came from something I initially thought was the correct approach.

I built all of the tools on the server side.

At first, the architecture made sense.

Then I saw what it did to the actual user experience.

The server should never have direct access to the users files in the way I had designed it.

The architecture had to change.

I moved tool execution to the client side inside the CLI and redesigned the system around that separation.

That rebuild made the system cleaner, safer, and faster for the person using it.

It was also a reminder that a working architecture is not necessarily a good architecture.

Sometimes you have to build something, see where it breaks, and then be willing to throw part of it away.

Building Alone Changes How You Think

Working on CleoCode alone has also changed how I approach building products.

When you have a team, you can divide problems.

Someone can work on the frontend.

Someone else can handle the backend.

Another person can investigate infrastructure.

As a solo builder, all of those problems eventually come back to you.

That can be frustrating.

But it also forces you to understand the entire system.

You start thinking about how one decision affects everything else.

A change in authentication can affect billing.

A change in streaming can affect sessions.

A change in the CLI can affect the backend.

A small architectural decision can eventually become a major product decision.

That has been one of the most valuable parts of building CleoCode.

What Comes Next

The next version is about giving users more control and more clarity.

One of the features I want to add is live cost information for every session.

You should be able to see what you are spending while you use the product instead of finding out later.

I also want users to be able to bring their own API key and use their own limits.

Another goal is allowing users to connect the AI plans they already pay for instead of forcing them into another completely separate workflow.

At the same time, I am continuing to work on the core system itself.

Faster execution.

Better reliability.

Safer tool handling.

More stable sessions.

A better experience for people who want to use an AI coding agent every day.

Why Open Source?

CleoCode is still early.

It is not a finished product.

There are things that will break.

There are things that can be designed better.

There are features that I have not even thought about yet.

That is exactly why I want other developers to use it.

Try it.

Break it.

Open an issue.

Send a pull request.

Tell me what makes no sense.

Tell me what you would build differently.

Or simply star the repository if the idea speaks to you.

The project is open source because I want the next version to be shaped by more than just my own perspective.

The Stack Behind It

CleoCode is built around a fairly focused stack.

The model layer supports OpenAI and Claude.

Billing is handled through Polar.

The terminal interface is built with OpenTUI.

The core uses Bun, Hono, Clerk, and Prisma.

The technology matters, but the bigger lesson for me has been learning how all of these pieces fit together into one product.

That is the part I wanted to prove to myself.

What I Wanted to Prove

I built the first version of CleoCode alone to prove something to myself.

I wanted to know whether I could take an idea that looked too complicated, break it down, make the architectural decisions, write the code, fix the mistakes, and eventually turn it into something people could actually use.

Now I know I can.

That does not mean the product is finished.

It means I have a much better idea of what I am capable of building.

And that changes what I want to build next.

Build It Anyway

There will always be a reason not to build something.

You do not have a team.

You do not have enough money.

The architecture looks too complicated.

Someone else already built it.

You are not experienced enough.

I had all of those thoughts while building CleoCode.

The difference was that I eventually decided to build it anyway.

CleoCode is still early, but it is real.

It runs in my terminal.

I use it.

I keep improving it.

And now I want other developers to shape what it becomes.

I built the first version alone to prove what I can design.

I want to build the next version with all of you.

CleoCode is open source. Try it, break it, contribute to it, and help shape what comes next.

Project: CleoCode

Repository: GitHub