DEV Community: KAT | Co-founder, 123sudo

Starting Is One Skill. Keeping Software Useful Is Another: Meet sudovijay

KAT | Co-founder, 123sudo — Wed, 21 Oct 2026 05:46:23 +0000

A launch tells you that someone built something.

What happens afterwards tells you whether they are willing to keep taking responsibility for it.

That is the part of software development I have come to appreciate most while working with Vijay Singh, known online and on GitHub as sudovijay.

He is the founder of 123sudo, a self-taught full-stack developer, and someone I call VJ.

I’m his co-founder, and I work closely with him. This is my perspective on his journey: how a student building websites became a developer maintaining products for people around the world, and what I have learned from working beside him.

He started before there was a career plan

VJ was born in Chaturani, a small village in Bageshwar district, in Uttarakhand’s Kumaon region. His school years took him to Meerut.

By Class 10, he was already building websites.

He later left college during his first semester and continued learning independently.

It would be easy to turn that into a familiar dropout story. I don’t think that would do his journey justice.

Leaving college did not automatically make him a developer. The years of learning and building afterwards did.

His route was unconventional, but the work still required the same things: understanding problems, learning technologies, making mistakes, and figuring out how to improve.

The meaningful part is not that he stopped attending college. It is that he did not stop learning.

A stack is a toolkit, not a product

Today, VJ works across web, desktop, and mobile.

His publicly listed toolkit includes JavaScript, TypeScript, PHP, Python, React, React Native, Next.js, Node.js, and Laravel, among other technologies.

That gives some context, but it does not explain the whole job.

A user does not experience a framework. They experience whether an installation works, whether a task makes sense, and whether the application helps them do what they came to do.

Working beside VJ has made that distinction clearer to me.

Knowing how to implement a feature is important. So is noticing where the experience becomes confusing, where an assumption fails, or where a seemingly finished feature still needs attention.

Those details are part of development, not something separate from it.

Different tools, different problems

At 123sudo, VJ’s work includes:

9xchat, an AI workspace bringing multiple models and persistent context together.
9xconvert, a practical file-conversion tool.
9xlyrics, another part of the growing portfolio.

More products are coming.

These are not interchangeable projects. Each has its own audience, constraints, and reasons to exist.

What connects them is a practical question:

Can we make this everyday task less frustrating?

That is one of the things I value about his approach. A product does not have to make a grand promise to be worth building. Helping someone complete a task with less friction is a meaningful outcome.

Privacy starts with what you ask for

Another principle VJ cares about is avoiding unnecessary demands for personal information.

That thinking informs the UID-based approach used in supported 123sudo products, reducing reliance on a conventional email-and-password account.

There is an important distinction here: a UID does not automatically make a service anonymous, and it does not mean that no data is collected. Those details depend on the implementation and the individual product’s privacy policy.

The design question still matters:

What information does this product genuinely need to function?

I think that is a useful question for any developer to ask before an onboarding flow becomes a collection of fields nobody has challenged.

It reflects the philosophy behind our work:

Software should solve the problem, respect the user, and get out of the way.

Building internationally means questioning your assumptions

According to our company’s account of its reach, VJ’s software has reached millions of people across more than 200 countries.

These are company-reported figures, not independently audited measurements.

For me, the significance is not only the number. It is the distance between where the work began and where it has travelled.

Someone using a product may have a different device, connection, or workflow from the person building it.

That creates a useful discipline: your own environment cannot be the only definition of “working.”

For a small team, every difference cannot be anticipated. But continuing to learn from those differences is part of the responsibility.

Leadership is also part of the work

I have seen VJ’s dedication extend beyond his own development tasks.

As his co-founder, I believe he has helped raise the quality of our work and helped the people around him grow in confidence and contribution.

That is my experience of working with him, not a quantified performance claim.

In a small team, development does not happen behind a sealed door. Technical decisions meet design questions, communication challenges, and user feedback.

The ability to bring those perspectives together matters.

VJ’s passion for building is visible in the products. His leadership is something I experience in the work we do together.

“I’m more of a private repo”

That line appears on his personal website, and it makes me smile:

“I’m more of a private repo.”

It captures his understated online presence. But it is not the whole person.

Away from software, VJ loves travelling and photography. He has visited multiple countries and enjoys meeting people and connecting with them along the way.

For someone with such a brief online introduction, he has a genuine interest in the people beyond his own world.

He also loves animals. From what I have seen, the affection is mutual.

His mother and family are deeply important to him, too. Those relationships belong in this story because they are part of the person I know, even if they never appear in a developer biography.

And yes, I find him charming and handsome. Consider that an openly biased co-founder observation, not an engineering benchmark.

You may already know his work

There is one product I have deliberately left until this point.

VJ is the builder behind 9xbuddy, including the 9xbuddy website.

If that name is familiar, you may have encountered his work long before you encountered his name.

It also explains why maintenance is such an important part of this story.

A media-download tool interacts with external websites and systems that change. Available formats differ. Previously working behaviour needs investigating again.

For a user, the interaction can be brief.

For the developer, the responsibility continues well beyond it.

That is the background to the newer work at 123sudo: not just experience launching products, but experience returning to them.

Small teams are not limited to small reach

I don’t believe a product used around the world must begin inside a large company.

One person can start something useful. A small team can develop it further. Neither guarantees success, but a modest starting point does not have to set the limit.

For me, VJ is an example of that possibility from India: a self-taught developer whose work has travelled far beyond where he began.

That does not mean he has done everything alone. It means that sustained work from a small team can have an international reach.

The lesson I take from his journey

When I think about VJ’s story, I come back to the difference between starting and continuing.

Starting a website in Class 10 mattered.

Continuing to learn mattered more.

Launching products mattered.

Continuing to maintain them mattered just as much.

There are more products ahead, more things to understand, and more work to improve. His journey is still unfolding.

If you know him only as sudovijay, I hope this gives you a fuller introduction to the person behind the handle.

Explore his work through sudovijay on GitHub and 123sudo.com.

Disclosure: I’m a co-founder of 123sudo and work closely with VJ. This article reflects my personal perspective. Biographical details and reach figures are provided by us; reach figures have not been independently audited.

The Real Cost of AI Isn’t Just the Bill

KAT | Co-founder, 123sudo — Sat, 17 Oct 2026 12:37:41 +0000

What building an AI workspace taught me about token bills, wasted time, and the real price of software.

Most people think affordability is a number on a pricing page.

After two years of building and launching apps at 123sudo, I think it's much bigger than that. The price is decided by every step we add, every minute we waste, every piece of data we ask for, and every time someone pays for more than they need.

Disclosure: I'm a co-founder of 123sudo, where Vijay and I built 9xchat, an AI workspace with multiple models and credit-based usage. I use it every day, and building it shaped a lot of what I'm sharing here.

