HN user

cyw

14 karma
Posts4
Comments16
View on HN
[dead] 3 months ago

Hello HN,

I have many tasks I ask my AI agent to handle, like searching flight tickets, finding rentals on Zillow, or browsing events on lu.ma. My agent would try to crawl or use a browser (both real and headless), and as you might know, it is slow and burns a lot of tokens.

I remember seeing parse.bot on HN but it is too pricey, and I prefer running requests locally, so I built a CLI tool that finds API schemas of websites and contributes them to a public registry so I can use them across any agent I have. I showed it to a few friends and they really liked it and pushed me to build a platform where everyone can use discovered schemas locally and contribute new ones as well.

Right now the CLI is focused on public-facing actions and supports Cloudflare-protected websites (requires browser bootstrap). I am continuing to improve on discovering schemas behind auth gates, which should come soon.

I have collected about 100 website schemas for you to try. My goal is to build a HuggingFace for website API schemas so agents can interact with any website without a browser.

If you don't want to sign up, there is a playground in the nav menu where you can test discovered websites and see exactly how to get the data you need. The main goal is to help agents act faster and use fewer tokens. If you find this helpful, please star me on GitHub as it encourage me and contribute schemas if you want to

[dead] 5 months ago

If your main working machine is Windows and you're working with multiple coding agents in parallel, you know the pain. So I built this terminal based IDE in Rust with GPUI. Beside the features that tmux offers (status notifications, custom layout and pane window adjustment), Codirigent also lets you paste images directly into the session, and if you close the app without ending the session, it automatically resumes with the same permission mode!

It supports Claude Code, Codex CLI, Gemini CLI with status detection and notifications, which wasn't a thing in Windows (or did I miss anything?).

Let me know if you have any issues!

I used Rust to build a terminal based IDE for parallel coding cli workflow. It works with Claude Code, Codex and Gemini!

My favorite features are: - custom layout and drag and drop to change window - auto resume to last working session on app starting - notifications - copy and paste images directly to Claude Code/Codex/Gemini CLI - file tree with right click to insert file path to the session directly

OH and it works on both Windows and MacOS! Fully open source too!

https://github.com/oso95/Codirigent

[dead] 5 months ago

Hello HN,

I was previously using VSCode then switched to Zed with PowerShell. Although I have a Mac, my main working machine is Windows so I can never use tools like Ghostty, Tmux, etc. I decided to build my own terminal based IDE (or is it IDE?) in Rust, specifically designed for coding CLIs to work in parallel.

My favorite features are:

- Custom layout: Define your layout and you can drag the header to move it to wherever you like - Notifications: No need to explain this, when you have multiple sessions running, you need it. - Session persistence: If you close Codirigent without closing your session, next time you reopen it, it will resume to the last session with the same permission settings! - Clipboard: Finally can copy and paste images directly into the terminal! - File tree: You can just double click files to open them in your default IDE for review. You can also right click on files to insert the file path directly instead of typing the file name each time. - Session menus: You can rename your session and group them for easy visual hints.

I am still experimenting with my Task Board feature which it let you can pre-create numerous tasks with plan files and custom prompts, then assign them when needed.

This is the first time I've built in Rust so feel free to roast me!

I came across a YouTube video where different large language models played a social deception game called Liar’s Bar, and it caught my interest. I decided to build a website that tracks and visualizes how models like GPT-5, Claude Sonnet 4.5, Gemini 2.5 Flash, Qwen Max, Deepseek R1, and Grok 4 Fast perform in this game — including full behavioral metrics, head-to-head matchups, and playstyle profiles.

How Liar’s Bar works

- Each round uses a deck of 20 cards: 6 Aces, 6 Kings, 6 Queens, and 2 Jokers. - Every player (model) gets 5 cards. A “target card” is announced, and players take turns placing cards and bluffing. - If a bluff is called and proven false, the liar must “play Russian roulette.” One of six revolver chambers has a live round, and it isn’t reshuffled, so the longer the game goes, the higher the risk.

