Forem: Shrijal Acharya

🚀 How to run a fully-autonomous company with OpenClaw 🦞

Shrijal Acharya — Thu, 02 Apr 2026 14:39:22 +0000

Imagine owning a company with just one human employee, and that too is yourself. The rest? All OpenClaw agents!

Before OpenClaw, that would have sounded completely silly, but with it, it's possible, really possible!

You can automate your entire company or simulate a fully functioning one with just OpenClaw and your VPS, Mac Mini, or local system for testing.

TL;DR

In this tutorial, you'll learn how to run an entire company using just yourself and a bunch of OpenClaw agents.

What you will learn: ✨

What OpenClaw is and how it works
Why storing API keys locally is a bad idea
Setting up Composio for secure OAuth-based integrations
Connecting your first app and getting agents up and running 🚀

Ready to become a one-person company? 👀

What's OpenClaw?

💁 I assume you already know what OpenClaw is. If not, why are you even here? Just kidding... The blog itself is completely beginner friendly. If you already have an idea of what OpenClaw is, just skip this section.

OpenClaw is a personal AI assistant you run on your own machine or a server you own. It is the thing that actually sits between your model provider (OpenAI, Anthropic, Kimi, etc.) and the stuff you want done, such as messaging, tools, files, and integrations, and this idea is what actually makes the one-person company possible.

Take this as a mental model:

Your LLM is the brain (thinks)
OpenClaw is the body (it can do things)
The Gateway is the receptionist (routes messages in and results out)

It provides the model with a runtime that can call tools, maintain state, and appear where you already chat (WhatsApp, Telegram, Slack, Discord, etc.). Now, that's just the gist. There's much more to understand. I assume you've already worked with it, so I'm not going any deeper than this in the intro.

For installation, visit the OpenClaw installation guide, and based on your distro and installation choice, install it on your machine.

If you just want it running quickly, do the normal installation. If you're even slightly paranoid (which you should be 😮‍💨), use Docker.

Also, make sure you set up a channel for easier chatting from your phone (preferably Telegram).

For help setting up a channel, ask OpenClaw itself. It knows itself better than anyone else on the internet.

💁 If you face issues like OpenClaw: access not configured when talking with the bot, make sure you run this command:

openclaw pairing approve <telegram/whatsapp/...> <pairing_code>

Just like that, now you have an agent listening on your channel. Message anything, and you should get a reply back.

From here onwards, I assume you already have OpenClaw running. To make sure everything is working, run this command:

openclaw health

If not, try running openclaw doctor, which helps debug your gateway or channel issues.

Run a whole company?

Yeah, in theory, you can actually automate or run an entire company. Can't guarantee the company will stand long, but with OpenClaw, it's now possible.

The only human in the process is going to be yourself. All your employees will be OpenClaw Agents.

As you can see, most day-to-day operations of running a company, such as sales, team meetings, and customer care, can be managed with OpenClaw Agents. And there are many more than just the ones in the image, of course. This is just a quick sketch to give you an idea.

Problem with "Just OpenClaw"

By default, OpenClaw works with API keys, and it stores them in a plain text file in the ~/.openclaw/ directory for all the services you use, such as Google, Gmail, and so on. This is not a very good practice if you're running this on your local machine. If using something like a VPS or the hyped Mac Mini, it's fine, but still, storing credentials in a local plain text file is never a good idea.

Especially if you're using smaller models, they are even more prone to prompt injections, and since OpenClaw has whole system access, it might wipe out your entire system without you doing anything.

What's actually gone wrong in the wild (already):

Malicious skills on ClawHub: researchers found hundreds to thousands of skills that were straight-up malware or had critical issues, including credential theft and prompt injection patterns.

Prompt injection turning into installs: there's been at least one high-profile incident where a prompt injection was used to push OpenClaw onto machines via an agent workflow.

For the above reasons, I recommend that you use some hosted service which in my case, Composio. It lets you authenticate using OAuth, which is the most secure option over pasting keys locally.

Connecting your first app

Now, it's time to create agents, but first, we need to set up or connect our first app from Composio.

The agents will mostly revolve around working with those applications from Composio.

1. Install Composio Plugin

Composio's OpenClaw plugin connects OpenClaw to Composio's MCP endpoint and exposes third-party tools (GitHub, Gmail, Slack, Notion, etc.) through that layer.

openclaw plugins install @composio/openclaw-plugin

2. Composio Plugin Setup

Log in at dashboard.composio.dev
Choose OpenClaw as the client.
Copy your consumer key (ck_...) from the Composio dashboard settings, then set it:

openclaw config set plugins.entries.composio.config.consumerKey "ck_your_key_here"

Now, it's a good idea to restart the gateway:

openclaw gateway restart

3. Verify the plugin loaded

openclaw plugins list
openclaw logs --follow

You're looking for something like "Composio loaded" and a "tools registered" message.

If the plugin is "loaded", it means you can now successfully access Composio.

Here's how it works:

The plugin connects to Composio's MCP server at https://connect.composio.dev/mcp and registers all available tools directly into the OpenClaw agent. Tools are called by name — no extra search or execute steps needed.

If a tool returns an auth error, the agent will prompt you to connect that toolkit at dashboard.composio.dev.

Here's how the configuration looks:

{
  "plugins": {
    "entries": {
      "composio": {
        "enabled": true,
        "config": {
          "consumerKey": "ck_your_key_here"
        }
      }
    }
  }
}

You can configure the following options directly from the config file:

enabled: enable or disable the plugin
consumerKey: your Composio consumer key
mcpUrl: the MCP server URL. By default, it's https://connect.composio.dev/mcp

Previously, you had to configure API keys per integration, but with Composio you don't have to worry about any of that. Just make sure not to leak the consumer key that we generated.

And it's that simple. Everything works out of the box just as you would use any other OpenClaw plugin!

Now, to test if it works, head over to the Control UI chat and send a message, something like:

"List the Composio tools you have available."

If it asks you to connect the tools, head over to dashboard.composio.dev and connect each of the tools you require. It's as simple as clicking Connect.

All the integrations you use are OAuth-hosted, and only the tools you connect will be available to OpenClaw. Nothing more than that.

Setting up a Multi-Agent Team

The idea is pretty clear. Since one single agent wouldn't be enough to handle all sorts of company requirements due to context window limitations, you could have multiple sub-agents for multiple task types.

Say, one agent AgentA handles marketing, AgentB handles business analysis, AgentC handles something else.

Each agent has a distinct role, personality, and model optimized for its use case — say, for business analysis, you'd want a more research-oriented model like GPT-5.2.

And how do you create them? It's simple, just chat with OpenClaw itself, either in the chat window or your configured channel.

Example:

Please create a new agent called **Shri**. This agent should be capable of handling tasks such as reading and composing emails, and scheduling Google Meet sessions.

For the model, use **Claude Sonnet 4.6** (`claude-sonnet-4-6`).

Please ensure that the existing main agent remains untouched and unchanged.

And it will create a new agent, which you can view in the Agents tab in the OpenClaw dashboard or by running /agents in the OpenClaw TUI.

Similarly, do it for all your different work types. Create a separate agent for each type of work.

The main agent can then delegate work to those specialized agents, each handling one specific task type, which improves response quality because one agent is handling one type of work instead of everything at once.

💡 TIP: This also helps you reduce model usage costs, as you can assign more reasoning-heavy models to complex tasks and smaller, cheaper models to simpler ones.

What's Missing?

Everything seems good, but there's one thing missing... autonomy.

You still have to message OpenClaw manually to get things done, which isn't ideal when you're planning on using it as an AI employee.

There are two ways to achieve this:

1. If you're a little technical

You must be familiar with cron jobs and their syntax. If so, this is a way to do it directly from the CLI outside of OpenClaw.

Run the following command:

openclaw cron add --schedule "<cron_syntax>" --message "<prompt>"

Say you want it running every single day at 8 AM:

openclaw cron add --schedule "0 9 * * *" --message "<prompt>"

2. If you're not technical

Similar to how we used a prompt to create a new agent, all you need to do is write a prompt:

Every morning at 9 AM, send me the top news of the day. Also scan my Google Calendar for the day, identify each attendee and their company. Send me two different messages on Telegram: one with the news summary and one with the meeting details.

Use the relevant Agent you have for each purpose.

💁 There's also a similar concept called Heartbeat, which is another approach for scheduling tasks in OpenClaw. You can check it out here: OpenClaw Heartbeat

Workflow Demo

Okay, time for a demo.

Showing an entire workflow demo of running a company would be too much work, so for this demo, I will show you one part of the workflow: checking the calendar and messaging a summary with attendees every day at a set time.