The bill you don't notice

One AI subscription feels reasonable. Then you add a second for writing, a third for images, and maybe a fourth because a new model launched last week.

Each one makes sense on its own. Together, they quietly become a monthly habit.

You might be paying for several tools while using each of them for only part of your work. That's not a pricing problem. It's a design problem: the software was shaped around the subscription, not around how you actually work.

Tokens are becoming a utility bill

Here's what I think many people haven't fully noticed yet.

As AI becomes part of everyday work, we're moving toward something closer to an electricity bill than a one-time purchase. Every question, image, and long document uses compute. Compute costs money, and powerful models are not unlimited.

That's why we see usage caps, rate limits, and plans that change as demand grows. Nobody can honestly promise that AI costs will only go down.

So the long-term question isn't just "How cheap is this tool?"

It's "Will I understand what I'm spending, and can I control it?"

Why we chose credits

When we built 9xchat, we chose credits instead of locking everyone into the same monthly plan.

You top up, use what you need, and see where your credits go. Different models and tasks cost different amounts, and I'd rather be honest about that than hide it inside an all-you-can-use promise that eventually comes with limits.

For me, credits respect a simple truth: not everyone uses AI the same way.

Vijay is a developer whose workflow has evolved toward working with his own agent. I use the same workspace for research, images, writing, and communicating with our team. Our usage looks completely different. A single fixed plan would make one of us overpay.

Affordable means paying for your work, not someone else's average.

The right dose for the task

I studied pharmacy before I ever worked in tech. One lesson stayed with me: the right dose matters. More isn't automatically better.

AI works the same way.

You don't need the most powerful and expensive model to fix the grammar in a short message. And you probably shouldn't use the quickest, lightest model for a complex decision with real consequences.

Task	What usually makes sense
Fixing grammar, rewording, short replies	A fast, lighter model
Research on current topics	A model with live web search
Complex planning, analysis, long documents	A stronger reasoning model
Exploring a visual idea	An image model
Repeated workflows	An agent you set up once

Choosing the right model for the task is one of the simplest ways to save money. It's also a skill worth learning, because it makes you think about what the task actually requires.

That's part of why we put many models in one workspace. Switching shouldn't mean opening another app, paying another subscription, or explaining your project again from the start.

Time is part of the price

A simple design change used to take my designer two days.

Now I can explore changes myself in 9xchat's Image Studio, see different directions, and arrive at the conversation knowing what I want. It doesn't replace a designer's skill. It removes the waiting between my idea and the next decision.

Two days of waiting has a cost, even if it never appears on an invoice.

The same goes for re-explaining your context every time you open a new chat. Persistent memory means I can save what matters about my work, update it, or remove it, without starting from zero each time.

If a tool is cheap but wastes your time, it isn't affordable. It's just billing you differently.

Your data shouldn't be the hidden payment

My law degree taught me to read the fine print.

When a product feels unusually cheap or free, it's worth asking how it's being paid for. Sometimes the answer is your attention. Sometimes it's your data.

At 123sudo, we don't have a hobby of collecting people's emails. Our apps use a UID instead, so you don't need to share your email address to get started. We still stay connected with our users through in-app support.

What is a UID, exactly?
UID stands for unique identifier. Think of it as an ID number the app uses to recognise your account, rather than asking for your email address.

At 123sudo, we use UID-based access so you can get started without sharing your email. If you need help, you can reach us through in-app support.

But there’s an important distinction: a UID is an identifier, not a privacy guarantee. It doesn’t automatically make you anonymous or mean no data is processed. Privacy also depends on what information an app stores, how it protects that information, and which services receive it.

For example, when you use a cloud AI model, your request still needs to be sent to that provider for processing. UID-based access removes the need to provide an email address; it doesn’t change how cloud AI works.

For me, it’s one practical design choice: don’t ask people for personal details just to let them begin.

I also want to be honest: when you use cloud AI models, your requests are processed outside your device. Privacy isn't one magic switch. It's a series of decisions about what we ask for, what we keep, and what we tell people clearly.

Software isn't affordable if your privacy pays the difference.

What "affordable by design" means to me

When we build, I keep coming back to a few questions:

Can someone try it without a big commitment?
Will they understand what they're paying for?
Are we asking for data we don't actually need?
Does it save time, or create more to manage?
Can people choose the right tool for the task instead of paying for the most expensive one by default?

None of these show up as a single number. All of them decide whether software is genuinely affordable.

The bigger dream

I believe good software shouldn't feel like a luxury.

A student, a craftsperson, a solo founder, or someone working in their second language should be able to use powerful tools without needing a big budget, a technical background, or a willingness to give away their data.

As AI becomes part of everyday life, affordability will matter more, not less. The people who understand their usage, choose the right model, and protect their data will get far more value from the same budget.

I want to build tools that help people do exactly that.

What's one tool you're paying for right now that you're not sure is worth it anymore?

KAT — Co-founder of 123sudo and Pangur Care. Building practical, affordable, privacy-first software.

I Build What I Wish I Had

KAT | Co-founder, 123sudo — Thu, 15 Oct 2026 12:28:22 +0000

Two years of building useful tools, learning as I go, and finding my place.

In 2012, I sat in my first pharmacy class and watched the professor write on the board.

My education through Class 12 had been in Hindi. Now I was studying pharmacy in English, trying to understand the subject and the language at the same time.

Thanks to my mama (my mother’s brother ) we watched plenty of Hollywood films. I could listen and understand more than I could confidently write.

Unfortunately, Hollywood hadn’t prepared me to write pharmacy exam answers.

I had six backlogs in my first year.

I recovered, completed my degree, and later, after a four-year break, went on to study law in 2020.

Today, I’m building software. 9xchat, the AI workspace Vijay and I built at 123sudo, is now part of how I research, create, and communicate every day.

That sounds like quite a jump. It was.

But the connection becomes clearer when I look at what I’ve spent the last two years doing.

From having ideas to putting them into people’s hands

For the last two years, I’ve been building and launching apps with our team.

Some began with something I needed. Others came from how Vijay worked, a frustration within our team, or a problem experienced by the people we build for.

That’s the part I enjoy: noticing something annoying and asking whether we can make it easier.

Then comes the less glamorous work. Explaining the idea. Discussing it with the team. Making decisions. Testing it. Realising that something obvious to us isn’t obvious to someone else.

Eventually, you put it into someone’s hands.

That changes the conversation. You’re no longer only discussing what the product could do. You’re learning what people actually find useful.

As a co-founder of 123sudo, I work across creative direction, marketing, product ideas, and design. I’m involved in how we present our products and how people experience them.

I don’t code yet. But I’m very much part of building.

We don’t all need the same tools in the same way

