Launch HN: Dedalus Labs (YC S25) – Vercel for Agents

72 pointsposted 2 days ago
by windsor

Item id: 45054040

15 Comments

muratsu

2 days ago

Congrats on the launch. I see that you're charging 5% on Balance Reloads. This pricing model seems to be getting popular across multi-LLM applications. Was curious to know how did you go about implementing it? or are you just passing on the 5% of openrouter

windsor

2 days ago

Good eye. A ~5% surcharge on prepaid credits is the standard model right now for most multi-LLM services. We actually do not use OpenRouter internally, so this number is flexible. One thing I'll note is that we try to be as upfront and transparent about our platform fee as possible so that no one is surprised.

muratsu

2 days ago

Oh interesting. I've previously looked into implementing it myself but seemed like it would require a lot of effort. I would love to connect and learn more about your implementation. What's the best way to reach out to you? My email is available on my profile.

just_human

2 days ago

Congrats on the launch and looks interesting! I love how easy it is to combine local code "tools" with remote mcp servers. The marketplace looks promising, but would be helpful to have some curation as many of the servers don't have descriptions and link to private github repo's. Neat vision and look forward to trying this.

windsor

a day ago

Thanks! Really glad you noticed this feature. Mixing client-side and server-side tool calls was something we spent a lot of time thinking through.

The current SOTA, e.g. OpenAI’s Responses API or Anthropic’s Computer Use API, basically mandates that server-side tool results return directly, while client-side tool results have to be manually parsed and executed by the user (for obvious security reasons). As a result, it was extremely unclear how a user would be able to chain together tool calls that mixed local and remote tools.

We wanted to close this DX gap, which surprisingly had no real incumbent solution. Users should be able to just define tools and get back clean responses. For power users, we still support manual JSON parsing for full low-level control, but our belief is simple: developers should spend their time building, not doing plumbing work like post-processing tool results.

mifydev

2 days ago

Congrats on the launch! I’m curious, do you have to store the tool inputs and outputs on the server side while either of the sides are waiting for response? I’m building a specialized coding agent for integrations and I had to avoid stateful api, because I don’t want to store user code.

windsor

a day ago

We tried to keep things simple, so our runner utility class is currently stateless.

However, it's highly extensible, and we can support stateful logic if we wanted to. For instance, we have a cool concept called "Policy" in our SDKs, which is basically a user-defined callback function that is run after each runner step (see our docs for more info). You can build some pretty advanced use cases with this, e.g. executing conditional database calls on a per-step basis.

The code for the runner is open source, in case you wanted to check out how we did it: https://github.com/dedalus-labs/dedalus-sdk-python/blob/main...

kitan232

a day ago

Congratulations on the launch. Been trying this out for the past hour, and really like how easy it is to host your own MCP servers. Would love to see more public MCPs on the marketplace. Also, I was wondering when you plan to support auth?

windsor

a day ago

Thanks for trying us out! Let me know if you run into any issues with deployment or the like. If you want a clean MCP template to get up and running, check out this example: https://github.com/dedalus-labs/brave-search-mcp

Auth is a big one for us, and we're working really hard to provide a robust auth experience that is easy to use for both LLM agents and human users. One of our goals is to help mold the shape that the community takes with MCP. We’ll be launching our auth solution around end of September. I’m personally really excited to tackle this problem.

barapa

21 hours ago

Why does every comment start with 'congrats on the launch'?

Feels unnatural

mnafees

a day ago

Congratulations on the launch!

I’ve been writing Go for the past 4 years, and I’d strongly suggest avoiding Stainless for auto-generating Go SDKs. Some of the issues I’ve run into: - Awkward package naming (e.g., githubcomdedaluslabsdedalussdkgo) - Methods with unnecessary complexity, including excessive use of reflection for JSON handling - Other codegen quirks that make the SDK harder to use and maintain

From experience, I’d recommend either using another code generator or hand-writing the Go SDK for a cleaner and more idiomatic developer experience.

windsor

a day ago

Thanks! What's your favorite SDK generator for Go? What are the most important things for you when interacting with Go SDKs?