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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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.