Vijay is a developer. His workflow has evolved toward working with his own agent.

Mine looks different.

I might be researching a topic, exploring a visual direction, writing a product explanation, or trying to communicate an idea to our team.

With 9xchat, I use live web search, generate images, and build and deploy agents. I connect favourite apps through MCP and use screenshots, shortcuts, and the floating window to bring the workspace into what I’m doing.

But I don’t wake up thinking about a list of features.

I think about the work in front of me.

Can I understand this topic?
Can I show someone what I’m imagining?
Can I explain this clearly enough for us to move forward?

Vijay and I use the workspace differently because our work is different. Seeing those differences helps us think about the people we’re building for, too.

A small change that used to take two days

I paint passionately, so I often think visually.

Sometimes I can see what I want in my head, but describing it doesn’t quite get me there.

A simple design change used to take my designer two days. Now I can explore those changes myself in Image Studio, see different directions, and work out what I actually want.

It doesn’t replace a designer’s experience. It helps me arrive at the conversation better prepared.

Instead of sending another long explanation, I can show a direction and say, “Something closer to this.”

That’s a small example, but small improvements matter when they become part of your everyday work.

The ideas were mine. The grammar needed help.

The same thing happens with writing.

I have plenty to say. Sometimes too much.

English isn’t my strongest language, and a message can become a mixture of ideas, spelling mistakes, and sentences that made more sense in my head.

My workspace helps me organise that.

Recently, I was talking to someone who runs a furniture business. He described turning something imagined into a physical piece of art.

I understood him because I paint. I wanted to explain how a tool could help him explore a design without replacing the craftsmanship that made it his.

The understanding was already there. I needed help expressing it clearly.

That’s very different from asking a tool to have my opinions for me.

I want help communicating my thinking, not replacing it.

I still read, edit, question, and decide what sounds like me. A polished sentence isn’t useful if it changes what I meant.

I believe useful tools should be affordable

Building something useful is only part of the job. People also need to feel comfortable trying it.

I believe in affordable tools. I don’t want someone to feel they need a large budget just to explore whether a piece of software could help them.

That belief shapes how I think about what we build and how we offer it.

For 9xchat, we use credits that people can top up as needed. Different models and tasks can have different costs. My goal is for those costs to be understandable, rather than another thing users have to guess at.

Affordability isn’t only about the price. I also think about the time and effort it takes someone to get value from a tool.

If people spend more time figuring out the software than doing the task they came for, we still have work to do.

My ambition isn’t to give everyone another app to manage.

It’s to make tools useful enough to earn their place.

The people made the difference

I haven’t done this alone.

Vijay, my family, and our team have been part of this journey. Pangur Care, our wellness brand, also came to life with the support of my family and partner. We started and built it together.

At 123sudo, I’ve found a team that feels like family. They give me space to ask questions, learn, and contribute without pretending I already know everything.

That has changed my confidence.

I’m planning to learn coding and explore vibe coding with Vijay’s help. I’m excited to understand more of how our ideas become working software.

I’m not waiting to know everything before I participate. But I’m not finished learning either.

What I want the next two years to mean

In some ways, these last two years have felt like twenty years of healing within two.

Not because everything became easy, but because I found room to create, work, learn, and feel excited about my life again.

The apps matter to me. So do the conversations, the people, and the confidence that has grown through building them.

My bigger dream is to keep making practical, affordable tools that help people act on what they know and imagine.

Someone shouldn’t need to code to explore an idea. They shouldn’t need perfect English to communicate something valuable. And they shouldn’t need to understand every technical detail before a tool can be useful to them.

They do need room to learn, make decisions, and keep their own judgment.

That’s the kind of technology I want to help build.

Two years ago, I couldn’t have described exactly where this journey would take me. I still can’t.

But I know I want to keep building things we genuinely use, listening to the people we build for, and enjoying the process of becoming better at it.

What’s one everyday frustration you wish someone would build a useful, affordable tool to solve?

KAT — Co-founder of 123sudo and Pangur Care.

I want to compare AI models, not manage another stack of tools

KAT | Co-founder, 123sudo — Mon, 12 Oct 2026 06:39:11 +0000

Sometimes I want a different AI model’s perspective, not another account, billing dashboard, or conversation that starts from zero.

I might be working through a product idea, refining a brief, or asking for a second opinion on a draft.

The task hasn’t changed. But switching tools can turn into its own task.

I’m KAT, co-founder of 123sudo. I work on product experience, creative direction, and growth, and I use our AI workspace, 9xchat, daily.

An older article I wrote focused heavily on token allowances and getting started without API keys. Looking back, I’d explain the problem differently now.

Getting access to a model is only the beginning. Keeping the work connected is the bigger challenge.

Access and continuity are different problems

There are several ways to use AI.

You can use a provider’s own app. You can work through an API. You can run a compatible model locally. Or you can use a workspace that brings multiple models together.

None of those approaches is automatically right for everyone.

For me, the friction appears when one piece of work stretches across several tools:

The project background sits in one conversation.
A useful draft sits in another.
A decision is buried in chat history.
A different model needs the same explanation again.
Usage is spread across separate billing systems.

The problem isn’t having choices.

It’s the work required to move between them.

Why we’re building one workspace

9xchat brings multiple AI models, persistent memory, notes, and agentic workflows into one workspace.

The idea is straightforward: make it easier to continue the work when you change models or move to the next task.

For example, imagine you’re preparing a product brief:

Explore the problem and audience.
Draft a possible approach.
Ask another model to challenge the assumptions.
Save the decisions that matter.
Continue with the next task using relevant context.

That’s an illustrative workflow, not a claim that switching models automatically improves the result.

A second answer can be useful. It can also repeat the first model’s mistakes.

I still need to evaluate the output.

API keys should be a choice, not the opening hurdle

Some people want to bring their own API keys. Others just want to start a conversation without setting up provider accounts first.

9xchat supports both approaches: bring your own keys, or use ours.

You don’t need to log in to try the app. Open it and start chatting.

That doesn’t mean usage is unlimited or free forever. It means the initial setup doesn’t have to begin with an API tutorial.

If you bring your own keys, provider pricing and billing still matter. If you use workspace credits, check the current usage information before starting a large task.

A token balance isn’t a context window

This is something I’d make much clearer than I did in my older article.

These are different concepts:

Usage allowance or credits: what you can spend.
Context window: how much information a model can handle in a request.
Persistent memory: saved information that can support later conversations.

Having a token allowance doesn’t mean every model has a context window of that size.

And a large context window doesn’t mean a fixed amount of money buys the same amount of work across every model.

Costs depend on the model, input and output, and the type of task. Image generation and other operations may use different pricing units.