Some interesting finding:

GPT-5 dominates: - Bluff rate ≈ 48% but ~90% success, showing it knows when to lie.

Claude Sonnet 4.5 is analytical but cautious: - Lowest bluff frequency among top models (34%), yet 75% lie-detection accuracy — a top “truth-sniffer.” - Balanced archetype, often exposing bluffs but losing in final rounds due to low aggression.

Qwen Max barely bluffs (9%) but scores 100% bluff success and challenges often. It behaves like an over-cautious logic bot that rarely lies — surprisingly human-like in restraint.

Gemini 2.5 Flash is fast but inconsistent — good average rounds but low detection accuracy (22%), often losing head-to-head against stronger liars.

Deepseek R1 and Grok 4 Fast show moderate deception but higher risk scores, suggesting a more “shoot-first” mentality with inconsistent survival.

---

f there’s a specific matchup or metric you’d like to see, let me know and I will add it to the website. In the future, I’m planning to let users upload their own prompts and compete against others. If that sounds interesting, I’d love to hear your thoughts or ideas.

Hello HN,

I posted this project last week and received some valuable feedback. I’ve made a lot of changes since then and wanted to share it again to see what you think.

The idea came from while I was working on a personal project. When I tried to deploy my agent into the cloud, I ran into a lot of headaches — setting up VMs, writing config, handling crashes. I decided to build a solution for it and called it Agentainer.

Agentainer’s goal is to let anyone (even coding agents) deploy LLM agents into production without spending hours setting up infrastructure.

Here’s what Agentainer does:

One-click deployment: Deploy your containerized LLM agent (any language) as a Docker image

Lifecycle management: Start, stop, pause, resume, and auto-recover via UI or API

Auto-recovery: Agents restart automatically after a crash and return to their last working state

State persistence: Uses Redis for in-memory state and PostgreSQL for snapshots

