myzie

`environment.type: "none"`

When there is an environment, my impression is it's a floor of 5 minutes at that 1 GB @ $0.03/20 min rate. So $0.0015/minute * 5 minutes = $0.0075 minimum charge per activated environment.

https://developers.openai.com/api/docs/guides/agents-api/ses... https://developers.openai.com/api/docs/pricing#built-in-tool...

Async tool calls, having the agent wait indefinitely for a human response, and showing a form or questions to the user via a tool call are a few common capabilities that come up that a product manager might miss at first.

This is why I've been building Nvoken. LLM agnostic, ergonomic SDKs, flexible tool call patterns, tenant and user-aware budget enforcement, etc.

I'd really appreciate any and all feedback on this! It gives you some free tokens on signup and it's super quick to try.

https://nvoken.com

https://deepnoodle.ai/research/linkedin-legal-battles-tos-vi...

The reason I was posting here on HN is to see if anyone more technical may be interested in this as well. E.g. to leverage an API like this with AI agents or otherwise.

Dive orchestrates multi agent workflows in Go. Take a look and let me know what you think.

Along these lines, I'm building Dive:

https://github.com/diveagents/dive

When building a SaaS with a Go backend, it's nice to be able to have the option of the agents and workflows being in the same process. And being confident in the ability of that to scale well.

While it's true that Go lacks good ML libraries, for some this isn't too consequential if your app is primarily using Anthropic or OpenAI and a database that offers semantic or hybrid search for RAG. The ML is done elsewhere. Plus it could be that you can leverage MCP servers and at that point you're language agnostic.

Regarding the concurrency model approach with Go and agents, I initially baked a message based approach (a la the Actor model, with one goroutine per agent) into Dive Agents, but eventually found that this would be better implemented as another layer. So currently in Dive it's the user's choice on how to implement concurrency and whether to use messaging. But I anticipate building that back in as an optional layer.

To me it seems like the companies actually doing the crawling have an incentive to leverage centralized caching. It makes their own crawling faster (since hitting the cache is much faster than using Playwright etc to load the page) and it reduces the impact on all these sites. Which would then also decrease the impact of this whole bot situation overall.

This seems like an opportunity for a company like Firecrawl, ScrapingBee, etc to offer built-in caching with TTLs so that redundant requests can hit the cache and not contribute to load on the actual site.

Even if each company that operates a crawler cached pages across multiple runs, I'd expect a large improvement in the situation.

For more dynamic pages, this obviously doesn't help. But a lot of the web's content is more static and is being crawled thousands of times.

I built something for my own company that crawls using Playwright and caches in S3/Postgres with a TTL for this purpose.

Does this make sense to anyone else? I'm not sure if I'm missing something that makes this harder than it seems on the surface. (Actual question!)

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

I see you're a Cloudformation Stacks user (good stuff), so you may know some of what I say below already, but maybe the Terraform specific notes will be of interest.

Many AWS deployments (Terraform or otherwise) are single region unfortunately, with a primary factor there being that AWS APIs are for the most part region-specific. The AWS Terraform provider was built with this mindset too, unfortunately. Then the situation is complicated by Terraform's lack of support for dynamic providers, which is one of the most discussed still-open issues in Terraform.

Some related open issues:

https://github.com/hashicorp/terraform/issues/24476 https://github.com/hashicorp/terraform/issues/25244 https://github.com/hashicorp/terraform/issues/19932

My understanding is that people that have this as a first-class concern use something like Terragrunt to dynamically generate the HCL as needed.

https://terragrunt.gruntwork.io/

For Burrow here, I was was focused on shipping something and didn't want to spend time on generating that code just yet. But the project has gotten some attention so if this is a recurring request I'll probably do it.

Note that I intentionally chose the 17 AWS regions that are default enabled in every new AWS account, so it should only be if you want to customize it that this becomes important.

A Cloudformation Stacks based deployment to achieve multi-region would be another good (and perhaps better) option here. I could add that to the Makefile, with inspiration from your link there.

That said, you could actually layer the two together if you were so inclined, and/or optionally route through Cloudflare and AWS.

Making the Cloudflare Worker implementation of this would be trivial and there's no dependency on Go in any way for the proxy itself.

https://github.com/pgEdge/cloudflare-pgedge-latency-tests

https://github.com/risor-io/risor