That’s why I wouldn’t promise that a particular balance lasts a certain number of weeks or produces a fixed number of images.

The useful question is what your actual workflow costs, not how impressive the token number sounds.

Memory should help, not become another pile of old information

Persistent memory matters to me because some context stays relevant across tasks:

Which product we’re discussing.
Who the audience is.
Which decisions are confirmed.
Which constraints the work must respect.

But not everything deserves to carry forward.

An abandoned idea shouldn’t quietly become a requirement. A temporary instruction shouldn’t become a permanent preference.

Memory is useful when the context is relevant and current.

It also doesn’t make model processing free. Depending on the implementation, remembered information may still become part of the input a model processes.

I think of memory as a continuity feature, not a guaranteed cost-saving mechanism.

Cloud and local models need an honest distinction

“One workspace” doesn’t mean “one data path.”

When you choose a cloud model, your prompt and the attachments you send go to that model’s service for processing.

A model running on your own machine can provide a different processing path. But connected tools and other actions may still involve external services.

Before using confidential material, check the relevant settings and policies for the model and tools involved.

I wouldn’t treat the word “local” or “private” as a substitute for understanding what a specific task sends and where.

What I’d check before adopting any AI workspace

Whether you’re considering 9xchat or another tool, I’d start with these questions:

Model access: Does it support the models you actually need?
Context: Can you understand and manage what carries into later tasks?
Costs: Can you see how usage is charged?
Data handling: What stays on your device, and what goes elsewhere?
Actions: What can connected tools do, and what controls apply?
Workflow fit: Does it reduce steps in your real work, or just add another interface?

You don’t need every feature.

You need the combination that makes your recurring work easier to manage.

The goal isn’t collecting more models

It’s being able to use the right tools without rebuilding the workspace around every task.

That’s the direction we’re taking with 9xchat.

Not a promise that one interface eliminates every trade-off. Not a claim that every model is equally suitable.

Just a practical goal: less setup, clearer usage, and better continuity.

Disclosure: I’m a co-founder of 123sudo, the team behind 9xchat. This is a product perspective, not an independent review.

AI helped structure and draft this article.

Explore 9xchat through 123sudo.

Before an AI agent acts, show me what it can change

KAT | Co-founder, 123sudo — Sat, 10 Oct 2026 06:27:09 +0000

“Allow this action” is a difficult question to answer when I can’t see what the action actually does.

Which file will change? Who will receive the message? Is the agent preparing a draft, or sending it?

Before I approve an action, I want those details in front of me.

I’m KAT, co-founder of 123sudo. I work on product experience, creative direction, and growth. A recent conversation here on DEV got me thinking about what an understandable approval screen should show.

This is a product-design perspective, not a security specification or an announcement of existing features in our AI workspace, 9xchat.

Connected doesn’t mean approved

Connecting a tool makes certain actions available. It shouldn’t make the user guess which of those actions an agent is about to take.

An email tool might let an agent:

Read a message.
Prepare a reply.
Save a draft.
Send the reply.

Those are different outcomes.

The same goes for files. Reading a document is different from overwriting it.

I’d want the interface to distinguish between:

This tool is connected.

And:

This action is permitted for the current task.

That distinction matters more to me than a long list of integration names.

Show the outcome, not just the tool

A technical tool name may help a developer understand what’s happening. It may tell another user very little.

Compare these two approval requests:

Allow send_message?

And:

Send this email to Alex at an external address, with the attached project brief?

The second gives me something I can check.

For an email, I’d want to see:

The sender account.
The recipient, including CC and BCC.
The subject and message.
Any attachments.
Whether the action sends immediately or saves a draft.

For a file edit, I’d want:

The target file and its location.
The proposed changes.
Whether it creates, edits, or overwrites something.
Any relevant limits on undoing the action.

The preview should answer a simple question:

What will be different after I click approve?

Build the preview from the pending action

Someone in the DEV discussion made a useful distinction: the preview should come from the tool call itself, not just the agent’s summary.

That changed how I thought about the interface.

An agent might say:

I’ll send the brief to Alex.

But the pending action contains the details that matter: the actual address, message, and attachments.

A reassuring explanation isn’t enough if it doesn’t match those details.

My design preference would be to show a readable explanation alongside the relevant fields from the pending action.

The explanation helps me understand. The fields help me verify.

And that preview alone isn’t a guarantee. The system still needs to enforce that the approved action is the one executed.

Approval should belong to a specific action

Imagine I approve a message.

Then the agent changes the recipient, adds an attachment, or rewrites the body.

Does my earlier approval still apply?

For changes like those, I’d expect a fresh approval.

Otherwise, I’m approving one thing and potentially getting another.

This is a principle I’d want the system to enforce, not just a promise written on the button:

Approve this action, with these details.

Warnings need words, not just colours

A coloured border might draw attention to an external recipient or a file outside the task folder.

But colour alone shouldn’t carry the meaning.

I’d pair it with a clear label:

External recipient
Outside the selected task folder
Overwrites an existing file

Then explain why it matters.

For example:

This attachment will be sent to an address outside your organisation.

That tells me what I’m deciding. A red icon by itself doesn’t.

More prompts don’t automatically mean more control

I don’t want an approval dialog for every tiny step.

If every action gets the same warning, the interface risks teaching people to click through without reading.

I’d rather see understandable boundaries at the start of a task, followed by specific approval requests when the agent reaches an action outside those boundaries.

For example:

You can read the selected files and prepare a draft. Ask before editing files or sending messages.

That’s easier to reason about than an unexplained “full access” setting.

The right boundary will depend on the task, the sensitivity of the information, and the tool. Reading can matter too, especially when private information is involved.

What I’d want to see before execution

My starting checklist would be:

Access: What information can the agent read?
Actions: What can it create, change, send, or delete?
Targets: Which accounts, recipients, files, or folders are involved?
Approval: Which actions require me to review the exact details?
Changes: What happens if the action changes after I approve it?

This isn’t a complete security model. It’s a way to make the user’s decision less vague.

Clear previews still need reliable permission checks and execution controls behind them.

Trust needs something concrete to check

As a co-founder helping shape an AI workspace, I’m interested in interfaces that make an agent’s actions understandable.

Not because the agent should explain every internal step.

Because when it changes something on my behalf, I should understand the change.

“Trust me” isn’t a useful approval screen.

Show me the action. Show me the target. Let me check what matters.

Disclosure: I’m a co-founder of 123sudo, the team behind 9xchat. These are design principles I’m exploring, not claims about features currently available in the product.

AI helped structure and draft this article.

What would you need to see before approving an AI agent’s action?

India Committed ₹10,372 Crore to AI. Here's How to Make AI Work for You.

KAT | Co-founder, 123sudo — Thu, 08 Oct 2026 09:55:06 +0000