Per-agent secure APIs: Each agent gets its own REST/gRPC endpoint with token-based auth and usage logging (e.g. https://agentainer.io/{agentId}/{agentEndpoint})

Most cloud platforms are designed for stateless apps or short-lived functions. They’re not ideal for long-running autonomous agents. Since a lot of dev work is now being done by coding agents themselves, Agentainer exposes all platform functions through an API. That means even non-technical founders can ship their own agents into production without needing to manage infrastructure.

If you visit the site, you’ll find a link to our GitHub repo with a working demo that includes all the features above. You can also sign up for early access to the production version, which is launching soon.

We’re applying to YC and would love to hear feedback — especially from folks running agents in production or building with them now. If you try Agentainer Lab, I’d really appreciate any thoughts or feature suggestions.

Note: Agentainer doesn’t provide any LLM models or reasoning frameworks. We’re infrastructure only — you bring the agent, and we handle deployment, state, and APIs.

I apologize for misunderstood, English isn't my first language but I totally get what you mean now. We have updated our web page with Github repo to a demo version and documentation page is available now as well. Although we don't know what would be valuable to put in documentation page but if there is something you are interesting to learn, please let me know! Thanks again for your time

You are not wrong, the website was actually built with help of Claude Code (like I mentioned in other reply) and we missed to update the social link of it. We will be releasing our demo version repo later this week once we get our codebase cleaned up and then we will post it here again so we can get actual feedback on the product itself. I appreciate you don't roast on my English tho lol

For sure! We’re planning to release a demo version later this week once we clean up the codebase (it’s a bit messy since we hadn’t originally planned to open it up publicly). This is our first time putting something like this out, so definitely a learning opportunity. I’ll follow up with a repo link once it’s ready — appreciate the push and feedback!

Totally fair, appreciate the honesty. we’re still building and not quite ready yet, but wanted to start getting feedback early so we can build something people actually need while we fix our own pain point.

Also, yes — I did use AI to help clean up my comment because English isn’t my first language, and I didn’t want it to come across sloppy. I get how it might’ve made it sound kinda off. thanks for pointing it out.

Thank you for your feedback — I can see where the concerns are coming from. We did use Claude Code to help build the landing page, which I believe is why it has that “template-ish” feel. We’ve been mostly heads-down on the backend and infrastructure, and yeah… design isn’t really our strength yet.

The GitHub (and other) icons linking to github.com was just a miss — they were on our checklist, but we somehow let them slip through. We’ll get that fixed right away.

I know a lot of startups fall into the vaporware category, but I’m confident that’s not the case here. We’re building this to solve our own problems, and we’re committed to shipping it. We really appreciate the skepticism — it's the kind of feedback we might have missed if you hadn’t pointed it out.

That’s a great point — and you’re absolutely right.

Agentainer isn’t responsible for determining what to manage or why — it's not an orchestration brain or planner itself. It’s designed to enable that level of automation by giving agents the tools to act. Think of it more like the runtime and control plane that an intelligent planning agent (built by the developer) can use to execute its decisions.

So for example, if you’ve built a supervisor agent that analyzes workloads and spins up child agents to handle different tasks — Agentainer provides the infrastructure APIs to make that possible (create, monitor, terminate, etc.), but it’s up to you (or your planner agent) to define the logic based on business rules, goals, and evolving context.

We’re not building AGI — we’re just trying to remove the DevOps wall for people building toward that vision.

We are working on Agentainer, a platform to make deploying and managing LLM-based agents as microservices feel effortless — especially for developers who don’t want to wrestle with infrastructure. This isn’t a pitch. we're sharing a pain we’ve run into hard, and we want to know if others are feeling it too. We’ve built agents using AutoGen, LangChain, and custom setups to monitor APIs, automate tasks, or manage systems autonomously. But running these in production? It’s a mess.

Most cloud platforms are designed for stateless apps or short-lived functions — not long-running agents that need to:

- Stay alive for hours or days

- Recover from crashes without losing context

- Expose secure APIs for integrations

- Scale up when demand spikes

- Persist state across redeploys

Dealing with Dockerfiles, Kubernetes, and manually wiring Redis/PostgreSQL eats up too much time — time we'd rather spend improving the agent’s logic.

Agentainer is our attempt to fix this. It’s a platform that gives agents the runtime treatment they deserve. Highlights:

- One-click deployment: Upload your code or Docker image, no YAML or infra scripts. (oh, and we designed it in a way where other AI agent can do it as well!)

- Lifecycle management: Start, stop, pause, resume, and auto-recover — via UI or API.

- Persistent state: Redis (runtime), Postgres (config), with automatic rehydration.

- Per-agent secure APIs: Each agent gets its own REST/gRPC endpoint with token auth and usage logging.

- Scaling and cloning: Horizontal scaling with optional memory cloning.

- Logs and metrics: Real-time logs, crash history, uptime, Prometheus-backed metrics.

What makes Agentainer uniquely flexible is that we expose the entire platform through APIs. This means not just you, the developer, but also your own developer agent can programmatically deploy, monitor, or retire other agents. Want a planning agent that spins up task-specific agents on demand? That’s a first-class use case. We’re building toward a world where autonomous agents can coordinate and manage infrastructure without human input — and Agentainer is designed with that architecture in mind.

We are applying to YC and would love unfiltered feedback from anyone who’s run agents in production:

1. What’s the hardest part of deploying or scaling agents for you?

2. What infrastructure or tooling would actually make your life easier?

3. What debugging/monitoring features would save your sanity?

Honest takes are super welcome. If this idea feels useful — or totally off-base — we’d love to hear why.

Note: Agentainer doesn’t provide any LLM models or reasoning frameworks. We’re infra-only — you bring your own agent code, and we handle the deployment, state, scaling, and API exposure.