HN user

cmdtab

96 karma

https://saksham.work

me@saksham.work

Posts13
Comments61
View on HN

Not just cheaper in terms of token usage but accuracy as well.

Even the smallest models are RL trained to use shell commands perfectly. Gemini 3 flash performs better with a cli with 20 commands vs 20+ tools in my testing.

cli also works well in terms of maintaining KV cache (changing tools mid say to improve model performance suffers from kv cache vs cli —help command only showing manual for specific command in append only fashion)

Writing your tools as unix like cli also has a nice benefit of model being able to pipe multiple commands together. In the case of browser, i wrote mini-browser which frontier models use much better than explicit tools to control browser because they can compose a giant command sequence to one shot task.

https://github.com/runablehq/mini-browser

I would stay away from any startup for production workload.

Made the mistake. Never again.

Fly, railway, render. Avoid. All have weird show stopper bugs for any reasonable scale and you will fight against the platform compared to using big cloud.

And big cloud works better even in cases where PAAS is advertised as simpler (google cloud run and build is as easy to setup as railway but you have much more knobs to control traffic, routing, roll out etc)

Runable | Software Engineer | Bangalore | 60-120K USD depending on the candidate

https://runable.com is an AI suite for everyone. You can create decks, reports, documents, designs, websites etc by just describing what you want.

We are looking for exceptional engineers to join us as we scale. We already process 100 billion+ tokens and billions of requests monthly.

Send your best work to saksham@runable.com

We don’t do DSA, leetcode etc and have a very hands on approach to interviewing

Runable | Bangalore, India | On Site | Software Engineers | Full Time & Internship | runable.com

Runable is a general purpose AI agent for any task you can think of. You can create presentations, websites, docs, reports, videos, images, use over 3000+ services, control remote browsers, etc.

I’m looking for savvy people with potential to grow quickly who wants to work at a startup. If you want to take ownership, learn and be a founder in future. This is the place for you.

Shoot me an email with your github or portfolio: saksham@runable.com

I tried flight control but it was a bit buggy and rough. My docker image worked differently on their platform compared to other PAAS.

Lot of issues with slow AWS provision or missing APIs on AWS side so it would take hours to delete resources created by them.

They inherit all the limitations of DO. For example, if you want to do anything that requires more than 6 TCP connection. Every fetch request will start failing silently because there is no more TCP connection to go through. This was a deal breaker for us. Their solution was split our code into more workflows or DOs.

You are limited to 128 MB ram which means everything has to be steamed. You will rewrite your code around this because many node libraries don't have streaming alternatives for things that spike memory usage.

The observability tab was buggy. Lifecycle chart is hard to understand for knowing when things will evict. Lot of small hidden limitations. Rate limits are very low for any mid scale application. Full Node compatibility is not there yet (work in progress) so needed to change some modules.

Overall, a gigantic waste of time unless you are doing something small scale. Just go with restate/upstash + lambdas/cloud run if you want simpler experience that scales in serverless manner

Temporal required re-architecting some stuff, their typescript sdk and sandbox is bit unintuitive to use so would have been an additional item to grok for the team, and additional infrastructure to maintain. There was a latency trade off too which in our case mattered.

Didn't face any issue though. Temporal observability and UI was better than DBOS. Just harder to do incremental migration in an existing codebase.

Needed checkpoints in some of our jobs wrapping around the AI agent so we can reduce cost and increase reliability (as workflow will start from mid step as opposed to a complete restart).

We already check pointed the agent but then figure it's better to have a generic abstraction for other stuff we do.

Recently moved some of the background jobs from graphile worker to DBOS. Really recommend for the simplicity. Took me half an hour.

I evaluated temporal, trigger, cloudflare workflows (highly not recommended), etc and this was the easiest to implement incrementally. Didn't need to change our infrastructure at all. Just plugged the worker where I had graphile worker.

The hosted service UX and frontend can use a lot of work though but it's not necessary for someone to use. OTEL support was there.

Runable | ONSITE - Bangalore | Full Time | https://runable.com

Runable is building general purpose automation agent to automate anything digitally possible.

We are hiring for backend/platform focused full stack engineers, video editor and a community manager intern.

https://runable.notion.site/Careers-at-RUNABLE-20dfb5780e748...

Apply. We have a simple take home for engineering role unless you have a solid github or stuff you built we can check.

Task: Build a simple orchestrator that runs a coding agent in the background inside firecracker instances with novnc support.

I think providing examples and sample code is better than tying your API to AI sdk.

Due to how fast AI providers are iterating on their APIs, many features arrive weeks or months later to AI SDK (support for openai computer use is pending since forever for example).

I like the current API where you can wait for an event. Similar to that, it would be great to have an API for streaming and receiving messages and everything else is handled by the person so they could use AI sdk and stream the end response manually.

I check multiple different apps to order food or taxi services every day looking for cheapest price and availability. It’s a pain and I don’t like the decision fatigue.

I thought why not automate this and turn it into an app so I built this MCP server.

I’m not using vision at all (mostly a fallback) and parsing the accessibility tree into something LLM can understand.

He seems to be of Indian origin. Indian households can be very tight knit and prioritize financial success a lot more.

Compare parts of screenshot and see if they changed. I didn't want to use DOM at all. My hypothesis was multi model AI agents will get cheaper over time (Gemini flash is crazy cheap) and people would start putting in attacks in the DOM to confuse AI.

Additionally, existing tools that I used struggled interacting with sites like reddit. So I set out to skip DOM and focus on a generalized approach.

I tried to go cheaper by using ui-tars, open source model by bytedance to run test locally without needing anthropic but it wasn't reliable enough.

That short test link is interesting. I didn't know they existed. Wow, the field is moving fast.

For the 1st point, I generate a script with hashed check points so next run is automated unless something changes in the UI to invoke AI. I make this possible by proxy wrapping playwright library so I can take over every method. Users use playwright like they always have but with one extra method called act.

Omini parser lets you split section of the UI to hash and watch for changes that are relevant.

For 2, can you give some examples?