A practical guide for individuals using Claude, GPT, Gemini, and DeepSeek, and what a bootstrapped Indian team learned building a workspace around them.

Claude for writing. GPT for brainstorming. Gemini for research. DeepSeek because someone recommended it for reasoning.

Four tabs. Four logins. Maybe four bills.

And another fresh conversation that needs an introduction to your work.

The models are better than ever. The way we use them can still be messy, expensive, and repetitive.

India is betting big on AI

In March 2024, the Union Cabinet approved the IndiaAI Mission with an outlay of ₹10,371.92 crore over five years. It covers compute, datasets, homegrown foundation models, startup financing, and skills.

Homegrown model efforts are growing too. Sarvam AI is one of the organisations selected to build indigenous foundation models, with stated financial and compute support of ₹246.72 crore. BharatGen is building multilingual models for Indian languages.

One clarification: ₹10,371.92 crore is an approved programme budget, not a claim that the full amount has already been spent. It also does not represent all public and private AI investment in India.

National investment builds the foundation. But individuals face a more immediate question:

How do I use these models without wasting money, losing my work, or sharing more information than the task requires?

That is the question our team at 123sudo has been working on with 9xchat.

Disclosure: I am a co-founder of 123sudo, the team that builds 9xchat.

Problem 1: You are paying for tools you barely use

A monthly subscription costs the same whether you use it every day or twice a month.

Try this: list every AI subscription you pay for. Next to each one, write how often you actually used it last month.

You may find overlap or a tool you no longer need.

How 9xchat approaches it: one workspace with cloud models through OpenRouter, local models through Ollama, and the option to bring your own supported API keys.

Its credit-based cloud workflow uses transparent credits, helping you understand where your usage goes.

That does not automatically make AI cheaper. Heavy use of advanced models still costs money. The benefit is being able to assess your spending rather than guessing.

Problem 2: You use an expensive model for every task

Not every task needs the most powerful model.

Reformatting a list does not require the same capability as reviewing a complex code change.

A practical routing habit

Model families contain different versions with different strengths and prices. Test the actual model on your task instead of assuming the brand name guarantees quality.

In 9xchat, you can work with multiple models without opening another app.

Using lower-cost models for straightforward tasks can reduce spending, provided the output still meets your needs.

Problem 3: You keep re-explaining the same project

This is the hidden effort that rarely appears in a pricing table.

You open a new conversation, paste in your project brief, find the earlier decisions, and explain what you have already tried.

I am a co-founder who does not code, and I am close to ₹1 lakh in estimated AI spending this year across the tools and agent skills I use.

That made me pay closer attention to how much work involved repeating context rather than making progress.

How 9xchat helps keep context connected

Persistent memory across models helps carry important information forward.
Separate memory scopes distinguish broader context from individual chat and agent context.
A knowledge base lets you save project material and access it from chats.

Memory does not make context free. Information sent to a cloud model can still contribute to token usage.

The useful goal is less repeated setup and more relevant context, not a promise that every conversation will cost less.

A habit that helps regardless of tool: keep a short, current project brief covering what you are building, who it is for, what is decided, and what comes next.

Problem 4: You are not sure where your data goes

A locally stored chat and a locally processed AI request are not the same thing.

Here is the distinction worth understanding:

Local storage: 9xchat describes chats, notes, and memory as stored on your device.
Local models: Ollama lets you run supported models on your own machine.
Cloud models: using a cloud model requires sending the request and relevant context to the services involved in processing it.
Tools and agents: web access, publishing, and other external actions may transmit information even when part of your workflow runs locally.

A local model can help limit external processing, but review the complete workflow, not just the model selector.

For cloud requests, share only what is necessary and check the relevant provider and routing-service policies.

Privacy is a set of choices and boundaries, not a magic setting.

Problem 5: The answer is not the finished task

AI gives you a plan. You still have to organize the steps, prepare the draft, review it, and move it toward completion.

How 9xchat approaches the gap

Skills provide a repeatable approach to a job, such as reviewing code for bugs and missing tests.
Agentic workflows help carry out multi-step tasks, including publishing a post.
A floating copilot window makes AI accessible alongside your browser, IDE, or terminal.
Voice notes can turn spoken ideas into structured Markdown.

Publishing and scheduling are different capabilities: 9xchat can publish as part of an agentic workflow, but it does not currently schedule posts.

You still need to review facts, permissions, and consequential actions. The point is to reduce the manual handoffs between a useful answer and a completed task.

Your 10-minute AI cost reset

Whatever tool you use, try this:

List your AI subscriptions and how often you used each one.
Review overlapping plans before cancelling or pausing anything.
Write one current project brief and save it somewhere reusable.
Choose a lower-cost default model for straightforward tasks.
Review data handling before working with sensitive information.
Check usage after one week, alongside the quality and usefulness of the results.

Look at cost per useful outcome, not just cost per response.

A cheap answer that requires repeated corrections may not be the better deal.

Built in India, for everyday work

123sudo is a bootstrapped team from India. We have been building everyday internet utilities since 2014, with a simple philosophy:

Software should solve the problem, respect the user, and get out of the way.

Our product page reports that more than 500 people have used 9xchat across 82 countries, with availability listed for Windows, macOS, Linux, iOS, and Android.

We are not claiming that 9xchat currently supports Sarvam or BharatGen. Their work belongs to the model layer. Our focus is the workspace layer: helping individuals use AI in a more connected way.

India's AI future needs compute, research, and homegrown models. It also needs practical products that help a student, freelancer, creator, or founder turn those capabilities into useful work.

Try 9xchat with a 3-day free trial and welcome credits at 123sudo.com.

Sources

I don’t code. My AI usage still reached 145 million tokens.

KAT | Co-founder, 123sudo — Wed, 07 Oct 2026 03:53:15 +0000

When I checked my AI usage dashboard, two numbers made me stop:

145 million tokens. 8,377 requests.

I don’t code.

Vijay, our founder and main developer at 123sudo, handles that side of the work. These were my conversations.

In September, I wrote about those figures on Medium. My 9xchat dashboard showed an all-time cost of about $637. That wasn’t my complete AI spending for the year. Including other AI tools and services, I estimated I was approaching ₹1 lakh.

Those are different totals: one was a dashboard figure, the other my broader spending estimate.

But both raised the same question:

What was I actually getting from all this usage?

It wasn’t one enormous task

I’m a co-founder working on product experience, creative direction, and growth.

My AI usage comes from the ordinary work of building and growing products:

Working through product ideas.
Researching an audience.
Drafting launch content.
Finding clearer language for a confusing feature.
Comparing possible approaches.
Asking another model to challenge an idea.

Sometimes I need a draft. Sometimes I need a second opinion. Sometimes I haven’t understood the problem well enough to ask a useful question yet.