You could have it run every X hours or every single day at a fixed time. After each interval, the model will do as said above (Obviously, the idea is too naive, but it's just for this demo.) The possibilities are endless.

Keep this in mind: “anything that you can do manually on the internet, you can automate with OpenClaw.” So, you get the idea.

💁 NOTE: If you're serious about this idea, it's better to run this on a VPS or a Mac Mini, because you mostly don't have your personal PC running 24/7.

Here's the demo:

Conclusion

So far, you've learned how to run a fully functioning company with just yourself and a bunch of OpenClaw agents, using Composio as the secure integration layer between OpenClaw and all your third-party apps.

Be sure to give a star to Composio and OpenClaw on their GitHub repositories.

If you found this article helpful, drop a like and share your thoughts in the comments below. 👇

Happy automating! 🥳

Shrijal AcharyaFollow

Full Stack SDE • Open-Source Contributor • Collaborator @Oppia • Mail for collaboration

Everything you need to know about OpenAI GPT-5.4 ✌️

Shrijal Acharya — Sat, 21 Mar 2026 14:08:05 +0000

OpenAI’s new GPT-5.4 is here, and on paper at least, it looks like one of their strongest all-rounder models so far.

TL;DR

In this article, we take a quick look at OpenAI GPT-5.4, go through its official benchmarks, and then compare it in one small coding task against Anthropic’s general-purpose model, Claude Sonnet 4.6, to see how it actually performs.

We briefly go over what GPT-5.4 is, what OpenAI is claiming with this model, and why it looks like one of their strongest all-rounder releases so far.

We look at the official benchmarks around coding, reasoning, tool use, and computer-use capabilities to get an idea of how strong the model looks on paper.

Instead of relying only on benchmarks, we also compare GPT-5.4 against Claude Sonnet 4.6 in one small, quick coding task (not enough to judge fully, but still...).

Brief on OpenAI GPT-5.4

So, before we jump into the coding test, let me give you a quick brief on GPT-5.4, because this is one of OpenAI’s biggest model releases in a while.

OpenAI released GPT-5.4 on March 5, 2026, and they are positioning it as their most capable and efficient frontier model for professional work.

What makes this model interesting is that OpenAI is not selling it as just a coding model, and not just a reasoning model either. They are basically pitching it as an all-round professional work model that combines strong reasoning, strong coding, better tool use, and much better performance on practical work like spreadsheets, presentations, etc.

Honestly, this part matters more than it sounds. A lot of real AI work is not just prompting or writing code, it is dealing with PDFs, spreadsheets, slides, and all kinds of unstructured data. That is also where something like Tensorlake makes sense, because it helps turn that mess into something models can actually work with.

And the specs are also pretty wild. GPT-5.4 supports a 1.05M token context window with 128K max output tokens, which is pretty good room to work with. All in all, this helps the model remember things better. Also, a thing to note is that the knowledge cutoff for this model is August 31, 2025.

Now, let's talk about the part we mostly care about.

On the official OpenAI benchmarks, GPT-5.4 scores 57.7% on SWE-Bench Pro (Public), which puts it basically side by side with GPT-5.3-Codex, a coding-focused model, at 56.8%. So yes, OpenAI says this general-purpose model is slightly better than GPT-5.3-Codex, a coding-focused model, which I personally have not had the best experience with compared to Claude models, and that is kind of wild to think about.

OpenAI says GPT-5.4 is their first general-purpose model with native computer-use capabilities, which is a pretty big deal. That means it is built not just to generate text or code, but also to operate across software, work from screenshots, and handle more agent-like workflows. On OSWorld-Verified, it scores 75.0%, which OpenAI says is above human performance on that benchmark. 🤯

One thing I also like here is that OpenAI is claiming GPT-5.4 is their most factual model yet. It is said to be 18% less likely to contain any errors compared to GPT-5.2.

For API developers, pricing matters, of course.

The standard GPT-5.4 model is listed at $2.50 per 1M input tokens, $0.25 cached input, and $15 per 1M output tokens. GPT-5.4 Pro is way more expensive at $30 input and $180 output per 1M tokens, and OpenAI says it can take several minutes on hard tasks, so that one is clearly for cases where you really want the best answer and are okay paying for it.

💁 The normal GPT-5.4 model is probably the one most people will actually care about day to day, and that's what I'd prefer.

And as always, benchmarks are benchmarks. But on paper at least, GPT-5.4 looks like one of the strongest all-rounder models OpenAI has shipped so far.

Quick Coding Test

As this is a general-purpose model instead of a coding-tuned model, comparing the model's ability solely on coding is just not fair. But as developers, we mostly care about how good the model is at coding anyway, so just to give you an idea of how this model performs, we will do a quick test.

As you can see, there's not much difference in SWE-Bench between GPT-5.4 and GPT-5.3-Codex:

GPT-5.4: Latency (s): 1,053, Accuracy: 57.7%, Effort: xhigh
GPT-5.3-Codex: Latency (s): 1,114, Accuracy: 57.2%, Effort: xhigh

But to give you an idea of what to expect from this model in coding, I will run one small, quick test.

Let's take two general models, one from Anthropic, Claude Sonnet 4.6, and one from OpenAI, GPT-5.4, not pro, and compare them against each other to show the difference in their coding skills.

For the test, we will use the following CLI coding agents:

Claude Sonnet 4.6: Claude Code (Anthropic’s terminal-based agentic coding tool)
OpenAI GPT-5.4: Codex CLI

As GPT-5.4 is said to be strong in frontend, why not test it on frontend itself?

Test: Figma Design Clone with MCP

In this test, we'll be comparing both models on a Figma design, a complex dashboard with so many things happening in the UI.

Here's the Figma design that I'll ask both models to clone:

Prompt:

Build a **pixel-accurate clone** of the attached Figma design frame using the **provided Next.js project** as the starting point. Do **not** create a new project. Instead, implement the UI inside the existing codebase.

https://www.figma.com/design/8quNKljV0spv67VAGsA75D/Dashboard-Design-Concept--Community---Copy-?node-id=69-123&t=Tvu2UB7UDMqkvPRb-4

Please match the design as closely as possible, with close attention to layout, spacing, alignment, typography, colors, borders, shadows, corner radius, and overall visual balance.

Requirements:

* use the existing **Next.js** setup
* keep the code clean and componentized
* make the page responsive without changing the intended design
* use semantic HTML where appropriate
* avoid adding your own design decisions unless necessary
* if any part of the design is unclear, make the most reasonable choice and stay visually consistent

Prioritize **design accuracy first**, then code quality.

GPT-5.4

GPT-5.4 pretty much one-shotted the entire implementation in one go, which was honestly nice to see. It did not need any follow-up prompt, no fixing, nothing. It just took the Figma frame through MCP and started building the whole thing right away.

The final result actually looked decent. I would not call it pixel-perfect by any means, but compared to Claude Sonnet 4.6, I’d say the implementation looked noticeably better overall. The whole thing feels more like a static picture of the design than an interface you can actually interact with.

Time-wise, it took roughly 5 minutes to get to a working to the working build.

Here’s the demo:

You can find the code it generated here: GPT-5.4 Code

Token usage looked like this:

Total Token Usage: 166,501
Input Token Usage: 151,595
Cached Input Tokens: 1,291,776
Output Token Usage: 14,906
Reasoning Tokens: 1,479

And the following code changes:

Code Changes: 3 files changed, 803 insertions(+), 82 deletions(-)

To be honest, I still would not say this is the kind of code implementation you can just ship straight to production and call it done. But for a one-shot frontend clone from a Figma frame, this was a pretty solid attempt.

Claude Sonnet 4.6

Claude Sonnet 4.6 went straight into the implementation right away. It did run into an issue at first, not really a build error, but more of one of those annoying Next.js image gotchas:

After that, I gave it a quick follow-up prompt, and almost instantly, it fixed the issue and came back with a decent implementation.

As you’d expect, it did manage to clone the project structure and get the UI in place. And again, the same issue, there's just no functionality whatsoever. It just feels like a picture with no interactivity.

Here’s the demo:

You can find the code it generated here: Claude Sonnet 4.6 Code

Time-wise, it took 9 minutes 56 seconds to get to a working result, and the follow-up fix was pretty much instant.

Token usage, based on Claude Code’s model stats, looked like this:

Input Token Usage: 84
Output Token Usage: 35.4K

And the following code changes:

Code Changes: 10 files changed, 1017 insertions(+), 84 deletions(-)

To be honest, I’m not really impressed, but I’m not disappointed either. The result feels pretty neutral overall. It was able to use tools, get fairly close to the UI, and produce something usable for comparison, but the implementation itself feels a bit weird and not all that convincing.

Conclusion

So, after all the benchmarks, claims, and hype, I think the fairest takeaway is this: GPT-5.4 looks very strong on paper, and for a lot of people it works and is an upgrade, but it still doesn’t seem like it is the best model you can get for coding.

So yeah, I’d say GPT-5.4 is probably one of the strongest all-rounder models OpenAI has shipped so far, but whether it beats Claude, be it Sonnet or Opus, for coding in real usage is still something you’ll want to judge from your actual hands-on testing, not just benchmarks.

And honestly, that’s the real takeaway here anyway.

These models keep getting better at a speed that is honestly hard to keep up with. So rather than getting too stuck on who won one benchmark, the better thing to do is probably to keep building, keep testing, and keep learning how to use these models better for your use case.

What do you think, is GPT-5.4 actually that good, or is Claude still your go-to? 👇

Shrijal AcharyaFollow

Full Stack SDE • Open-Source Contributor • Collaborator @Oppia • Mail for collaboration

🔥Claude Opus 4.6 vs. Sonnet 4.6 Coding Comparison ✅

Shrijal Acharya — Thu, 05 Mar 2026 14:04:59 +0000

Anthropic recently dropped the updated Claude 4.6 lineup, and as usual, the two names everyone cares about are Opus 4.6 and Sonnet 4.6.

Opus is the expensive “best possible” model, and Sonnet is the cheaper, more general one that a lot of people actually use day to day. So I wanted to see what the real gap looks like when you ask both to build something serious, not a toy demo.

Benchmark-wise, there’s a difference of course, but it doesn’t look that huge when it comes to SWE and agentic coding.

I kept it super basic: one test (but a big one), same prompt, same workflow. I just compared how close they got without me stepping in.

⚠️ NOTE: Don’t take the result of this test as a hard rule. This is just one real-world coding task, run in my setup, to give you a feel for how these two models performed for me.

TL;DR

If you just want the takeaway, here’s the deal with these models:

First, Opus 4.6 is the peak for coding right now. At the time of writing, it’s basically the OG, and nothing else comes that close.

Claude Opus 4.6 had a cleaner run. It hit a test failure too, but fixed it fast, shipped a working CLI + Tensorlake integration, and did it with way fewer tokens. Rough API-equivalent cost (output only) came out around ~$1.00, which is kind of wild for how big the project is.
Claude Sonnet 4.6 Surprisingly close for a cheaper, more general model. It built most of the project and the CLI was mostly fine, but it ran into the same issue as Opus and couldn’t fully recover. Even after an attempted fix, Tensorlake integration still didn’t work. Output-only cost was about ~$0.87, but it used way more time and tokens overall to get there.

💡 Obviously, this isn’t a test to “compare” the two head-to-head. It’s just to see the difference in code quality. In general, there’s never really been a fair comparison between Opus and Sonnet since their very first launch, Opus has always been on another level.

Test Workflow

ℹ️ NOTE: Before we start this test, I just want to clarify one thing. I'm not doing this test to compare whether Sonnet 4.6 is better than Opus 4.6 for coding, because obviously Opus 4.6 is a lot better. This is to give you an idea of how well Opus 4.6 performs compared to Sonnet.

For the test, we will use everyone's favorite CLI coding agent, Claude Code.

As both models are from Anthropic, it works best for both and is not biased toward either.

We will test both models on one decently complex task:

Task: Build a complete Tensorlake project in Python called research_pack, a “Deep Research Pack” generator that turns a topic into:
a citation-backed Markdown report, and
a machine-readable source library JSON with extracted text, metadata, summaries, you get the idea.

It also has to ship a nice CLI called research-pack with commands like:

research-pack run "<topic>"
research-pack status <run_id>
research-pack open <run_id>

We’ll compare the overall feel, code quality, token usage, cost, and time to complete the build.

💡 NOTE: Just like my previous tests, I’ll share each model’s changes as a .patch file so you can reproduce the exact result locally with git apply <file.patch>.

Why Tensorlake?

Tensorlake is a solid choice for this Opus 4.6 vs Sonnet 4.6 test because it is a real platform with enough complexity to quickly show whether a model can actually build something end to end. It has an agent runtime with durable execution, sandboxed code execution, and built in observability, so the test is not just writing a few functions, it is wiring up a production workflow.

And selfishly, it is also a good dogfood moment. 👀 If a model can spin up a Tensorlake project from scratch and get it working, that is a pretty strong sign for two things: these recent models are getting scary good and how usable Tensorlake is for building serious agent style pipelines.

Coding Tests

Test: Deep Research Agent

For this test, both models had to build the research_pack Tensorlake project in Python. The goal was simple: give it a topic, it crawls stuff, figures out sources, improves them, and spits out:

report.md with [S1] style citations
library.json with the full source library
a clean CLI: research-pack run/status/open
plus Tensorlake deploy support so you can trigger it as an app, not just locally

You can find the prompt I’ve used here: Research Agent Prompt

One thing that went a bit crazy is that both models ran into basically the exact same/similar issue during the run.

That shows how similarly these models can behave, which is kind of creepy. If you give them the exact same task and constraints, they’ll often make similar choices. I wanted to call that out because you might’ve noticed the same pattern too.

Not surprisingly, Opus fixed it much faster and with way fewer tokens. Sonnet took longer, burned a lot more context trying to debug it, and even after the fix pass, it still didn’t fully work.

Claude Opus 4.6

Opus was pretty straightforward.

It did hit a failure while running tests, but it was a quick fix. After that, everything looked clean: CLI worked, offline mode worked, and overall all the feature flags seem to work perfectly.

Here’s the acceptance checklist it generated at the end, I really love it as it created this after making sure all tests pass, and everything is in place, that's how it's done.

Here's the demo of the working CLI:

Note: The API key visible in the below demo videos has been revoked. Please don’t try to use it.

...and how it integrates with Tensorlake:

You can find the code it generated here in a patch file: Opus 4.6 Patch file

Cost: ~$1.001

ℹ️ NOTE: As I'm using a Claude plan and not on API usage, this is roughly calculated based on the input/output tokens.

Duration: 20 minutes 6 seconds + ~1 min 40 sec for the fix

Output Token Usage: 33.2K + ~4K for the fix

Code Changes: 156 files changed, 95013 insertions(+)

ℹ️ You can see the complexity of the project for yourself, and you’ll probably be shocked at how good these models have gotten. It’s no longer just boilerplate or small refactors. They can build a complete, end-to-end project from scratch from a single prompt. We’re officially in the real AI era.

Claude Sonnet 4.6

Sonnet was… close, but not quite as clean as Opus.

Just like Opus, it ran into a test failure during the run. This is one of those things you’ll notice with similar models: same prompt, same codebase, and they sometimes hit the exact similar weird issue.

Here’s the demo of the CLI (you’ll see it mostly working, but there are some rough edges) and not as well implemented as Opus:

...and how it integrates with Tensorlake:

It's not working as you can see. Sonnet did attempt a fix, but still couldn't get to a working state with Tensorlake. But overall, it was super close.

You can find the code it generated here: Sonnet 4.6 Patch

Cost: ~$0.87

ℹ️ Same as Opus 4.6, this is an approximate cost based on the input/output tokens.

Duration: 33 minutes 48 seconds + ~3m 18s for the attempted fix

Output Token Usage: 52.9K + ~5K for the fix (didn't work)

Code Changes: 88 files changed, 23253 insertions(+)

🤷‍♂️ I can’t really complain about Sonnet’s performance, other than this one issue. It still got almost everything working. And to be fair, Sonnet isn’t Anthropic’s flagship coding model like Opus. It’s more of a general-purpose model, and Opus also comes with a pretty big cost difference, so the gap in code quality is kind of expected.

And please don’t try using the API keys shown in the video, as it’s already revoked.

Conclusion

Opus as a lineup is just too good. If you want an end-to-end product that works most of the time with minimal hand-holding, go with Opus. If you want something cheaper, and you’re okay finishing the last bit yourself, Sonnet is still solid.

Even in this one test, you can already see the gap in implementation quality, token usage, and time spent.

And if Anthropic can cut Opus to half its price, or even get it close to Sonnet’s, it’d be over for most other models.

For me, the best way to use these models is still the same: let them build most of it fast, then run it, test it, and clean up the rough parts yourself.

Let me know your thoughts in the comments. ✌️

How to set up Secure OpenClaw and power it with 850+ SaaS Apps 🦞🔒

Shrijal Acharya — Thu, 05 Mar 2026 13:26:54 +0000

OpenClaw has been showing up in my feed way too much, so I finally sat down and tested it properly, and yeah, it comes with a few real problems.

In this post, I’ll cover what OpenClaw is, how to set it up, where the security risks really come from, and how to use safer remote integrations so you can make it a bit more secure and save yourself some stress.

TL;DR

If you just want the takeaway, here’s the deal with OpenClaw:

OpenClaw is a local agent gateway. It is the layer that connects your LLM (OpenAI, Anthropic, etc.) to real tools and local execution.

The “special sauce” is the package. People like it because it ships as a usable bundle: built-in skills, a simple “agent brain” file (SOUL.md), and easy chat support like messenger integrations.

Security is the big problem. By design, it can touch files, run commands, and pull third-party skills. The least-bad way to use it is with remote, sandboxed integrations (which I’ve shown how to set up).

Also, watch your token bill. It can be very inefficient and chew through credits fast, especially if you’re using hosted models instead of a local LLM.

Overall, you'll learn everything you need to understand and start with OpenClaw (and make it slightly better with secure integrations).

What's OpenClaw?

OpenClaw is a personal AI assistant you run on your own machine (or a server you own). It is not a new model. It is the thing that actually sits between your model provider (OpenAI, Anthropic, Kimi, etc.) and the stuff you want done, such as messaging, tools, files, and integrations.

Take this as a mental model:

Your LLM is the brain (thinks)
OpenClaw is the body (it can do things)
The Gateway is the receptionist (routes messages in and results out)

So when people say “OpenClaw turns an LLM into an agent,” what they really mean is: it gives the model a runtime that can call tools, keep state, and show up where you already chat (WhatsApp, Telegram, Slack, Discord, etc.).

Now, that's just the gist. There's a lot more to understand. I assume you've already worked with it, so I'm not going any deeper than this in the intro.

What's Special than something like Manus? 🤔

Manus is essentially "agent as a product," but you're limited to their UI, tools, rules, and cloud.

OpenClaw is more like “agent as a kit.” It’s meant to be installed, set up, and shaped around your own workflow. You decide what models it uses, what tools it can touch, what data it can access, and where it runs.

That's the biggest difference.

💁 "Manus is for convenience, and OpenClaw is for control."

Wow, that was a nice line I came up with on the fly. 😂

OpenClaw Installation

You’ve got two clean ways to install OpenClaw. If you just want it running quickly, do the normal installation. If you’re even slightly paranoid (which you should be 😮‍💨), do Docker.

The core requirement is Node ≥ 22.

Option 1: Normal install (recommended for most people)

Prereqs: Node 22+ and an API key (OpenAI, Anthropic, OpenRouter, whatever you’re using).

Install OpenClaw:

curl -fsSL https://openclaw.ai/install.sh | bash

Run onboarding (this sets up provider auth + gateway settings and can install the background service):

openclaw onboard --install-daemon

Check the gateway status (if you installed the service, it should already be running):

openclaw gateway status

Optional: Open the Control UI:

openclaw dashboard

Option 2: Docker (more isolated and secure)

Docker is great when you want a throwaway environment or isolation from your host, but it introduces an important rule:

ℹ️ Containers only see plugins and config if they share the same OpenClaw state directory/volume. So, it comes with a little complexity.

Clone and start the Docker stack:

git clone https://github.com/openclaw/openclaw
cd openclaw
./docker-setup.sh

💡 To know more about how/what it does, visit the OpenClaw Docker Quickstart

Control UI gotchas

If you open the Control UI, and it shows something like:

unauthorized: gateway token missing

That's normal. The UI needs a gateway token to connect.

Get your token:

cat ~/.openclaw/openclaw.json | jq -r '.gateway.auth.token'

Make sure jq is installed on your machine. Or, you can manually get the token from the config file ~/.openclaw/openclaw.json.

Then either:

Paste it in the UI (Overview → Gateway Access → Gateway Token)

Use a URL that includes it, for example via:

openclaw dashboard --no-open

OpenClaw is bad for Security

OpenClaw’s whole selling point is also the problem: it can read/write files, run shell commands, and load third party “skills.” That is basically “download random code from the internet and run it with your permissions,” except now an LLM is the one executing.

What’s actually gone wrong in the wild (already):

Malicious skills on ClawHub: researchers found hundreds to thousands of skills that were straight up malware or had critical issues, including credential theft and prompt injection patterns.
Prompt injection turning into installs: there’s been at least one high profile incident where a prompt injection was used to push OpenClaw onto machines via an agent workflow.
Exfiltrate API keys and tokens: When your agent has full control of the computer, and when compromised, it can easily exfiltrate the API keys and tokens to attackers.

If you’re still going to run it, do the bare minimum to not get cooked:

Don't trust skills you don't know. If you didn’t read it, don’t install it.
Prefer OAuth-hosted integrations over pasting keys locally.
Run it sandboxed (Docker) and keep it away from your real home directory.

If you want to read more on OpenClaw’s security posture, we have a nice piece on it: OpenClaw is a Security Nightmare Dressed Up as a Daydream

Setting up safe Integrations

So enough of that. Let's look into how you can make it a bit more secure.

I assume you already have OpenClaw installed and have already done the initial setup onboarding. We’ll use Composio plugin, which gives us access to 850+ SaaS apps like Gmail, Outlook, Canva, YouTube, Twitter and more without you needing to manage OAuth tokens and integrations.

Contrary to OpenClaw’s native integrations, the credentials do not stay in your system and neither a compromised Claw can access them. The credentials are securely hosted and managed by Composio.

1. Install Composio Plugin

Composio’s OpenClaw plugin connects OpenClaw to Composio’s MCP endpoint and exposes third-party tools (GitHub, Gmail, Slack, Notion, etc.) through that layer without you needing to handle auth hassles.

openclaw plugins install @composio/openclaw-plugin

2. Composio Plugin Setup

Log in at dashboard.composio.dev
Choose OpenClaw as the client.
Copy your consumer key (ck_...) from the Composio dashboard settings, then set it:

openclaw config set plugins.entries.composio.config.consumerKey "ck_your_key_here"

3. Verify the plugin loaded

openclaw plugins list
openclaw logs --follow

You're looking for something like "Composio loaded" and a "tools registered" message.

If the plugin is "loaded", it means that you can now successfully access Composio.

Here's how it works:

If a tool returns an auth error, the agent will prompt you to connect that toolkit at dashboard.composio.dev.

Here's how the configuration looks:

{
  "plugins": {
    "entries": {
      "composio": {
        "enabled": true,
        "config": {
          "consumerKey": "ck_your_key_here"
        }
      }
    }
  }
}

You can configure the following options directly from the config file:

enabled: enable or disable the plugin
consumerKey: your Composio consumer key
mcpUrl: the MCP server URL. By default, it's https://connect.composio.dev/mcp

Previously, you had to configure API keys per integration, but with Composio you don't have to care about any of that. Just make sure not to leak the consumer key that we generated.

And it's that simple. Everything works out of the box as you would use any other OpenClaw plugins!

Now, to test if it works, head over to the Control UI chat and send a message, something like:

“List the Composio tools you have available. Only print the result here”

If it asks you to connect the tools, head over to dashboard.composio.dev and connect each of the tools you require. It's as simple as clicking Connect.

All the integrations you use are OAuth hosted, and only the tools you connect will be available to OpenClaw. Nothing more than that.

Wrap Up!

OpenClaw is really useful for some people (not everyone), but it’s also risky. It can touch your files, run commands, and pull in third party skills, which can include malware, like we discussed. It’s a local agent gateway with everything: your filesystem, your shell, and whatever credentials you put into it. That power is the whole point, and it’s also the danger.

So if you’re going to use it, seriously consider OAuth-hosted safe integrations instead of pasting API keys everywhere. It’s an easy way to reduce the chance of a disaster.

And, if you're looking for some secure alternatives, find it here: Top 5 Secure OpenClaw Alternatives

That’s it for this post. Hope it helped, and I’ll see you next time. ✌️

🖐️Top 5 secure OpenClaw Alternatives you should consider 👀

Shrijal Acharya — Tue, 17 Feb 2026 12:59:41 +0000

OpenClaw is everywhere right now, and I get the hype. I’ve been seeing it all over my feed lately, and it’s clearly clicking with a lot of people. 👌

After using it for quite some time myself, it feels a bit too noisy, and not every tool works the same way for every person.

Whenever something starts trending this hard, it’s a good excuse to look around, especially if you’re after something more minimal.

And now, OpenClaw may have its 4th rename to be ClosedClaw very soon. 🤷‍♂️ You never know with OpenAI.

Why OpenClaw alternatives?

OpenClaw is super powerful, no doubt, but it comes with two big headaches, and you probably have already felt them yourself.

Security
Setup Friction
Security

When your agent can read files, run shell commands, and pull in third-party “skills,” you are basically giving it the keys to your machine. The skill marketplace has already turned into a real problem, with researchers finding hundreds of malicious skills.

If you are not auditing everything you install, it is easy to get yourself cooked.

Setup Friction

The “self-host it and wire up” path is fun if you like tinkering, but it is also where most people get stuck. You end up handling gateways, background services, tokens, and permission issues (most of the time).

And it's not that you're probably going to use all the features that come with the bloated app, just a few, for most people, so alternatives often could be a good choice.

Below are five OpenClaw alternatives that can cover the same ground, often with a smoother and more minimal experience, depending on what you’re building.

1. TrustClaw

ℹ️ Rebuilt from scratch on OpenClaw's idea with 1000+ tools, with a focus on security.

TrustClaw is for those who like the idea of OpenClaw but don't want to hand over their passwords to the agent and run it locally.

It's built by the Composio team, and the pitch is basically: you get an agent that is available 24/7, capable of taking real actions across a vast number (500+) of apps, but the risky parts like credentials and code execution are handled in a more controlled way.

What makes it different?

OAuth-only auth: You connect apps the normal way (OAuth), so you are not pasting API keys or passwords into config files.
Sandboxed execution by default: Every action runs in an isolated cloud environment that disappears when the task finishes. So you are not running “agent code” locally with your permissions.
Managed tool surface: Instead of pulling random community “skills” from a public registry, TrustClaw uses Composio’s managed integrations and tooling.
Audit trails + kill switch: It keeps a full action log, and you can revoke access with one click if you ever need to.

The last point is important because agent toolchains are a real security risk right now. These marketplaces, with just one random add-on, can trick you into running malware. This has already happened in the past. Ref: OpenClaw’s AI ‘skill’ extensions are a security nightmare

The kind of prompts it’s built for

“Handle my customer complaints and log in Notion”

It finds the right tools, fetches emails, creates drafts, and writes Notion pages (using tools such as: GMAIL_FETCH_EMAILS, GMAIL_CREATE_DRAFT, NOTION_CREATE_PAGE).
“Pull all Reddit threads mentioning [competitor] from the last 3 months, analyze sentiment...”
“Summarize all Slack messages in #product-feedback from this week...”

Why it’s comparatively better (for most of you)

Setup in seconds (vs. 30 to 60 minutes of tunnels and local setup)
Encrypted credentials managed by Composio (vs. plaintext local config)
Remote sandbox (vs. local machine execution)
Managed tool surface (vs. unvetted public skill registry)
Action logs + one-click revocation (vs. digging through config files)
and no need for Mac Mini 🤷‍♂️

Quick start

Go to TrustClaw and hit Get Started.
Connect the apps you want (OAuth flow).
Give it a task in plain language, or schedule one to run while you are offline.

Here's a demo: 👇

// Detect dark theme var iframe = document.getElementById('tweet-2022518658048888916-653'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2022518658048888916&theme=dark" }

It's that simple, so now you have OpenClaw that runs completely in the cloud with managed permissions and the tools you require.

2. ZeroClaw

ℹ️ Written in Rust, it runs even on $10 hardware with <5MB RAM.

ZeroClaw keeps the agent stack lean. Instead of a big local setup with lots of moving parts, you get a lightweight Rust binary that starts fast and runs comfortably on cheap hardware. If you care more about speed, stability, and low resource use, this one hits the sweet spot.

What makes it different?

Ultra lightweight: designed to keep CPU and RAM usage low.
Quick boot: fast startup, good for bots and always-on tasks.
Modular: swap models, memory, tools, and channels without rewriting everything.

Why pick it over OpenClaw?

You want something minimal and predictable.
You’re running on a small VPS / Raspberry Pi / home lab.
You don’t need a huge plugin marketplace, you need a tool that just runs.

Quick Start

git clone https://github.com/zeroclaw-labs/zeroclaw.git
cd zeroclaw
cargo build --release
cargo install --path . --force

# quick setup with openrouter
zeroclaw onboard --api-key sk-... --provider openrouter

# chat
zeroclaw agent -m "Hello, ZeroClaw!"

3. NanoClaw

ℹ️ OpenClaw's alternative that runs entirely in a container for security.

NanoClaw is basically the same thing but runs completely isolated inside a Docker container. The whole idea is simple: keep the codebase small, and put the risky stuff (bash, file access, tools) inside an isolated container so it can only touch what you explicitly mount.

That's pretty much the idea of NanoClaw.

What makes it different?

Container isolation by default: runs in Apple Container (macOS) or Docker (macOS/Linux), with filesystem isolation.
Per-chat sandboxing: each group/chat can have its own memory and its own mounted filesystem, separated from others.
Built on Anthropic’s Agents SDK: it’s basically designed to work nicely with Claude’s agent tooling and Claude Code.
WhatsApp + scheduled jobs: message it from your phone, and set recurring tasks that ping you back.

Quick start

git clone https://github.com/gavrielc/nanoclaw.git
cd nanoclaw
claude

Then run /setup. Claude Code handles everything: dependencies, authentication, container setup, and service configuration.

Here's a quick demo: 👇

4. nanobot

ℹ️ Ultra lightweight AI assistant built with Python.

Nanobot, as the name suggests, is quite small. The core agent is about ~4,000 lines of code, and the repo even publishes a live count you can verify with their script. That is the whole vibe: small enough that you can actually read it, trust it, and change it.

What makes it different?

Core size metric: ~4,000 LOC, with a “real-time” line count shown in the README (and a script to verify).
MCP support (fresh): added 2026-02-14, so it can plug into MCP tool servers without you reinventing the plumbing.
Runs where you already are: built-in “gateway” mode supports a bunch of chat surfaces like Telegram, Discord, WhatsApp, Slack, Email, and more.

Quick Start

pip install nanobot-ai

nanobot onboard
nanobot agent          # local interactive chat
nanobot gateway        # run it as a chat bot (Telegram, Discord, WhatsApp, etc)

Here's a quick architecture:

Here's a video to give you an idea of how it works: 👇

5. memU Bot

ℹ️ Built for 24/7 proactive agents designed for long-running use.

memU Bot is built for people who want an agent that keeps running and becomes more useful over time, instead of resetting to zero every time you open a new chat.

The site definitely looks like it was coded by a 12-year-old 😭, but don’t let that scare you off, because the product underneath is really good.

Under the hood, it’s tied to memU, NevaMind’s memory framework for long-running proactive agents, with a focus on reducing long-run context cost by caching insights.

What makes it different?

Always-on + proactive: it’s designed to sit in the background and capture intent (not just respond to prompts).
Memory system that scales: memU treats memory like a file system (categories, memory items, cross-links), so the agent can fetch relevant fragments instead of shoving the whole history into every request.

Quick start

It's a bit more involved than other options.

If you just want the product (memU Bot):

Go to memu.bot, enter your email, and get the download link they send you.
Install it like a normal desktop app (they provide a macOS .dmg in the tutorial flow).
Start it, connect the channel you want (Telegram, etc.), and let it run so it can build memory over time.

git clone https://github.com/NevaMind-AI/memU.git
cd memU

# Requires Python 3.13+
pip install -e .

# set your key (OpenAI is the default in their quick tests)
export OPENAI_API_KEY="your_api_key"

# quick test using in-memory storage
cd tests
python test_inmemory.py

Want persistent memory backed by Postgres + pgvector?

docker run -d \
  --name memu-postgres \
  -e POSTGRES_USER=postgres \
  -e POSTGRES_PASSWORD=postgres \
  -e POSTGRES_DB=memu \
  -p 5432:5432 \
  pgvector/pgvector:pg16

export OPENAI_API_KEY="your_api_key"
cd tests
python test_postgres.py

They also provide a small runnable "proactive loop" example if you want to see the behavior without going through tests:

cd examples/proactive
python proactive.py

There's also a Cloud version which you can try out as well.

It might be worth checking this out: 👇

If you know of any other useful OpenClaw alternative tools that I haven't mentioned in this article, please share them in the comments section below. 👇🏻

That concludes this article. Thank you so much for reading! 🫡

Shrijal AcharyaFollow

Full Stack SDE • Open-Source Contributor • Collaborator @Oppia • Mail for collaboration

🔥 Claude Opus 4.5 vs GPT 5.2 High vs Gemini 3 Pro: Production Coding Test ✅

Shrijal Acharya — Sun, 18 Jan 2026 12:41:12 +0000

Okay, so right now the WebDev leaderboard on LMArena is basically owned by the big three: Claude Opus 4.5 from Anthropic, GPT-5.2-codex (high) from OpenAI, and finally everybody's favorite, Gemini 3 Pro from Google.

So, I grabbed these three and put them into the same existing project (over 8K stars and 50K+ LOC) and asked them to build a couple of real features like a normal dev would.

Same repo. Same prompts. Same constraints.

For each task, I took the best result out of three runs per model to keep things fair.

Then I compared what they actually did: code quality, how much hand-holding they needed, and whether the feature even worked in the end.

⚠️ NOTE: Don't take the result of this test as a hard rule. This is just a small set of real-world coding tasks that shows how each model did for me in that exact setup and gives you an overview of the difference in the top 3 models' performance in the same tasks.

TL;DR

If you want a quick take, here’s how the three models performed in our tests:

Claude Opus 4.5 was the most consistent overall. It shipped working results for both tasks, and the UI polish was the best of the three. The main downside is cost. If they find a way to achieve this performance while reducing cost, it will actually be over for most other models.

GPT-5.2-codex (high) was one of the best. But it's obviously slower due to the higher reasoning. When it hit, the code quality and structure were great, but it needed more patience than the other two in this repo.

Gemini 3 Pro was the most efficient. Both tasks worked, but the output often felt like the minimum viable version, especially on the analytics dashboard.

💡 If you want the safest pick for real “ship a feature in a big repo” work, Opus 4.5 felt the most reliable in my runs. If you care about speed and cost and you’re okay polishing UI yourself, Gemini 3 Pro is a solid bet.

Test Workflow

For the test, we will use the following CLI coding agents:

Claude Opus 4.5: Claude Code (Anthropic’s terminal-based agentic coding tool)
Gemini 3 Pro: Gemini CLI
GPT-5.2 High: Codex CLI

Here’s the repo used for the entire test: iib0011/omni-tools

We will check the models on two different tasks:

Task 1: Add a global Action Palette (Ctrl + K)

Each model is asked to create a global action menu that opens with a keyboard shortcut. This feature expands on the current search by adding actions, global state, and keyboard navigation. This task checks how well the model understands current UX patterns and avoids repetition without breaking what's already in place.

Task 2: Tool Usage Analytics + Insights Dashboard

Each model had to add real usage tracking across the app, persist it locally, and then build an analytics dashboard that shows things like the most used tools, recent activity, and basic filters.

We’ll compare code quality, token usage, cost, and time to complete the build.

💡 NOTE: I will share the source code changes for each task by each model in a .patch file. This way, you can easily view them on your local system by cloning the repository and applying the patch file using git apply <path_file_name>. This method makes sharing changes easier.

Real-world Coding Tests

Test 1: Add a global Action Palette (Ctrl + K)

The task is simple: all models start from the same base commit and then follow the same prompt to build what is asked in the prompt.

And obviously, as mentioned, I will evaluate the response from the model from the "Best of 3."

Let's start off the test with something interesting:

Here's the prompt used:

This project already has a search input on the home page that lets users find tools. I want to add an improved, global version of this idea that works as an **Action Palette**, similar to what you see in editors like VS Code.

**What to build**

* Pressing **Ctrl + K** (or Cmd + K on macOS) should open a centered action palette overlay from anywhere in the app.
* The palette should support:
  * Searching and navigating to tools (reuse existing tool metadata)
  * Executing actions, such as:

    * Toggle dark mode
    * Switch language
    * Toggle user type filter (General / Developer)
    * Navigate to Home and Bookmarks
    * Clear recently used tools

* Fully keyboard-driven experience:

  * Type to filter
  * Arrow keys to navigate
  * Enter to execute
  * Escape to close

**Notes**

* This should not replace the existing home page search. Think of it as a more powerful, global version that combines navigation and actions.
* The implementation should follow existing patterns, styling, and state management used in the codebase.

GPT-5.2-Codex (high)

GPT-5.2 handled this surprisingly well. The implementation was solid end to end, and it basically one-shotted the entire feature set, including i18n support, without needing multiple correction passes.

That said, it did take a bit longer than some other models (~20 minutes), which is expected since reasoning was explicitly set to high. You can clearly see the model spending more time thinking through architecture, naming, and edge cases rather than rushing to output code. The trade-off felt worth it here.

The token usage was noticeably higher due to the reasoning set to high, but the output code reflected that.

Here's the demo:

You can find the code it generated here: GPT-5.2 High Code

Cost: ~$0.9-1.0
Duration: ~20 minutes (API time)
Code Changes: +540 lines, minimal removals
Token Usage:
- Total: ~203k
- Input: ~140k (+ cached context)
- Output: ~64k
- Reasoning tokens: ~47k

💡 NOTE: I ran the exact same prompt with the same model using the default (medium) reasoning level. The difference was honestly massive. With reasoning set to high, the quality of the code, structure, and pretty much everything jumps by miles. It’s not even a fair comparison.

Claude Opus 4.5

Claude went all in and prepared a ton of different strategies. At the start, it did run into build issues, but it kept running the build until it was able to fix all the build and lint issues.

The entire run took me about 7 minutes 50 seconds, which is the fastest among the models for this test. The features all worked as asked, and obviously, the UI looked super nice and exactly how I expected.

Here's the demo:

You can find the code it generated here: Claude Opus 4.5 Code

To be honest, this exceeded my expectations; even the i18n texts are added and displayed in the UI just as expected. Absolute cinema!

Cost: $0.94
Duration: 7 min 50 sec (API Time)
Code Changes: +540 lines, -9 lines

Gemini 3 Pro

Gemini 3 got it working, but it's clearly not on the same level as GPT-5.2 High or Claude Opus 4.5. The UI it built is fine and totally usable, but it feels a bit barebones, and you don't get many choices in the palette compared to the other two.

One clear miss is that language switching does not show up inside the action palette at all, which makes the i18n support feel incomplete even though translations technically exist.

Here's the demo:

You can find the code it generated here: Gemini 3 Pro Code

Cost: Low (helped significantly by cache reads)
Duration: ~10 minutes 49 seconds (API Time)
Code Changes: +428 lines, -65 lines
Token Usage:
- Input: ~79k
- Cache Reads: ~536k
- Output: ~10.7k
- Savings: ~87% of input tokens served from cache

Overall, Gemini 3 lands in a very clear third place here. It works, the UI looks fine, and nothing is completely broken, but compared to the depth, completeness, and polish of GPT-5.2 High and Claude Opus 4.5, it feels behind.

Test 2: Tool Usage Analytics + Insights Dashboard

This test is a step up from the action palette.

You can find the prompt I've used here: Prompt

GPT-5.2-Codex (high)

GPT-5.2 absolutely nailed this one.

The final result turned out amazing. Tool usage tracking works exactly as expected, data persists correctly, and the dashboard feels like a real product feature. Most used tools, recent usage, filters, everything just works.

One really nice touch is that it also wired analytics-related actions into the Action Palette from Test 1.

It did take a bit longer than the first test, around 26 minutes, but again, that’s the trade-off with high reasoning. You can tell the model spent time thinking through data modeling, reuse, and avoiding duplicated logic. Totally worth it here.

Here’s the demo:

You can find the code it generated here: GPT-5.2 High Code

Cost: ~$1.1–1.2
Duration: ~26 minutes (API time)
Code Changes: Large multi-file update, cleanly structured
Token Usage:
- Total: ~236k
- Input: ~162k (+ heavy cached context)
- Output: ~75k
- Reasoning tokens: ~57k

GPT-5.2 High continues to be slow but extremely powerful, and for a task like this, that’s a very good trade.

Claude Opus 4.5

Claude Opus 4.5 did great here as well.

The final implementation works end to end, and honestly, from a pure UI and feature standpoint, it’s hard to tell the difference between this and GPT-5.2 High. The dashboard looks clean, the data makes sense, and the filters work as expected.

Here’s the demo:

You can find the code it generated here: Claude Opus 4.5 Code

Cost: $1.78
Duration: ~8 minutes (API Time)
Code Changes: +1,279 lines, -17 lines

Gemini 3 Pro

Gemini 3 Pro gets the job done, but it clearly takes a more minimal approach compared to GPT-5.2 High and Claude Opus 4.5.

That said, the overall experience feels very bare minimum. The UI is functional but plain, and the dashboard lacks the polish and depth you get from the other two models.

Also, it didn't quite add the button to view the analytics right in the action palette, similar to the other two models.

Here’s the demo:

You can find the code it generated here: Gemini 3 Pro Code

Cost: Low, with heavy cache utilization
Duration: ~5 minutes (API Time)
Code Changes: +351 lines, -3 lines
Token Usage:
- Input: ~67k
- Output: ~7.1k
- Savings: ~85%+ input tokens served from cache

Overall, Gemini 3 Pro remains efficient and reliable, but in a comparison like this, efficiency alone is not enough. 🤷‍♂️

Conclusion

At least from this test, I can conclude that the models are now pretty much able to one-shot a decent complex work, at least from what I tested.

Still, there have been times when the models mess up so badly that if I were to go ahead and fix the problems one by one, it would take me nearly the same time as building it from scratch.

If I compare the results across models, Opus 4.5 definitely takes the crown. But I still don’t think we’re anywhere close to relying on it for real, big production projects. The recent improvements are honestly insane, but the results still don’t fully back them up.

For now, I think these models are great for refactoring, planning, and helping you move faster. But if you solely rely on their generated code, the codebase just won’t hold up long term.

I don't see any of these recent models as “use it and ship it” for "production," in a project with millions of lines of code, at least not in the way people hype it up.

Let me know your thoughts in the comments.

Shrijal AcharyaFollow

Full Stack SDE • Open-Source Contributor • Collaborator @Oppia • Mail for collaboration

Ministral 3 3B Local Setup Guide with MCP Tool Calling 🔥

Shrijal Acharya — Wed, 24 Dec 2025 16:26:00 +0000

Everyone’s talking about Ministral 3 3B, so I wanted to see what the hype is about. 🤨

Let's test it properly. We’ll start with the fun part and run it directly in the browser using WebGPU, fully local.

Then we’ll switch to the practical setup and run a quantized version with Ollama, plug it into Open WebUI, and test real tool calling. First with small local Python tools, then with remote MCP tools via Composio.

We will cover a few specs and then move on to practical tests, so let's jump in.

What’s Covered?

In this hands-on guide, you’ll learn about the Ministral 3 3B model, how to run it locally, and how to get it to perform real tool calls using Open WebUI, first with local tools and then with remote MCP tools via Composio.

What you will learn: ✨

What makes Ministral 3 3B special
How to run the model locally using Ollama (including pulling a quantized variant)
How to launch Open WebUI using Docker and connect it to Ollama
How to add and test local Python tools inside Open WebUI
How to work with remotely hosted MCP tools in Open WebUI

⚠️ NOTE: This isn’t a benchmark post. The idea is to show a practical setup for running a small local model with real tools, then extending it with remote MCP servers.

What's so Special?

Ministral 3 3B is the smallest and most efficient model in the Ministral 3 family. Mistral 3 includes three state-of-the-art small dense models: 14B, 8B, and 3B, along with Mistral Large 3, which is the most capable model to date from Mistral. All models in this family are open source under the Apache 2.0 license, which means you can fine-tune and use them commercially for free.

But the topic of our talk is the Ministral 3 3B model. At such a small size, it comes with function calling, structured output, vision capabilities, and most importantly, it is one of the first multimodal models capable of running completely locally in the browser with WebGPU support.

As Mistral puts it, this model is both compact and powerful. It is specially designed for edge deployment, offering insanely high speed and the ability to run completely locally even on fairly old or low-end hardware.

Here is the model’s token context window and pricing.

Token Context Window: It comes with a 256K token context window, which is impressive for a model of this size. For reference, the recent Claude Opus 4.5 model, which is built specifically for agentic coding, comes with a 200K token context window.

Pricing: Because it is open source, you can access it for free by running it locally. If you use it through the Mistral playground, pricing starts at $0.1 per million input tokens and $0.1 per million output tokens, which is almost negligible. It honestly feels like the pricing is there just for formality.

Besides its decent context window and fully open-source nature, these are the major features of Ministral 3 3B.

Vision: Enables the model to analyze images and provide insights based on visual content, in addition to text.

Multilingual: Supports dozens of languages, including English, French, Spanish, German, and more.

Agentic: Offers strong agentic capabilities with native function calling and JSON output, which we will cover shortly.

Local: Runs completely locally in your browser with WebGPU support.

Here is a small demo of the model running directly in the browser:

To actually get a feel for running a model locally in the browser, head over to this Hugging Face Space: mistralai/Ministral_3B_WebGPU

💡 NOTE: For most users, this will work out of the box, but some may encounter an error if WebGPU is not enabled or supported in their browser. Make sure WebGPU is enabled based on the browser you are using.

When you load it, the model files, roughly 3GB, are downloaded into your browser cache, and the model runs 100 percent locally with WebGPU acceleration. It is powered by Transformers.js, and all prompts are handled directly in the browser. No remote requests are made. Everything happens locally.

How cool is that? You can run a capable multimodal model entirely inside your browser, with no server involved.

Running Ministral 3 3B Locally

In the above example, you see how the model does such an amazing job with vision capabilities (live video classification). Now let's see how good this model is at making tool calls. We will test it by running the model locally on our system.

For this, there are generally two recommended approaches:

vLLM: Easy, fast, and cheap LLM serving for everyone.
Good old Ollama: Chat & build with open models.

You can go with either option, and generally speaking, the vLLM approach is a lot easier to get started with, and that's what I'd suggest, but...

I kept hitting a CUDA out-of-memory error, so I went with Ollama with the quantized model. I have had a great experience with Ollama so far. The model will be good enough for our use case demo.

Step 1: Install Ollama and Docker

If you don't have Ollama installed already, install it on your system by following the documentation here: Ollama Installation Guide.

It's not compulsory, but we will use the OpenWebUI through the Docker container, so if you plan to follow along, make sure you have Docker installed.

You can find the Docker installation guide here: Docker Installation.

Step 2: Download Ministral 3 3B Model and Start Ollama

Now that you have Ollama installed and Docker running, let's download the Ministral 3 3B model and start Ollama.

ollama pull ministral-3:3b

⚠️ CAUTION: If you don't have sufficient VRAM (Virtual RAM) and decent specs on your system, your system might catch fire when running the model. 🫠

If so, go with the quantized model instead as I did.

ollama pull ministral-3:3b-instruct-2512-q4_K_M

Now, start the Ollama server with the following command:

ollama serve

Once the model is downloaded and the server is running, you can quickly test it in the terminal itself.

ollama run ministral-3:3b-instruct-2512-q4_K_M "Which came first, the chicken or the egg?"

If you get a response, you are good to go.

Step 3: Run Ollama WebUI

To just talk with the model, the CLI chat with ollama run works perfectly, but we need to add some custom tools to our model.

For that, the easiest way is through the Ollama WebUI.

Download and run the Ollama WebUI with the following command:

docker run -d --network=host \
            -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
            -v open-webui:/app/backend/data \
            --name open-webui --restart always \
            ghcr.io/open-webui/open-webui:main

That command starts Open WebUI in Docker and sets it up to talk with the local Ollama server we just started with the ollama serve command.

docker run -d runs the container in the background (detached).
-network=host puts the container on the host network, so it can reach services on your machine using 127.0.0.1 (localhost).
e OLLAMA_BASE_URL=http://127.0.0.1:11434 tells Open WebUI where your Ollama server is.
v open-webui:/app/backend/data creates a persistent Docker volume so your Open WebUI chat history persists.
-name open-webui names the container.
-restart always makes it auto-start again after reboots or crashes.
ghcr.io/open-webui/open-webui:main is the image being run (the main tag).

To see if it all worked well, run this command:

docker ps

If you see a container with the name open-webui and the status Up, you are good to go, and you can now safely visit: http://localhost:8080 to view the WebUI.

Step 4: Add Custom Tools for Function Calling

Once you're in, you should see the new model ministral-3:3b-instruct-2512 in the list of models. Now, let's add our custom tools.

First, let's test it with local tools, which are smaller Python functions that the model can call.

Head over to the Workspace tab in the left sidebar, and in the Tools section, click on the "+ New Tool" button, and paste the following code: Local Tools

Now, in a new chat, try saying something like:

"What's 6 + 7?"

The model should use our added tool to answer the question.

Step 5: Add Remote MCP Tools for Function Calling

But that's not fun. 😪 We want to use tools that are hosted remotely, right?

For that, we can use Composio MCP, which is well-maintained and supports over 500 apps, so why not?

Now we need the MCP URL... For that, head over to Composio API Reference.

Add your API key and the user ID, and make a request. You should get the MCP URL returned to you in a JSON format. Keep a note of the URL.

💡 But is this the only way? No, this is just a quick way I use to get the URL back without any coding. You can get it using Python/TS code as well.

Now, you're almost there. All you need to do is add a new MCP server with this URL.

Click on your profile icon at the top, under Admin Panel, click on the Settings tab, and under External Tools, click on the "+" button to add external servers.

In the dialog box, make sure that you switch to MCP Streamable HTTP from OpenAPI, and fill in the URL and give it a nice name and description.

For Authentication, check None; we will handle authentication with the additional header "x-api-key". In the Headers input, add the following JSON:

{
  "x-api-key": "YOUR_COMPOSIO_API_KEY"
}

Once that's done, click on Verify Connection, and if everything went well, you should see "Connection Successful." That's pretty much all you need to do to use local and remote tools with the Ministral 3 3B model using Ollama.

The steps here are going to be pretty much the same for any other models that support tool calling.

Here's an example of the model returning a response after doing tool calls:

💡 NOTE: The model might take quite some time to answer the question and perform tool calls, and that pretty much depends on your system as well.

If you feel something is not working as expected, you can always view logs of your Ollama WebUI.

docker logs -f open-webui

Next Steps

This entire demo was done using Ollama and Ollama WebUI. See if you can get it working with vLLM and Ollama WebUI. The steps are going to be quite similar.

Just follow the docs for vLLM installation based on your system, and follow the guide which should get you going.

Let me know if you are able to make it work.

Conclusion

That's it. We just ran a lightweight, quantized Ministral 3 3B model in Ollama, wrapped it with Open WebUI, and showed it can perform real tool calling, both with small local Python tools and remote MCP tools via Composio.

You now have a simple local setup where the model can do more than just chat. The best part is, the steps won't change for other models, and you can quickly have your own local model that's entirely yours.

Now, try adding more toolkits and models (if your system can handle it) and just experiment. You already have a clear understanding of Ministral 3 3B and running models locally with Ollama. Apply it to your actual work, and you'll thank me later.

Well, that's all for now! I will see you in the next one. 🫡

✌️5 AI Document Parsing Tools That Actually Work 🚀🔥

Shrijal Acharya — Fri, 12 Dec 2025 12:35:04 +0000

Working with real world documents is still pain. PDFs, invoices, random exports from legacy tools. Half the work is just getting them into a clean, structured format your models can use. 😕

This post is about that first step. The one that usually gets ignored in demos and tutorials. Parsing and structuring the documents.

The tools here handle OCR, layout, tables, forms and file format so you can focus on the logic around them.

I am walking through a few I actually like using, with short code snippets you can drop straight into your own projects.

So, let's begin. 🚀

1. Tensorlake

💡 Document Ingestion API plus a serverless runtime for agentic data workflows

Tensorlake gives you two big things in one place:

A Document Ingestion API that turns messy files into clean markdown or structured JSON
A serverless platform to run agentic workflows on top of that data

You can send PDFs, Office files, images or raw text and get back well structured content with preserved layout. Long story short, you can treat it as a Document Ingestion API that handles PDFs, Office files, scans and images, then add agent style applications on top using their serverless runtime.

So, instead of handling OCR and background jobs with retry logic, you get one single platform that parses, chunks, classifies and then feeds the results into the agent or tools.

🤔 Is it for you?

If you are building invoice extractors, contract analyzers, or any complex data ingestion or agents that need to actually read documents, Tensorlake sits right in the middle of your stack as the ingestion and workflow layer.

Features

Multi format parsing: Parse PDFs, Office docs, spreadsheets, presentations, images and raw text to markdown or JSON.
Layout aware output: Preserves tables, sections and reading order so your RAG or search stays aligned with the original document, which many other tools miss.

Schema based extraction: Use JSON Schema or Pydantic models to pull out only the fields you care about.
Agentic runtime: Decorate Python functions, run them in sandboxes and let Tensorlake handle scaling, retries and state.

And many more...

Now, let's go through a quick code example of some common use cases.

Code Example: From PDF to markdown

First, install the SDK and use the DocumentAI client to upload a PDF, start a parse job and stream the markdown chunks once parsing is done.

pip install tensorlake

Now, to extract the text from a PDF, you can do something like:

from tensorlake.documentai import DocumentAI, ParseStatus

doc_ai = DocumentAI(api_key="your-api-key")

# Upload and parse document
file_id = doc_ai.upload("/path/to/document.pdf")

# Start parsing
parse_id = doc_ai.parse(file_id)

# Wait until parsing is complete
result = doc_ai.wait_for_completion(parse_id)

if result.status == ParseStatus.SUCCESSFUL:
    # Each chunk is a piece of clean markdown
    for chunk in result.chunks:
        print(chunk.content)

This is the basic flow you would use in a backend job that takes uploaded PDFs and turns them into LLM friendly text for something like RAG or search.

Once you have the chunks, you can push them straight into a vector store or a database.

You can have more control over parsing, like using structured parsing, which you can find here: Structured Extraction. I leave it up to you to explore more about this.

Code Example: Tiny agentic app on the Tensorlake runtime

To run a small agentic app on top of Tensorlake, it's as simple as:

import os
from agents import Agent, Runner
from agents.tool import WebSearchTool, function_tool
from tensorlake.applications import application, function, run_local_application, Image

# Container image with the dependencies the function needs
FUNCTION_CONTAINER_IMAGE = Image(
    base_image="python:3.11-slim",
    name="city_guide_image",
).run("pip install openai openai-agents")

@function_tool
@function(
    description="Gets the weather for a city",
    secrets=["OPENAI_API_KEY"],
    image=FUNCTION_CONTAINER_IMAGE,
)
def get_weather_tool(city: str) -> str:
    agent = Agent(
        name="Weather Reporter",
        instructions="Use web search to find current weather in the city",
        tools=[WebSearchTool()],
    )
    result = Runner.run_sync(agent, f"City: {city}")
    return result.final_output.strip()

@application(tags={"type": "example", "use_case": "city_guide"})
@function(
    description="Creates a simple city guide",
    secrets=["OPENAI_API_KEY"],
    image=FUNCTION_CONTAINER_IMAGE,
)
def city_guide_app(city: str) -> str:
    agent = Agent(
        name="Guide Creator",
        instructions="Make a friendly city guide that includes the current temperature",
        tools=[get_weather_tool],
    )
    result = Runner.run_sync(agent, f"City: {city}")
    return result.final_output.strip()

if __name__ == "__main__":
    city = "Paris"

    if not os.environ.get("OPENAI_API_KEY"):
        print("Error: OPENAI_API_KEY is not set")
        raise SystemExit(1)

    request = run_local_application("city_guide_app", city)
    response = request.output()
    print(response)

This above code creates a city guide application using OpenAI Agents with tool calls. I'm not going to explain the code here, as the blog will get unnecessarily longer.

You can find the explanation for this code in their GitHub README.

Deploying and running on Tensorlake Cloud

To run the application on Tensorlake Cloud, it first needs to be deployed.

Set TENSORLAKE_API_KEY in your shell session:

export TENSORLAKE_API_KEY="Paste your API key here"

Set OPENAI_API_KEY in your Tensorlake Secrets so that your application can make calls to OpenAI:

tensorlake secrets set OPENAI_API_KEY "Paste your API key here"

Deploy the application to Tensorlake Cloud:

tensorlake deploy examples/readme_example/city_guide.py

Run the remote test script found in examples/readme_example/test_remote_app.py:

from tensorlake.applications import run_remote_application

city = "San Francisco"

# Run the application remotely
request = run_remote_application("city_guide_app", city)
print(f"Request ID: {request.id}")

# Get the output
response = request.output()
print(response)

The application will execute on Tensorlake Cloud, with each function running in its own isolated sandbox.

To put it short, Tensorlake takes care of spinning up containers, injecting secrets and keeping the function durable so it can retry tool calls without you building your own queue system.

Here's a quick Tensorlake document ingestion demo to see it in action working with a complex document. 👇

2. Docling

Docling is from the IBM Research Team, licensed under MIT (free and open to commercial use), and turns PDFs, Office docs, images, audio and more into a unified DoclingDocument format. You can then export that into markdown, HTML, DocTags or lossless JSON and plug it straight into RAG, agents or search.

It runs locally and comes with strong layout and table understanding plus OCR and vision models for scanned or complex documents.

Features

Multi format parsing - PDF, DOCX, PPTX, XLSX, HTML, images, audio and more into one structured representation.
Advanced PDF understanding - Page layout, reading order, tables, code, formulas and images handled out of the box.
Multiple export targets - Export a single DoclingDocument to markdown, HTML, DocTags or structured JSON.
Local and privacy friendly - Designed to run completely locally.
Gen AI integrations - Hooks into LangChain, LlamaIndex, Haystack and others out of the box.

And many more...

Code Example - Convert and print markdown

The basic flow is intentionally simple: create a converter, give it a source and then decide how you want to export the result.

from docling.document_converter import DocumentConverter

source = "https://arxiv.org/pdf/2408.09869"  # can also be a local Path(...)
converter = DocumentConverter()
result = converter.convert(source)

markdown = result.document.export_to_markdown()
print(markdown)

This example shows the “one document in, one markdown document out” path that you would usually add into your indexing step.

This gives you one markdown document you can split into chunks and feed into a vector database.

Code Example: Same idea from the CLI

Docling also comes with a CLI. You can install it with the following command:

pip install docling

Now, you can run it using the following command:

# Convert a PDF at a URL to markdown on stdout
docling https://arxiv.org/pdf/2206.01062

# Use the GraniteDocling vision language model in the pipeline
docling --pipeline vlm --vlm-model granite_docling https://arxiv.org/pdf/2206.01062

Obviously, there are a few more complex use cases with a lot more flags you can add. For this, visit their documentation.

Here's a quick video by Red Hat to see it in action. 👇

3. Unstructured

Unstructured gives you an open source library plus a managed platform to turn unstructured content into structured data for LLM apps. It partitions PDFs, slides, HTML, Office files and images into a standard set of elements that downstream tools can easily consume.

On top of that, the ingest layer adds connectors, chunking and embeddings so you can build full ETL style pipelines around your document sources.

Features

One partition API autodetects file type and routes to the right parser for you.
LLM friendly outputs structured elements with text, metadata and coordinates when needed.
Source and destination connectors GitHub, S3 and more via the Ingest CLI and Python library.
Hosted Partition Endpoint offloads compute to their API when you want better models or scale.

Code Example: Quickstart with `partition`

This is the core pattern you will see in most examples, and it is enough to plug into a RAG pipeline.

from unstructured.partition.auto import partition

# Read and partition a document
elements = partition("example-docs/layout-parser-paper.pdf")

# Inspect a few elements
for el in elements[:5]:
    print(repr(el.category), "->", str(el)[:80], "...")

You end up with a list of elements that know their category, which makes it easy to filter for titles, paragraphs or tables before you use it further.

Code Example: Batch processing with Ingest CLI

For real projects you usually need to process many files at once and save the outputs somewhere. It comes with an ingest CLI and is built for exactly that.

# Chunk and partition an entire folder of files
unstructured-ingest \
  local \
    --input-path $LOCAL_FILE_INPUT_DIR \
    --output-dir $LOCAL_FILE_OUTPUT_DIR \
    --chunking-strategy by_title \
    --chunk-max-characters 1024 \
    --partition-by-api \
    --api-key $UNSTRUCTURED_API_KEY \
    --partition-endpoint $UNSTRUCTURED_API_URL \
    --strategy hi_res

This runs a full pipeline that reads documents from LOCAL_FILE_INPUT_DIR, partitions them with the hi_res strategy, chunks them by title and writes the structured outputs into your output directory. From there, you can index or analyze them however you like.

Here's a quick API quickstart to get an idea. 👇

4. Amazon Textract

Amazon Textract is AWS’s managed OCR and document analysis service that pulls text, handwriting, layout and structured data out of scanned documents and PDFs.

It runs inside your AWS account, plugs into services like S3, Lambda, SNS and SQS, and is used at scale by companies like PayTM for document workflows.

Features

Structured extraction pulls data from tables, forms and key value pairs, not just plain text.
Layout and handwriting support detects paragraphs, titles, layout elements and handwritten text in scans.
Works naturally with S3, Lambda, SNS, SQS and other AWS services.
Sync and async APIs low latency calls for single pages plus batch jobs for large multipage docs.
Security and compliance encryption, IAM and regional controls for regulated workloads.

Code Example: Detect text from a local file

This is the basic pattern if you just want the text out of a document. You read the file as bytes, call detect_document_text and print the lines Textract finds.

import boto3

textract = boto3.client("textract")  # uses your AWS credentials

file_path = "sample-doc.png"  # can be any image format

with open(file_path, "rb") as f:
    image_bytes = f.read()

response = textract.detect_document_text(
    Document={"Bytes": image_bytes}
)

for block in response["Blocks"]:
    if block["BlockType"] == "LINE":
        print(block["Text"])

What is happening here:

Textract analyzes the image or PDF and returns a list of Blocks that represent words, lines and other elements.
You filter for blocks of type LINE and print their Text, which is enough for many basic OCR use cases or as a first step before sending text into an LLM.

Code Example: Extract tables and forms from S3

To pull structured data from forms and tables, you use analyze_document with the FORMS and TABLES feature types and point Textract at a document in S3.

import boto3

textract = boto3.client("textract")

bucket_name = "my-doc-bucket"
object_key = "invoices/invoice-001.png"

response = textract.analyze_document(
    Document={
        "S3Object": {
            "Bucket": bucket_name,
            "Name": object_key,
        }
    },
    FeatureTypes=["FORMS", "TABLES"],
)

print(f"Found {len(response['Blocks'])} blocks")

# Quick peek at found tables
for block in response["Blocks"]:
    if block["BlockType"] == "TABLE":
        print("Detected a table with Id:", block["Id"])

There is a lot of other complex stuff that you can do with Textract. For more details, check out the Textract documentation.

In production you usually wire this up with S3 triggers and Lambda so new documents are picked up and processed by themselves.

Here's a quick intro to Amazon Textract. 👇

5. Google Cloud Document AI

Document AI is Google Cloud’s document stack that gives you ready made processors for invoices, receipts, forms, IDs and general OCR. You pick a processor, send it a file and get back a Document object with text, structure, entities and layout info, not just raw strings.

The nice part is how it fits into the rest of GCP (Google Cloud Platform). You can drop files into Cloud Storage, trigger processing with Pub/Sub or Cloud Functions or Cloud Run, then push clean data into BigQuery or your app.

Use it when you want:

Prebuilt processors - invoice, receipt, form, ID and general OCR processors that work out of the box.
Tables and forms - key value pairs and tables straight from scanned PDFs and images.
Custom models - custom extractors, classifiers and splitters when your docs do not match the prebuilt ones.
Cloud pipelines - runs close to Cloud Storage, Cloud Run and Vertex AI so it is easy to wire into existing GCP setups.

Code Example: Send a PDF and read the text

This is the usual Python flow. You create a processor in the console, grab its ID, then call it from your code.

from google.cloud import documentai

project_id = "your-project-id"
location = "us"
processor_id = "your-processor-id"
file_path = "path/to/document.pdf"

client = documentai.DocumentProcessorServiceClient()

name = client.processor_path(project_id, location, processor_id)

with open(file_path, "rb") as f:
    file_bytes = f.read()

raw_document = documentai.RawDocument(
    content=file_bytes,
    mime_type="application/pdf",
)

request = documentai.ProcessRequest(
    name=name,
    raw_document=raw_document,
)

result = client.process_document(request=request)
doc = result.document

print(doc.text[:1000])

You send raw bytes plus the MIME type, Document AI runs the selected processor and you get back a Document object. For quick use cases, grabbing doc.text is enough.

Code Example: Turn a parsed form into fields

If you use a form style processor, Document AI already marks fields as key value pairs, which you can loop over and map into your own schema.

def clean(text: str) -> str:
    return text.replace("\n", " ").strip()

form_doc = doc  # from the previous example. see above

fields = []

for page in form_doc.pages:
    for field in page.form_fields:
        name = clean(field.field_name.text_anchor.content)
        value = clean(field.field_value.text_anchor.content)
        conf = field.field_value.confidence
        fields.append((name, value, conf))

for name, value, conf in fields:
    print(f"{name}: {value} (conf {conf:.2f})")

This is the point where a scanned form basically becomes a Python dict. From here, you can push the data into BigQuery, Firestore or any service you use on GCP.

This is just a start, and there's a lot more to it. Visit the documentation to learn more.

Here's a quick introduction to Google Cloud Document AI. 👇

Conclusion

If you think of any other handy AI tools that I haven't covered in this article, do share them in the comments section below. ✌️

So, that is it for this article. Thank you so much for reading! 🎉🫡

✨Gemini 3 Pro vs GPT 5.1: Which One Codes Better? 🚀

Shrijal Acharya — Tue, 25 Nov 2025 14:02:17 +0000

Gemini 3 Pro just dropped, and it is already getting a lot of attention for its reasoning and long context abilities.

But now, the natural question is, "How well does it code?"

And does it actually outperform GPT 5.1 Codex, which, in my tests, has been the best so far (better than Claude 4.5 Sonnet) on real tasks?

To find out, I put it side by side with GPT 5.1 and tested both models on two fundamental tasks: a UI build and a complete agent workflow.

We will go through the results in a moment, but first, let's have a quick TL;DR and a refresher on Gemini 3.

TL;DR

If you want a quick take, here is how both models performed in the test:

Gemini 3 Pro handled both the UI task and the agent build more cleanly, requiring very few follow-ups.
The most significant difference showed up in the agent test, where Gemini 3 Pro actually followed the documentation and built it well. At the same time, GPT-5.1 had a few issues with the agent implementation.
Even though in our test it's not very obvious, for everyday coding, Gemini 3 Pro feels like the safer bet.
Latency is higher than GPT-5.1 Codex and can be frustrating for minor fixes.

If you are doing real coding or building agents, Gemini 3 Pro is the better choice right now.

⚠️ NOTE: The goal of this test is to show how much of a jump Gemini 3 Pro is compared to the best models we had before its release.

Brief on Gemini 3 Pro

Gemini 3 was released this November 18th with state-of-the-art reasoning, pushed directly to Search with no waiting period or beta testing, unlike most Google models.

Gemini 3 is Google's most intelligent model family to date, and is the state-of-the-art (SOTA) across a variety of benchmarks.

As you can see, this model makes almost all the models we had till now, including GPT-5.1, Claude 4.5 Sonnet, look outdated. The difference in their stats is just insane.

From these, here are the ones I find the most incredible:

LMArena Elo: 1501 (crossing GPT-5.1 and Claude Sonnet 4.5)
Humanity's Last Exam: 37.5% without tools (hardest AGI benchmark available)
GPQA Diamond: 91.9% (PhD-level science reasoning)
AIME 2025: 95% (high school mathematics)
MathArena Apex: 23.4% (new state-of-the-art)

"Gemini 1 introduced native multimodality and long context to help AI understand the world. Gemini 2 added thinking, reasoning and tool use to create a foundation for agents.

Now, Gemini 3 brings these capabilities together – so you can bring any idea to life."

~ Google Deepmind

So, it's built by putting together the good sides of the earlier Gemini models.

Talking about its specs, it comes with a huge 1M input token context window and an output token limit of 64K.

🤔 What's the difference from Gemini 2.5 Pro?

Specs are almost the same. Both 2.5 Pro and 3 Pro give you about a 1M input window, 64K output and full multimodal support. But Gemini 3 Pro is a clear upgrade in how it thinks with that context. It scores roughly 10 to 20 per cent higher on many reasoning benchmarks, takes a massive jump on complex tests like ARC-AGI-2 and SimpleQA, and performs better at long-context retrieval at the 1M scale.

There's just a percentage improvement in hallucination rate compared to Gemini 2.5 Pro, and Claude leads by a significant margin on this metric, which should've been better. We will test it shortly.

Google is also clearly tuning this thing for real "agent"- style workflows, not just limited to chat. In practice, that means Gemini 3 Pro is built to run tools, browse, execute code, and integrate into your agentic workflows. As said, it's available everywhere; you can find it in all Google products.

Google has launched it everywhere, so you can already get the idea of how confident they are in this model.

Google has also launched Deep Think Mode alongside Gemini 3 Pro, which isn't public yet, but it uses extended reasoning chains to work through complex problems. It's like taking a moment to think before answering user questions. It offers improvement over the raw Gemini 3 Pro.

Humanity's Last Exam: 41.0% (vs. 37.5% with standard Gemini 3 Pro)
GPQA Diamond: 93.8% (vs. 91.9% with Gemini 3 Pro)

They are running safety checks before the public release to ensure it isn't misused.

To learn more about the model, see its model card here: Gemini 3 Pro Model Card.

Coding Comparison

Now, let's start with the coding test. We will be comparing Gemini 3 Pro with GPT-5.1 on two tasks.

UI Test: I've already seen dozens of videos and demos praising Gemini 3 for its frontend coding, so we will run one to see how well it handles a basic task.
Building an Agent: We will make an agent from scratch, as it's also a model known to be great at agentic workflows.

1. UI Test - Clone Windows 11

Prompt: You can find the prompt I've used here: Prompt - UI Test

Response from Gemini 3 Pro:

You can find the code it generated here: Source Code

Here's the output of the program:

This is by far the best response I've gotten from any AI model to this prompt to date. This is just too good. The overall feel does resemble Windows 11. The choice of icons could have been better, but the overall look and feel are really, really close.

On this question, I'm not looking at how the model implements logic, but rather its pure frontend skills, and this one has done it well. Also, the wallpaper-changing feature is cool and works.

It took about 10 minutes to implement it all. The total output token usage was around 30K, including the README, LICENSE, and a few other document files it generated on its own. So, be careful when using YOLO mode in Gemini CLI. 😑

Response from GPT-5.1 codex:

You can find the code it generated here: Source Code

Here's the output of the program:

This is super close to Gemini's implementation, but there's a lot of stuff that feels missing and could be improved.

Even though the look and feel of the output from Gemini 3 Pro is much better, the code for this question by this model is better than that of Gemini 3 Pro. If you look into how it's structured, how types are declared, and all that, this is much better.

2. Building a Calendar Agent

To build the agent, let's use something different. This time, we will be using Composio's Tool Router (Beta), which automatically discovers, authenticates, and executes the right tool for any task without you having to manage authentication and wire everything per integration. 🔥

💁 Prompt: You can find the prompt I've used here: Prompt - Agent Coding

Response from Gemini 3 Pro:

You can find the code it generated here: Source Code

Here's the output of the program:

This works. It's not the best implementation with the best-written code style, but it simply works. Minimal yet functional. It's fascinating how well this model understands the context from the provided link and finds all the pieces it needs to put together.

There are still many type issues and a few code implementation issues, but all in all, it's hanging by a small thread, yet surprisingly, it just works.

In terms of time, it took about 5 minutes to build this entire agent. And, just to be clear, it's not a one-shot; I had to help it with a little bit of setup.

The entire test took around 14K output tokens, and since the prompt I gave is very verbose, the input token count is significantly higher.

Response from GPT-5.1:

Here's the output of the program it got me first:

For real, it just mocked the entire agent route. There's no composio tool router used. This is so depressing. All it did was create the UI and mock the whole agent implementation.

You can find the agent route code that it generated here: Link

Now, I had to copy and paste some parts of the tool router documentation manually, and with a lot of hand-holding this time and showing the Gemini 3 code as a reference, I got it somewhat working. But still, the UI is messed up, and the cards don't show.

Here's the final output of the program:

You can find the code it generated here: Source Code

Conclusion

Gemini 3 Pro kind of lived up to the hype in these tests. As for the code quality, both completed the test in one go for the most part, and the code is modular and follows best practices. However, sometimes GPT-5.1 provided much better code than Gemini 3 Pro. 🤷‍♂️

This model Gemini 3 is a lot better in agent-styled workflows, and even the UI, and it shows. Really looking to see how the Deep Think mode improves things once it rolls out.

If you're still curious to learn more, there's one blog that I recommend that you go through, "Three Years from GPT-3 to Gemini 3" by Ethan Mollick, that walks you through the whole AI arc in these years and gives you some intuition on what's changed, beyond just the benchmark numbers.

It's still early, and results may vary with different prompts, but for practical coding tasks, Gemini 3 Pro is a top model.

Try it with your own projects and you will see what I mean. Share your results if you test it on something real. ✌️

🧠 Cursor Composer 1 vs Claude 4.5 Agent Build Comparison ⚡

Shrijal Acharya — Wed, 12 Nov 2025 13:45:23 +0000

The AI coding race is heating up again. After OpenAI, Anthropic, and Google, Cursor has stepped into the game with its new model, Composer 1, a coding-focused agent model that’s said to be 4x faster than other models with similar intelligence. 🤨

It’s said to output code at lightning speed, reason through large contexts, and even outperform models like GPT-5 and Claude Sonnet in engineering workflows.

That’s a bold claim, so I decided to test it myself. In this post, we’ll see how Composer 1 performs when building an actual agent and to make things fair, I’ll put it head-to-head with Claude Sonnet 4.5, one of the most consistent coding models out there.

TL;DR

If you just want the results, here’s a quick rundown of how both models performed in building a simple agent:

Composer 1 produced the most complete implementation and had the fastest output. It coded the entire agent in under 3 minutes, though it needed two small follow-ups.
Claude Sonnet 4.5 also got the job done, but sometimes used outdated API methods, even though I clearly provided the latest documentation for a Python package. It tends to rely more on its training data than the instructions you give it.

In terms of code quality and implementation, there’s not much difference. That said, Sonnet 4.5 burned almost twice the tokens, while Composer 1 delivered similar results in half the time (not 4x) with far fewer tokens. It’s efficient, fast, and feels like a strong pick for everyday coding.

Brief on Cursor Composer

Since this model dropped only a few weeks ago, here’s a short refresher.

Composer 1 is the first agent-focused coding model from Cursor. They claim it’s about 4x faster than similarly intelligent models.

(By the way, what even is the Cursor Bench Score? Can't really trust all the metrics blindly. 🤷‍♂️)

It is said to be a mixture-of-experts (MoE) language model supporting long context generation and understanding. As mentioned earlier, it's built especially for building agents or general software engineering workflows in mind through Reinforcement Learning (RL).

They've positioned it as a frontier coding model, with top-tier intelligence that seems to surpass all its peer models with similar intelligence. It comes with a 250 tokens per second output speed, which is roughly twice as fast as most coding models and about 4–5 times faster than some reasoning models.

If we talk about the pricing, it's priced the same as GPT-5, which is $1.25 per million input and $10 per million output tokens, which is pretty affordable for what it promises.

It is clearly aimed at replacing models like GPT-5 and Claude Sonnet 4.5 for software development. Although it is said that these models beat Composer 1 in pure coding intelligence, they run much slower.

So, we can say that Composer comes with a bit of an accuracy trade-off for a lot of speed gain, which could be a great option for some but not for everyone.

But all of these claims come from Cursor's own benchmark. It's up to you whether you decide to trust it or not. 🤷‍♂️

Coding Comparison

Alright, enough talk. Let’s see how Composer 1 stacks up against Sonnet 4.5 in actual coding.

Since Composer is pitched as an “agentic” model, I wanted to see how well it could handle building an AI agent from scratch.

To build the agent, we will be using Composio's Tool Router (Beta), which automatically discovers, authenticates, and executes the right tool for any task without you having to manage authentication and wire everything per integration. 🔥

💡Fun Fact: Tool Router is what powers complex agentic products like Rube.

We’ll compare code quality, token usage, cost, and time to complete the build.

What's the plan?

I asked both models to build a small Python agent that takes a YouTube URL, finds the interesting parts of the video, and posts a Twitter thread on behalf of the user.

💁 Prompt: "Create an AI Agent in Python when given a YouTube URL, The agent will find the interesting part of the video and post a tweeter thread on behalf of the user. For this, use the Composio's Tool Router: https://docs.composio.dev/docs/tool-router/quick-start. Note: Don’t use Composio’s YouTube Integration, build a custom tool on your own using the YouTube Transcript API (to make things a little harder)."

Response from Composer 1

You can find the entire source code here: Composer 1 AI Agent with Tool Router

Here's the output of the program:

Composer was really fast with the response. Took a little over 3 minutes to code the first response, it did run into a small issue with the implementation of the YouTube transcript function, and adding it as a custom tool to the agent.

It did also run into usage of some types and functions from the modules, but nothing much severe here.

But after a few back and forth in two more prompts with a little help from my side, it was able to make all of it work.

In the overall, Composio part working with the Tool Router, it didn't really run into any problems.

Token usage was around 200K tokens. For the timing, the first response took roughly 3 minutes, but on the follow-ups, it was negligible.

It was not asked, but it did quite a good job with the code quality and the overall user interface of this CLI chat.

💁 One thing I found a bit irritating is the number of comments it writes; there's a comment for every single line, which is insane! For many, it could be great, but this definitely feels a bit too much.

Response from Sonnet 4.5

You can find the entire source code here: Claude Sonnet 4.5 AI Agent with Tool Router

Here's the output of the program:

Sonnet kinda disappointed me here. The code quality was fine, yet it repeatedly used the old YouTube Transcript API methods (get_transcript, list_transcripts) even after being shown the newer version.

I eventually had to fix that part myself. And for some reason, whenever I asked for a small change, Sonnet rewrote half the working code, which felt unnecessary and ate up tokens like crazy.

Its total token usage was nearly double that of Composer’s, around 427K tokens, and it took between about 10 minutes to finish the job.

To be fair, its implementation of the Tool Router itself was solid but quite a bit slower and heavier overall.

Summary

To summarize the results, there's not much difference I could find in the code quality or the implementation, both were able to read the Tool Router documentation and implement it well. But for some reason, it was getting tough to make Sonnet use the new API than what it's trained on.

Token usage and the time they took to implement are just not comparable. Claude used 427K tokens, which is 2.1 times the tokens used by Composer 1, which is roughly 200K. In terms of time, there's a significant difference, and I also had to do many more follow-ups for this compared to Composer.

Wrap Up!

This was a really quick test. You could ask it to add more features to the agent, and test both the model results, but I leave it to you. But even from this small run, Composer 1 stands out. ⚡

With more than half the time and far fewer tokens, it matched or even slightly outperformed Sonnet 4.5 in overall coding quality.

From my experience using it, I don’t think you’ll run into any major issues choosing Composer over Sonnet for everyday development. It’s fast, consistent, and honestly feels built for this exact kind of work.

Would love to hear if anyone else has benchmarked this model with cool real world projects. ✌️

💡How to Build ChatGPT Apps with Widgets using the ChatGPT Apps SDK and Next.js 🥶⚡

Shrijal Acharya — Mon, 03 Nov 2025 15:35:43 +0000

With the recent release of ChatGPT apps, especially the ChatGPT Apps SDK, developers can now build apps that run directly inside ChatGPT. 🤯

Currently, by default, OpenAI supports just the following apps: Booking.com, Canva, Coursera, Expedia, Figma, Spotify, and Zillow.

In the coming days, they plan to support developer-submitted apps by opening submissions later this year. This is a big moment for everyone who uses ChatGPT, especially developers who can build their own apps, and for the over 800 million ChatGPT users who get to try them.

So, you must know how to build your own apps with the ChatGPT Apps SDK. How cool would it be to create an app that supports over 500 apps and isn't limited to the default OpenAI-supported apps?

That's precisely what we'll cover, from understanding the SDK and running the project locally to temporarily hosting it on Ngrok to access it in ChatGPT.

So, without further ado, let's dive right in.

TL;DR

To quickly summarize what we'll cover in this blog post, here's what we'll go through:

What are ChatGPT apps and the Apps SDK?
Installing Ngrok to host your localhost project on the internet with one command.
How to use Rube to access OpenAI ChatGPT Apps.
How to implement widgets in Next.js with ChatGPT Apps SDK + Rube MCP.

If you work with Next.js and want to learn how to build custom widgets for your ChatGPT Apps, this is the right place to start.

What is ChatGPT Apps and the Apps SDK

ChatGPT Apps are third-party tools that you can run directly in your ChatGPT conversations. The best way to understand this is to think of it as a way to use these apps like Figma, Canva, Zillow, Spotify, and more, and do all sorts of work directly in them without ever leaving ChatGPT.

To give you a better overview, these are some things you can do with ChatGPT Apps:

Say "Spotify, create me a playlist for my study session," and it'll build you a nice playlist in Spotify and play it directly in your chat.

Say "Canva, create me a thumbnail for my blog post with this text," and it'll build you a nice thumbnail for your blog post.

You're seeing where this is headed. This is OpenAI's third attempt to make ChatGPT not just a chatbot, but an all-in-one platform with all apps directly available in it, so you never have to leave ChatGPT.

The first two were custom GPTs, but they didn't work well with the users. However, this is a powerful, more flexible approach that, if adopted, could mean ChatGPT becomes your all-in-one platform.

Well, then what's ChatGPT Apps SDK?

As the name suggests, it's pretty obvious; it's used to build apps that run inside ChatGPT. 🫠

To add more context, it's an open-source toolkit from OpenAI built on top of MCP that lets developers create apps that run directly in ChatGPT.

At a high level, this is how it works:

Your app (e.g., Canva, Figma, etc.) runs as an MCP server that exposes its tools and input/output schemas directly to ChatGPT.

Now, ChatGPT can invoke those tools and, optionally, render the UI components you provide in a sandbox.

Building a ChatGPT App in Next.js with Widgets

The source code mainly consists of basic React code, so I won't explain it from scratch here. It's a GPT app designed to display Google Calendar meeting details with widget support.

This should be a good starting point for you. Feel free to build something similar for your use case with any apps you prefer.

Begin by cloning the project repository using the command below:

git clone https://github.com/shricodev/chatgpt-apps-sdk-demo-composio.git

Step-1: Set Up Composio

ℹ️ We'll use Composio to add integrations support to our application. You can choose any integration you like.

Before moving forward, you need to obtain a Composio API key.

Go ahead and create an account on Composio, get your API key, and paste it into the .env file in the root of the project.

COMPOSIO_API_KEY=<YOUR_COMPOSIO_API_KEY>

For this demo, I'll be using Google Calendar, so head over to the Composio dashboard to access the auth config ID for Google Calendar.

Create the auth config for Google Calendar.

Create an auth config for Google Calendar. Note the external user ID as we will use it in the .env file.

Once done, copy the auth config ID (which starts with ac_). Now, add the auth config ID and the user ID to the .env file.

COMPOSIO_USER_ID=<YOUR_COMPOSIO_USER_ID>
CALENDAR_AUTH_CONFIG_ID=<YOUR_COMPOSIO_CALENDAR_AUTH_CONFIG_ID>

Your final .env file should look something like this:

COMPOSIO_API_KEY=<YOUR_COMPOSIO_API_KEY>
COMPOSIO_USER_ID=<YOUR_COMPOSIO_USER_ID>

CALENDAR_AUTH_CONFIG_ID=<YOUR_COMPOSIO_CALENDAR_AUTH_CONFIG_ID>

Install Dependencies and Start the Project

Once your environment variables are configured, install the project dependencies:

pnpm install

After installation is complete, start the project with:

pnpm run dev

By default, the app runs on port 3000. Double-check that it’s running on that port, as you’ll need this information later when setting up Ngrok.

Step-2: Expose Your App with Ngrok

Since ChatGPT isn't running locally on your machine, you can't use localhost:3000 when connecting to the app in ChatGPT.

You can host it on platforms like Vercel, but Ngrok is often faster and more convenient for development.

Ngrok lets you share your local project via a temporary public URL, which is perfect for quick testing without redeploying.

Even if you need to make changes, you won't have to push the changes to your repo to trigger the Vercel deployment. Ngrok can work directly from your local filesystem.

Install Ngrok

Make sure that you have Ngrok installed on your machine.

Visit this URL: Ngrok Installation Guide, and find the relevant steps for your machine.

If you're someone like me who prefers Docker, you can use the following command to pull the Ngrok public image from Docker Hub.

docker pull ngrok/ngrok

Use whichever installation method fits your workflow.

Start Ngrok

Make sure that the project is running locally and listening on port 3000, as we will be exposing it to the internet.

It's as simple as typing out this command:

ngrok http 3000 // Change to the port your app is running on

And if you've followed the Docker steps, run the following command:

docker run --net=host -it -e NGROK_AUTHTOKEN=<NGROK_AUTH_TOKEN> ngrok/ngrok:latest http 3000 // Change to the port your app is running on

This will give you a public URL to access the project. Keep a note of this as we'll need it when setting up ChatGPT to add our new app.

Make sure to replace <NGROK_AUTH_TOKEN> with your actual ngrok auth token.

You can find it in your Ngrok dashboard. Log in to your Ngrok account, and you'll find it in the dashboard.

Step 3: Connect Your App to ChatGPT

Now, you should have a public URL for your app. Let's add it to ChatGPT.

It should look something like this: https://topographical-unmagnifying-halle.ngrok-free.dev

Head over to ChatGPT settings, then under Additional Settings> Apps and Connectors, make sure Developer mode is turned on. This gives you access to add your own application.

Click Create, and fill in the following details:

MCP Server URL: The public URL you just got from Ngrok. Add /mcp at the end, because that's the endpoint in our code that handles the requests from ChatGPT.

For Name and Description, you can put anything you want (show your creativity!)

Authentication: Select No Authentication, as we'll handle authentication with Composio itself. Our app does not support OAuth by default.

See It in Action

Let's see how all of this adds up. Here's a quick demo to give you an idea of our application.

Creating a Google Calendar meeting and viewing the details directly from GPT with widgets? That's really cool.

Advanced: How to use Rube MCP with the ChatGPT Apps SDK?

You know what? You don’t need to worry about any of that if you don’t care about visual feedback or fancy widgets in ChatGPT. This is the right place to start.

💡 We only had to code all of that because I wanted to show you how to use Widgets with ChatGPT Apps + Rube MCP inside Next.js.

None of the coding is necessary. The whole point of ChatGPT apps is to give you direct access to your applications right inside ChatGPT, so if you want all your apps ready to go without extra setup, this is perfect.

Honestly, this is precisely what I’d recommend for your daily workflow. It’s simple, smooth, and gives you access to over 500 apps available on Rube. Pretty cool, right?

Here’s all you need to do:

Make sure that you are in Developer Mode as we discussed earlier.

In the same tab, click Create, and fill in the following details:
MCP Server URL: https://rube.app/mcp
For Name and Description, you can put anything you want (show your creativity!)

Make sure you set up OAuth authentication, as we'll be using it to access the tools in ChatGPT.

Now, click on Create.

It will now ask for some access; hit Allow.

If everything goes well, your app should be available on ChatGPT. Make sure that you see all six actions appropriately listed, as these are the core actions Rube uses to manage authentication, prepare tool calls, and stuff.

Here's all 6 Rube actions listed:

RUBE_CREATE_PLAN: Creates a complete step-by-step plan for LLMs.
RUBE_MULTI_EXECUTE_TOOL: Fast and parallel tool executor for tools discovered through RUBE_SEARCH_TOOLS.
RUBE_REMOTE_BASH_TOOL: Execute bash commands in a REMOTE sandbox for file operations, data processing, and system tasks.
RUBE_REMOTE_WORKBENCH: Process remote files or script bulk tool executions using Python code in a remote sandbox.
RUBE_SEARCH_TOOLS: Search for tools to execute the user task.
RUBE_MANAGE_CONNECTIONS: Manage connection with Rube.

This is to give you an idea of all the actions Rube will use to perform your tasks.

And... that's it.

Now, simply head over to your chat, use @<APP_NAME>, in my case @Rube MCP Server, and start talking.

As an example, try saying this:

"@ send an email to my ex at XYZ. Subject: Guess who. Body: Don’t worry, it’s just AI with Rube… or is it?"

(C’mon, try it, you’ll test two connections at once. 😉 Just kidding…)

Wrapping Up

Alright, now you’ve got a clear idea of how the ChatGPT Apps SDK works, how to set up a custom server powered by Rube, host it with Ngrok, and use it right inside ChatGPT or plug in Rube and get going without any coding at all if you don't care about widgets.

In this post, we walked through everything from building your own custom server with Rube and widget support in Next.js to skipping the code entirely if you want to move fast.

Well, that's all for this! I will see you in the next one.

Shrijal AcharyaFollow

Full Stack SDE • Open-Source Contributor • Collaborator @Oppia • Mail for collaboration

🔥Top 10 Make alternatives for building AI automation 🤖

Shrijal Acharya — Mon, 06 Oct 2025 15:07:39 +0000

This article lists the top 10 Make alternatives for building AI automation that you should definitely check out in 2025! 🔥

If you're into AI automation, these tools are a lifesaver. It does not matter if you're a developer or not; I'll list tools for both developers and non-developers, so feel free to choose whatever suits you.

TL;DR

If you just want to see the list, here’s each of the tools worth checking out 👇

For Developers
- Composio: Connect your AI agent with 500+ apps and APIs using one SDK.
- Pipedream: Deploy AI workflows in seconds with code-level control.
- Merge: Unified API for syncing data and integrations across categories.
- Nango: Developer infra for managing 500+ API integrations.
- Paragon: Add prebuilt or custom integrations to your product fast.
For Non-Developers
- Zapier: No-code automation with 8,000+ app connections.
- Rube: Hosted MCP server that connects your AI tools to 500+ apps.
- n8n: Open-source automation platform with full flexibility.
- Langflow: Low-code AI builder for RAG and multi-agent apps.
- Gumloop: No-code platform to create AI workflows visually.

Each tool serves a different purpose, so be sure to check each one to see which best fits your needs. ✌️

Developer Friendly

1. Composio

ℹ️ Developer-first platform to connect AI agents with 500+ apps, APIs, and workflows.

Composio is built for developers who want to connect their AI agent with 500+ apps, APIs, and workflows. It's a developer-first platform and a bridge that gives your agent access to hundreds of SaaS apps, APIs, and workflows out of the box.

Composio handles everything from building integrations, managing authentication per integration, to optimizing JSON schema for agents, all of this in one call.

Instead of manually building connectors for integrations (Slack, Notion, you name it...), you drop in Composio's SDK or API, and your agent can start taking action right away.

With Composio, you can:

Add 100+ ready-to-use integrations into your AI agent instantly.
Expose APIs and tools in a structured way for LLMs (Claude, GPT, Gemini, etc.) to consume.
Deploy production-ready agents faster without reinventing the wheel.
Extend workflows by mixing prebuilt connectors with your own custom logic.
There's a lot...

It is a must and the most reliable in my experience if you're building agentic apps or automation products that need to talk to external services. Instead of wiring up OAuth, rate limits, and sync logic yourself, Composio handles that for you.

Check out the docs to get started, or jump straight in by installing their SDK in your project.

Quick Start:

# Install SDK (TypeScript)
npm install @composio/core

# or (Python)
pip install composio

Check out this demo to see Composio in action for Python. 👇

For TypeScript, refer to this: Getting Started with Composio using TypeScript

💁 NOTE: There’s Rube which is a part of Composio if you’re looking for somewhat similar for non-developers which I’ll cover in the next section.

2. Pipedream

ℹ️ Prompt, run, and deploy AI agents in seconds.

Pipedream gives you a visual workflow builder and lets you drop into code when you want to. It’s built for developers who want speed without losing control.

Here’s what makes Pipedream useful:

It supports 2,800+ apps and APIs, so you can link your AI agents to many tools quickly.
You can write custom logic in Node.js, Python, Go, or Bash inside workflows whenever you need flexibility.
It handles OAuth, tokens, and integrations so you don’t have to reinvent those common parts.
For AI-heavy tasks, Pipedream offers code generation from prompts, making it easier to spin up agent logic.

Check out this quick demo to see Pipedream in action. 👇

3. Merge

ℹ️ Fast, secure integrations for your products and agents

Merge is all about simplifying integration. Instead of building connectors one by one, you use a single unified API. Combine that with their MCP (Model Context Protocol) support, and your AI agent can read/write across many systems without you wiring each integration manually.

Here’s how Merge helps you:

It covers many categories like accounting, ticketing, CRM, file storage, and more with a common data model.
You embed Merge Link to let users link their accounts with apps you support. It handles auth, permissions, etc.
The MCP server from Merge lets your AI agent treat all those integrations as “tools” it can call via MCP.
Merge gives you SDKs, sandboxes, and developer tools to build faster without reinventing everything.

Want to get a quick video overview? Here you go, the CEO Shensi Ding herself explains how Merge helps. 👇

4. Nango

ℹ️ Developer infrastructure for product integrations with 500+ APIs.

Nango is all about giving developers infrastructure so they don't have to build every connector from scratch. It provides tools and building blocks to manage auth, syncing, webhooks, and custom logic, all with full control over how data flows.

I don't see much advantage to using Nango over other tools I've mentioned, but it's worth giving a shot.

What Nango lets you do:

Ship integrations to 500+ APIs quickly with prebuilt templates, auth handling, rate-limit logic, and more.
Write Functions (TypeScript code) that run inside Nango for custom logic: data transformations, webhook handling, or special API quirks.
Sync data both ways (read & write), manage webhooks, and handle complex API workflows.
Self-host locally or use Nango’s cloud, with architecture built for reliability, observability, and scale.

Here’s an intro video demo to Nango. 👇

5. Paragon

ℹ️ Ship every integration your customers need with 130+ pre-built connectors.

Paragon is a tool that helps you add integrations to your product quickly. It comes with 130+ ready-made connectors, and you can also build your own custom ones on the same platform.

Here’s what Paragon gives you:

It handles authentication, token refresh, and API quirks so you don’t have to.
You can use its Custom Integration Builder to create new connectors in minutes when a prebuilt one doesn’t exist.
It supports embedding the Connect UI (for users linking accounts) or going headless if you want full control.
Your integration logic can run as workflows (with retries, debugging, concurrency) or in TypeScript for when custom code is needed.

Here's a quick video intro to Paragon. 👇

For Non-Developers

1. Zapier

ℹ️ The most connected no-code AI orchestration platform, integrating with 8,000+ apps.

Zapier is a veteran in the automation game, and now it’s evolving fast into an AI orchestration tool too. You build workflows (called “Zaps”) that let actions in one app trigger responses in another (no coding needed, as you guessed it 😉).

With Zapier, you can:

Automate repetitive tasks across multiple apps (Slack, Gmail, CRMs, etc.)
Use AI functions to route or act on data mid-workflow
Build “Interfaces” (custom forms/UIs) that feed into Zaps
Use “Tables” as lightweight databases for your workflows

And because Zapier supports thousands of apps, chances are the tools you already use are already supported.

Sounds cool? Here's a quick tutorial to get your hands on Zapier. 👇

2. Rube

ℹ️ MCP server that connects your AI tools with 500+ apps.

If you’ve come across the term MCP before, you know it stands for Model Context Protocol. In simple terms, it’s a bridge that lets AI models talk to external apps and services, giving them both data and the ability to take action.

Rube acts as a hosted MCP server that bundles integrations with popular tools like Slack, Gmail, Facebook, and many more. Instead of setting up servers and wiring APIs yourself, you instantly unlock access to over 500 apps right inside your AI chat tools.

To see what’s available, you can browse the Rube marketplace, which lists all the supported apps.

Getting started is simple:

Install Rube on your preferred platform, or
Sign up on the web app, connect an app, and test it directly in your browser.

Here’s a quick demo that shows Rube in action 👇

3. n8n

ℹ️ The world’s most popular open-source no-code automation platform.

n8n is an open-source platform that makes it easy to create automation workflows, AI agents, and integrations without heavy coding. You get a visual canvas where you drag and connect nodes to link apps, APIs, and logic together.

The best part? It’s completely free and open-source. You can run it on your own machine, deploy it in the cloud, or use their hosted version if you want a plug-and-play option.

With n8n, you can:

Connect hundreds of apps and databases right out of the box
Add JavaScript or Python when you need advanced custom logic
Build one-off automations or scale up to production-grade workflows
Automate almost anything that exposes an API

In short, if there’s an API, chances are you can automate it with n8n. 🤯

If you want to see what’s possible, check out this quick walkthrough from NetworkChuck. It’s a great introduction to how powerful n8n can be 👇

4. Langflow

ℹ️ Low-code AI builder for agentic and RAG applications.

Langflow gives you a drag-and-drop visual interface that lets you build complex AI workflows without writing every line of code.

Under the hood, it’s powered by Python and gives you full access to customize components, hook into APIs, or integrate vector stores.

You can:

Quickly iterate using visual flows and reusable components
Orchestrate multi-agent systems with conversation control and retrieval logic
Turn your flows into APIs, JSON exports, or even MCP servers for integration
Support major LLMs, databases, and tools out of the box
As always, there's a lot more...

Take a look at the Langflow docs to learn more.

Here's a quick intro video to Langflow 👇

5. Gumloop

ℹ️ A no-code platform that lets you build AI workflows using drag-and-drop nodes.

Gumloop works similarly to Rube or n8n by giving you a visual canvas where you link building blocks (called “nodes”) to design workflows.

You place triggers, logic, API calls, AI prompts, or integrations on a canvas, connect them, and deploy. It handles orchestration behind the scenes.

What you can do with Gumloop:

Build workflows that fetch data, call AI models, transform it, and push results to apps like Google Sheets, Slack, CRMs, etc.
Use subflows so you can reuse chunks of logic inside bigger flows.
Integrate with services like Slack, Salesforce, Airtable, Outlook, GitHub, Google, and more.
Use its built-in AI features to scrape websites, analyze content, generate text, etc., all inside flows.

Want to see it in action? Here’s a demo showing a real workflow built using Gumloop 👇

If you know of any other useful AI automation tools that I haven't mentioned in this article, please share them in the comments section below. 👇🏻

These are your top 10 Make alternative AI automation tools for 2025, and that wraps up this article. Thank you so much for reading! 🫡