bkrausz
When you npm install openai or pip install anthropic, you’re pulling code generated by Stainless.
We’re building the platform for high-quality, easy-to-use APIs — and companies like OpenAI, Anthropic, and Cloudflare already rely on us.
We’re ~3 years old, ~60 people, with strong revenue, several years of runway, and backing from Sequoia and a16z.
As one of our first 40 engineers, you’ll have real ownership, autonomy to build great products, and a direct hand in shaping the future of how developers consume APIs.
We’re looking for exceptionally productive, thoughtful, and kind people who want to make software development better for everyone.
Learn more & apply → https://stainless.com/jobs?utm_source=YlRQ8pvARO
When you npm install openai or pip install anthropic, you’re pulling code generated by Stainless.
We’re building the platform for high-quality, easy-to-use APIs — and companies like OpenAI, Anthropic, and Cloudflare already rely on us.
We’re ~3 years old, ~50 people, with strong revenue, several years of runway, and backing from Sequoia and a16z.
As one of our first 35 engineers, you’ll have real ownership, autonomy to build great products, and a direct hand in shaping the future of how developers consume APIs.
We’re looking for exceptionally productive, thoughtful, and kind people who want to make software development better for everyone.
Learn more & apply → https://stainless.com/jobs?utm_source=YlRQ8pvARO
When you npm install openai or pip install anthropic, you’re pulling code generated by Stainless.
We’re building the platform for high-quality, easy-to-use APIs — and companies like OpenAI, Anthropic, and Cloudflare already rely on us.
We’re ~3 years old, ~35 people, with strong revenue, several years of runway, and backing from Sequoia and a16z.
As one of our first 25 engineers, you’ll have real ownership, autonomy to build great products, and a direct hand in shaping the future of how developers consume APIs. We’re looking for exceptionally productive, thoughtful, and kind people who want to make software development better for everyone.
Learn more & apply → https://stainless.com/jobs
If you want to email bkrausz at anthropic.com with your phone number I'm happy to check logs (assuming it's still not working).
Sorry about that, we really want to expand availability and are working to do so.
Sorry to hear about that! It sounds like you might have been using an unpinned model version, e.g. `claude-2`, which is designed to automatically get the latest models as they are released. We also support pinned model versions, e.g. `claude-2.0` or `claude-2.1`, which will not be upgraded automatically.
We've been moving away from recommending unpinned versions and are likely to only have pinned versions with future major model releases to avoid this sort of issue.
https://docs.anthropic.com/claude/reference/selecting-a-mode...
Much appreciated!
Brian and Michael here! We're 2 ex-Stripe engineers (and previously Facebook and YC). We started and helped scale Stripe's support team from just a few people in Gmail to their current size. Now we're bringing those lessons and tools to other startups. We have customers with hundreds of people each scaling their teams with Kenchi. Kenchi is about human-in-the-loop automation, currently targeting support teams. We sit inside your browser to provide a privacy-first approach to team members automating aspects of their work in any environment they sit in. We need to be snappy, resilient to running in different JS environments, and smart about how we tie into different pages to extract information in a robust and resilient way.
We're looking for full-stack devs and designers to join our team of (currently) 3. Founder-types who want to wear many hats, are curious about the innards of different frameworks, and love working across many parts of the system will thrive.
Shoot us an email at [email protected] to say hi! We'd love to hear about something you've worked on before of which you're most proud. Talk soon :)
Brian and Michael here! We're 2 ex-Stripe engineers (and previously Facebook and YC). We started and helped scale Stripe's support team from just a few people in Gmail to their current size. Now we're bringing those lessons and tools to other startups. We have customers with hundreds of people each scaling their teams with Kenchi. Kenchi is about human-in-the-loop automation, currently targeting support teams. We sit inside your browser to provide a privacy-first approach to team members automating aspects of their work in any environment they sit in. We need to be snappy, resilient to running in different JS environments, and smart about how we tie into different pages to extract information in a robust and resilient way.
We're looking for full-stack devs and designers to join our team of (currently) 3. Founder-types who want to wear many hats, are curious about the innards of different frameworks, and love working across many parts of the system will thrive.
Shoot us an email at [email protected] to say hi! We'd love to hear about something you've worked on before of which you're most proud. Talk soon :)
Years ago there wasn't even a Kafka portion, that's newer.
Stripe needs to be usable by both the developers building intense, scalable, reliable systems and the people teaching themselves to code in a limited context on a limited platform.
Many large customers eventually had some issue with webhooks that required intervention. Stripe retries webhooks that fail for up to 3 days: I remember $large_customer coming back from a 3 day weekend and discovering that they had pushed bad code and failed to process some webhooks. We'd often get requests to retry all failed webhooks in a time period. The best customers would have infrastructure to do this themselves off of /v1/events, though this was unfortunately rare.
The biggest challenges with webhooks:
- Delivery: some customer timing out connections for 30s causing the queues to get backed up (Stripe was much smaller back then).
- Versioning: synchronous API requests can use a version specified in the request, but webhooks, by virtue of rendering the object and showing its changed values (there was a `previous_attributes` hash), need to be rendered to a specific version. This made upgrading API versions hard for customers.
There was constant discussion about building some non-webhook pathway for events, but they all have challenges and webhooks + /v1/events were both simple enough for smaller customers and workable for larger customers.
Kenchi is about human-in-the-loop automation, currently targeting support teams. We sit inside your browser to provide a privacy-first approach to team members automating aspects of their work in any environment they sit in. We need to be snappy, resilient to running in different JS environments, and smart about how we tie into different pages to extract information in a robust and resilient way.
We're looking for full-stack devs and designers. Founder-types who want to wear many hats, are curious about the innards of different frameworks, and love working across many parts of the system will thrive.
Shoot us an email at [email protected] to say hi! We'd love to hear about something you've worked on before of which you're most proud. Talk soon :)
Brian, Michael, and Kevin here! We're 3 ex-Stripe engineers (and previously Facebook and YC). We started and helped scale Stripe's support team from just a few people in Gmail to their current size. Now we're bringing those lessons and tools to other startups. We have customers with hundreds of people each scaling their teams with Kenchi.
Kenchi is about human-in-the-loop automation, currently targeting support teams. We sit inside your browser to provide a privacy-first approach to team members automating aspects of their work in any environment they sit in. We need to be snappy, resilient to running in different JS environments, and smart about how we tie into different pages to extract information in a robust and resilient way.
We're looking for full-stack devs and design. We're 3 people now, so founder-types who want to wear many hats, are curious about the innards of different frameworks, and love working across many parts of the system will thrive.
Shoot us an email at [email protected] to say hi! We'd love to hear about something you've worked on before of which you're most proud. Talk soon :)
Additionally, devs would need to specify what their changes were independent of where they made the change, which meant that our API reference (which can display warning flags next to changed fields) was missing changes. With the new system we can enforce that the change being made is properly documented, since we know that it's encapsulated inside of the change class itself.
Within 30 minutes in the worst case. Most failures we would be able to communicate synchronously, such as if the card is not a debit card or the bank doesn't support instant payouts. Some other failures we communicate asynchronously, but ~instantly (e.g. if the bank account behind the debit card has been closed), as we have to reach out to financial partners for that information.
> we still need to wait for the charge to settle right?
Nope, we support instant payouts from the moment a charge succeeds, you do not need to wait for funds to settle in the traditional card-to-ACH sense! Specifically, instant payouts can be made off of an account's "pending" balance, as opposed to the usual limitation of "available" only.
The timing aspect that both of these questions touch on are one of the big features of this launch, and something we spent a lot of time on to get the logistics to work exactly right (there's a lot under the hood there). We're really excited to have something that operates faster than the 2-3 days ACH can take, both in moving money and giving you success feedback.
As for things like chargeback rate, it depends more on your type of business than the particular Stripe product you use. For example, if you are running a shopping cart hosting service, we recognize that each of your stores are different, and will consider them somewhat separately. However, as the direct line to your customers, if you're attracting a huge amount of fraud on your platform, we would expect you to take steps to reduce that, and would work with you to figure out what the best steps may be.
We are working to figure out the best balance between giving platforms control and using our expertise to help them with challenges like fraud. If you have any suggestions on how we could improve this balance I'd love to hear them, either here or via email at [email protected]
More generally, international KYC and compliant payments are quite hard, and our pricing there is very competitive. Domestically we saw that many companies were already paying similar rates on our fixed-fee pricing, so we weren't actually hurting customers in the US (on the contrary, we were encouraging more frequent payouts for the same rate, which would help everyone by making a more efficient system). We felt that the benefits of consistent pricing were worth it here.
Re standalone vs. managed accounts: our preference is that we make standalone accounts such a great and easy-to-use experience that everybody starts using them, because dealing with things like information collection and tax reporting is annoying. However, we're letting our customers dictate that. If managed accounts become immensely popular, it means we haven't made standalone accounts easy enough to use, or we've made an incorrect assumption about the world (likely a combination of both). Regardless, we intend to support managed accounts for a very long time, and have already had them around in some less-built-out form for quite a while.