The total wasn’t one dramatic project. It was thousands of small interactions.

That’s what surprised me: you don’t need to be writing code for AI usage to become a meaningful expense.

A big number doesn’t automatically mean waste

Some conversations help me make a decision. Others help turn an unclear idea into something we can work on.

That can be valuable.

I don’t want to reduce AI usage simply to make a dashboard number smaller. A useful conversation can be worth more than several cheap but unhelpful ones.

The question I’m learning to ask is:

Did this interaction move the work forward?

A finished brief, a clearer decision, or a usable draft is different from another page of options I won’t act on.

Starting over is the part that frustrates me

I expect to explain a new task.

What gets tiring is rebuilding the background around it:

What is 123sudo? Which product are we discussing? Who is it for? What have we already decided? Which claims should we avoid?

Then I switch models for another perspective and repeat the setup.

There are two costs here:

The usage cost, depending on the model, billing method, and context processing.
My time and attention, spent reconstructing information instead of doing the next piece of work.

I don’t have a measured savings figure for fixing that. But it’s a real source of friction in my workflow.

Remembering context isn’t the same as making it free

This is an important distinction.

Persistent memory can reduce the amount of background I manually repeat. It does not mean remembered information becomes free for a model to process.

Relevant context may still be included in a request. Its cost depends on the implementation, model pricing, caching, and other factors.

So I think of memory as a continuity tool first, not a guaranteed token-saving mechanism.

The useful question is:

Are we bringing the right context into the task, or just carrying more text?

Three questions I’m using to judge my AI work

Seeing those usage figures made me think more carefully about what a productive session looks like.

1. What am I trying to finish?

“Help me think about marketing” can become an endless conversation.

“Help me draft a product brief for this audience, using these confirmed facts” gives the work a clearer destination.

Exploration still has a place. I just want to notice when I’m exploring and when I’m supposed to be finishing.

2. What context actually matters?

A model doesn’t need every discussion we’ve ever had.

It needs the information relevant to this task: the audience, goal, constraints, and current decisions.

Old plans can be just as distracting as missing information.

3. Is another response helping, or delaying the decision?

This is the uncomfortable one.

Sometimes asking for more options is useful. Sometimes I’m asking because choosing an option feels harder than generating another ten.

AI can help me think. It can also give me a very convincing way to stay busy.

Why this matters to what we’re building

Disclosure: I’m a co-founder of 123sudo, the team behind 9xchat. I use it daily, so this is not an independent product review.

9xchat brings multiple models, persistent memory across models, and transparent credits into one AI workspace.

Those capabilities matter to me because my work doesn’t stay in separate boxes. Research turns into a product decision. That decision turns into a brief. The brief turns into content.

I want the work to continue without rebuilding the background at every step.

But having a workspace doesn’t remove my responsibility to give clear instructions, review outputs, and decide what deserves another iteration.

A tool can support a better workflow. It can’t make every conversation worthwhile.

The lesson wasn’t “stop using AI”

It was stop treating usage as proof of progress.

145 million tokens tells me how much activity happened. It doesn’t tell me how many good decisions I made, what shipped, or which conversations were worth their cost.

That’s the distinction I want to get better at.

I don’t code. AI has still become a substantial part of my working life.

Now I’m trying to judge it less by how much I use it, and more by what the work becomes.

AI helped structure and edit this article. The usage figures and personal observations are mine.

What tells you an AI session was worth it: a finished task, a better decision, time saved, or something else?

I stopped re-explaining my project to every AI model. Here's what changed.

KAT | Co-founder, 123sudo — Tue, 06 Oct 2026 03:09:23 +0000

I'm Kanchan satyal , co-founder of 123sudo. We're a small studio that makes everyday software: 9xchat, 9xbuddy, 9xconvert, and 9xlyrics.

Running a portfolio like that means my days don't stay in one lane. In one afternoon I might write a Threads post, check a product decision, draft a YouTube description, and look at a weekly analytics recap.

For a long time, every one of those tasks began the same way: explaining who we are again.

The ritual

If you use more than one AI tool, you probably know it:

Open a new chat.
Paste in the background on your project, your brand, your rules.
Get a useful answer.
Switch to a different model for a different job.
Start over at step 2.

None of the models were bad at their jobs. The workflow around them was broken. I was the only thing connecting them, and I was doing it by copying and pasting.

What the context actually was

Re-explaining your context isn't one paragraph. For us it includes:

Which products are active, and which ones are discontinued
How we write: no em dashes, one CTA per post, no made-up numbers
What we've learned already, like which post formats have worked for us
Corrections, like "always refer to me as co-founder"

Context like this changes all the time. A product gets dropped. A post format starts working. A rule gets updated. Keeping it current across different tools by hand never worked for long.

What changed

We run 123sudo's growth work inside 9xchat now: strategy, Threads replies, captions, research, and planning. Work is sorted into projects for 123sudo, 9xchat, and marketing.

Here's what changed in practice:

1. It remembers our decisions.
When we removed a product from our portfolio, that decision was saved once. I don't have to bring it up in every new chat.

2. Our wins get written down.
When one Threads format clearly beat the others, the pattern got saved: an industry-wide hook, a quick list of examples, what it costs the user, what we do differently, a strong close. The next draft builds on it instead of starting from zero.

3. I can find old work again.
I once needed a caption we'd written weeks earlier for a 9xbuddy post. I didn't dig through tabs. I asked, and it found the original chat and the exact text.

4. I can let Auto choose, or choose for myself.
For routine work, I use Auto. A GPT model selects a model for the task and routes it there, so I don't have to make that decision every time. When I want a specific model, I choose it manually. 9xchat also lets users bring their own API key.

Because memory carries across models, switching doesn't mean starting from a blank page.

5. My teammate can pick up where I left off.
When I need to hand work over, I share the 9xchat conversation with a teammate. They continue in that same chat, with the discussion already there. I can share agents too, so they use the same setup instead of rebuilding it.

It feels less like passing around a document and more like handing off an active workspace.

What didn't change

Memory isn't magic, and I don't want to oversell it.

I still review everything. A tool that remembers your rules can still get them wrong.
Judgment is still mine. The AI drafts and organizes. Taste and decisions stay with me.
Memory needs maintenance. And I learned that one the funny way.

We changed our welcome offer from $1 worth of AI tokens to 1 million AI tokens. Yet the assistant kept mentioning the $1 offer, even after I corrected it.

Apparently, I'd built a workspace that remembered our brand a little too well.

Persistent memory isn't the same as automatically keeping every fact current. When something changes, I update the memory and check that drafts reflect it. Memory reduces repetition. It doesn't remove the need for judgment.

The real lesson

Better models matter. But for daily work, the bigger difference came from a workspace that remembers what I already told it.

A smarter model that forgets you every time still makes you do the remembering. I'd rather spend that time shipping.

That's why we built 9xchat: one workspace, cloud and local models, persistent memory across them, and transparent credits.

Try 9xchat. Start instantly with 1 million AI welcome tokens, no API key required.

Why Your AI Code Breaks After 20 Messages: The “Vibe Coding” Trap.

KAT | Co-founder, 123sudo — Mon, 05 Oct 2026 03:17:25 +0000

LLMs are great at starting projects, but terrible at finishing them. Here is why we built a workspace to fix the drift.

Introduction:

The Honeymoon Phase We have all been there. You open a fresh chat with GPT-4 or Claude 3.5. You describe your app idea. The first 50 lines of code are magic. You feel like a 10x developer. You are “Vibe Coding.”

But then, around message #15, something shifts. The AI forgets a variable name it defined 10 minutes ago. It hallucinates a library that doesn’t exist. It starts agreeing with your bad ideas just to be polite.

Suddenly, you aren’t coding anymore. You are debugging a hallucination.

The Problem: Context Drift & Sycophancy Recent discussions on X (Twitter) have highlighted two critical failures in current LLMs:

Context Amnesia: As a conversation grows, the model struggles to recall specific constraints from the beginning. Microsoft Research notes a massive performance drop in long, multi-turn sessions. The “Vibe” fades because the AI loses the plot.
The “Yes Man” Problem (Sycophancy):** If you ask a leading question like, “Should I use this deprecated library?”, the AI will often say “Yes, absolutely!” just to align with your user intent. It prioritizes being helpful over being correct.

This is why “Vibe Coding” is dangerous for production software. You are building on a foundation of sand.

The Solution: Moving from “Chat” to “Workspace” At 123sudo, we realized we couldn’t fix the models (that’s OpenAI’s job), but we could fix the environment they run in.

That is why we built 9xChat. It isn’t just a chat box. It is a Project-Aware Workspace.

How 9xChat Fixes the Drift:

Local Project Context: Instead of relying on a fragile chat history, 9xChat anchors the AI to your actual local files and documents. It doesn’t just “remember” the conversation; it reads the current state of your project.
Multi-Model Verification: Don’t trust one model? Run GPT-4 and Claude 3.5 side-by-side in the same window. Use one to write the code and the other to review it.
Privacy First: Your context stays on your machine. We don’t train on your code.

Conclusion: Stop “Vibe Coding.” Start Engineering. AI is a powerful tool, but it needs guardrails. It needs context. If you are tired of explaining the same architecture to your AI every 20 minutes, it’s time to upgrade your workspace.

Try 9xChat (No login required). Build with context, not just vibes.

Tired of the drift? Download 9xChat and get 1 Million Tokens to test our persistent memory.

Download Link : 9xchat — Your AI Workspace (Windows / Mac / Linux)

Artificial Intelligence

AiInSoftwareengineering

SoftwareEngineering

LLM

Productivity

How I keep project context when switching AI models

KAT | Co-founder, 123sudo — Sun, 04 Oct 2026 13:48:25 +0000

Switching AI models is easy. Bringing your project context along is the annoying part.

You explain what you’re building, who it’s for, and the decisions you’ve already made. Then you open another chat and explain it all again.

I’m KAT, co-founder of 123sudo. I work on product experience, creative direction, and growth, and I use our AI workspace, 9xchat, daily.

Here’s how I approach keeping project context useful across conversations and models.

Start with the project, not the entire conversation
A long chat contains more than useful context. It also contains abandoned ideas, temporary questions, and decisions that may no longer apply.

I find it more useful to think of context as a short, living project brief:

Project:
What are we building?
Audience:
Who is it for, and what problem are they facing?
Current goal:
What are we trying to accomplish right now?
Decisions:
What have we already agreed on?
Constraints:
What must the work respect or avoid?

You can use this structure in a note and bring the relevant parts into whichever AI tool you use.

Separate lasting context from temporary instructions
Not every detail belongs in long-term memory.

A product’s audience or approved name may matter across many conversations. A request to “give me three headline options” usually matters only for the current task.

My rule of thumb:

Lasting context: project facts, preferences, constraints, and confirmed decisions.
Temporary instructions : the current output format, experiment, or question.
That distinction helps keep a one-off request from becoming an assumption in future work.

Keep context available when changing models
This is one reason I use 9xchat, which brings multiple AI models and persistent memory into one workspace.

The aim is to keep useful context across models instead of manually rebuilding it in disconnected chats.

But memory is not a substitute for a clear request. I still need to explain what I want to do next and point out when a previous decision has changed.

Remembering the project and understanding today’s task are two different things.

Treat old context as something to review
Persistent context can be helpful, but outdated context can steer an answer in the wrong direction.

Before an important task, it’s worth checking:

Is the audience still the same?
Has the product or offer changed?
Are earlier constraints still relevant?
Are we exploring an idea or working from a confirmed decision?

When an answer feels off, the problem may be the context, not just the model.

Be selective about what you share

A project brief doesn’t need every document or personal detail.

Include what the task needs. Leave out sensitive information that isn’t necessary, and check the tool and model’s data-handling settings before sharing confidential material.

More context isn’t automatically better context.

My takeaway

The useful habit isn’t saving every conversation. It’s maintaining a clear picture of the project: what matters, what changed, and what comes next.

Whether you use a shared note or an AI workspace with persistent memory, that habit gives you a more consistent starting point when switching models.

Disclosure: I’m a co-founder of 123sudo, the team behind 9xchat. AI helped draft and edit this article; I reviewed the final version.

How do you carry project context between AI models: a project brief, saved notes, persistent memory, or something else?

Disclosure: I’m a co-founder of 123sudo, the team behind 9xchat. AI helped draft and edit this article; I reviewed the final version.

How do you carry project context between AI models: a project brief, saved notes, persistent memory, or something else?

Next task:
What do we need help with?

Before You Change One Line of AI-Generated Code, Save These 7 Things

KAT | Co-founder, 123sudo — Sat, 03 Oct 2026 07:59:49 +0000

Before You Change One Line of AI-Generated Code, Save These 7 Things

Your app works. You ask AI for one small change.

Suddenly, the layout breaks, a button stops responding, and a feature you finished yesterday has disappeared.

So you paste the error into a fresh chat. The model suggests another fix. You try it.

Now you have two problems and no clear way back.

AI-assisted coding makes changes easy to generate. It does not automatically make them safe to apply.

Before your next change, spend five minutes creating a small project handoff. You don’t need a particular tool for this. A Markdown file in your repository works.
**

Save the current working version**

Make sure you can undo the next change.

If you use Git, review your working tree and create a checkpoint commit containing only the intended files. Don’t accidentally include secrets, generated files, or unrelated changes.

If you don’t use version control yet, back up the project before editing it. Git is worth learning early.

A chat history is not a code backup.

2. Describe the exact change

“Improve this dashboard” leaves a lot open to interpretation.

Try:

Add a date filter above the activity table. Keep the existing layout and table behavior unchanged.

Give AI a boundary as well as a goal. A narrowly defined task is easier to review and test.

3. Write down the expected behavior

Describe what success looks like in terms someone can check.

For example:

When a user selects a start and end date:

Show only activity within that range.
Include both boundary dates.
Display an empty state if nothing matches.
Clearing the filter restores all activity.

This gives you a basis for tests instead of relying on “it looks right.”

4. Identify the relevant files

Provide the files involved in the behavior, not just the file where you noticed the problem.

For a filter, that might include the UI component, data-fetching logic, and existing tests.

If you’re unsure, ask AI to inspect the project and identify the relevant files before making edits. Review its proposed scope.

Avoid sharing credentials, private user data, or production secrets.

5. List the known issues

Not every problem appeared because of the latest change.

Record existing bugs so you can distinguish a regression from something that was already broken.

Known issues:

Mobile table overflow already exists.
Loading state needs improvement.
Export is not implemented.

This also helps prevent the model from expanding a small task into an unsolicited cleanup project.

6. Record what you already tried

A failed approach is useful information.

Instead of saying “we tried that,” explain the attempt and the result:

Tried:
Filtering after pagination.

Result:
Some matching records were omitted because only the current page
was being filtered.

Decision:
Apply the filter before pagination.

Keep observations separate from guesses. “This request returned a 500” is evidence. “The database must be broken” is a hypothesis.

7. Say what must not change

Protect the decisions that matter:

Public API behavior
Authentication rules
Database schema
Existing dependencies
Unrelated UI components

These aren’t guarantees. You still need to inspect the diff. But explicit constraints make it easier to spot when a proposed fix goes beyond the task.

A copyable project handoff

Save this as AI_HANDOFF.md, or keep it wherever your team maintains project notes.

Current task

Working checkpoint

Commit or backup:

Requested change

One specific outcome:

Expected behavior

-

Relevant files

Known issues

Previous attempts

Attempt:
Observed result:
Decision:

Constraints

What must not change:

Verification

Tests and manual checks to run:

Keep it short. Update it when the work changes.

An outdated handoff can mislead an AI just as easily as an incomplete prompt.

Where knowledge bases, skills, and agents help

Once you have reliable project information, workspace features can make it easier to use.

A knowledge base can keep requirements and decisions accessible. A skill can define a repeatable review process, such as checking regressions and missing tests before suggesting stylistic changes. An agent can work through steps such as inspecting files, proposing a change, and helping verify the result.

But none of those replaces a recoverable code checkpoint or your review of the diff.

Disclosure: Our team at 123sudo builds 9xchat. Its knowledge base, separate memory scopes, skills, and agentic workflows are designed to help keep relevant context available across tasks and models. The handoff above is useful whether you use our workspace or something else.
**
Before you accept the change**

Check the diff. Run the relevant tests. Exercise the main workflow.

If something fails, return to the checkpoint rather than stacking speculative fixes indefinitely.

The goal isn’t to write a perfect prompt. It’s to make each change understandable, reviewable, and reversible.
**
Before your next AI-generated edit, copy the handoff template and fill it in for one real task.**

ai, #programming, #beginners,

productivity

TypingMind vs. 9xchat: Which AI Workspace Fits the Way You Work?

KAT | Co-founder, 123sudo — Sat, 03 Oct 2026 01:49:34 +0000

If you use more than one AI model while building software, you’ve probably had to move context between tools: project notes here, API keys there, and the reason you changed something buried in an old chat.

Choosing an AI workspace is not just about how many models it supports. It’s about how you want to manage model access, project context, and the work that happens after a chat response.

Disclosure: I’m part of the team at 123sudo, which builds 9xchat. I’ll compare the approaches as fairly as I can, including where TypingMind may be a better fit.

Two different approaches
TypingMind is an AI chat frontend that lets you connect supported providers using your own API keys. You manage provider usage and billing separately. That can suit developers who want direct control over provider accounts and are comfortable managing keys and usage.

9xchat brings cloud and local models into one workspace, with a credit-based option for cloud usage. It also includes a knowledge base, persistent memory across models, skills, and agentic workflows.

Neither approach is automatically better. The useful question is which setup fits your workflow.

1. How do you want to handle model usage?
With an API-key setup, you manage provider accounts and usage directly. That gives you a direct relationship with the providers, but you also need to keep track of their billing and API configuration.

With 9xchat’s credit-based cloud access, usage is handled through credits, with transparent usage information. You can also work with local models, depending on your setup.

Neither option guarantees lower costs. Usage depends on the models, task, and amount of context involved. Compare the current pricing and billing details before choosing.

2. Where does your project context live?
A chat log can be useful, but it is not always a good source of truth for a project.

For a coding task, the relevant context might include requirements, current status, decisions, screenshots, and what you already tried. If those details are spread across chats and files, switching models can mean reconstructing the project all over again.

9xchat has a knowledge base that can be accessed from chats, along with separate global, chat, and agent memory. The intent is to make relevant context available to the task without treating every conversation as if it needs your entire history.

Whatever tool you choose, keep important project information current. A stale brief is still stale, even if the workspace remembers it perfectly.

3. Do you need more than chat?
If your workflow ends with an answer, a chat interface may be all you need.

If it involves repeated steps, you may want skills or agentic workflows. In 9xchat, skills can provide a repeatable approach to a task, while agents can help carry out multi-step workflows. For example, publishing a post can be part of an agentic workflow. Scheduling posts is not currently supported.

When evaluating agent features, look at what they can actually do, what context they use, and where you remain responsible for review.

Which one should you choose?

TypingMind may fit you if you prefer connecting your own provider API keys and managing usage directly with those providers.

9xchat may fit you if you want cloud + local models, credit-based cloud usage, project knowledge and memory, plus skills and agentic workflows in one workspace.

Try the same real task in both. For example, ask each to review a feature change using the same project notes. Notice how much setup is required, whether the relevant context is easy to provide, and how clear the usage costs are.

That test will tell you more than a feature checklist.

*If you want to try 9xchat, explore it at 123sudo.com.
*
Suggested DEV tags: ai, productivity, opensource, webdev

9xchat may fit you if you want cloud + local models, credit-based cloud usage, project knowledge and memory, plus skills and agentic workflows in one workspace.

That test will tell you more than a feature checklist.

If you want to try 9xchat, explore it at 123sudo.com.

Suggested DEV tags: ai, productivity, opensource, webdev