embirico

(I work at OpenAI) Heya, in reality it's more much organic than that. We build stuff, ship it internally, then work crazy hard to quickly ship it externally. When we put something out on a given day, it's usually been in the works and scheduled for a while.

One concrete example: to set up a launch like today, where press, influencers, etc, all came out at 10a PT. That's all coordinated well in advance!

(I work on Codex) We have a robust sandbox for macOS and Linux. Not quite yet for Windows, but working on that! Docs: https://developers.openai.com/codex/security

(I work on Codex) I think for us the big unlock was GPT-5.2 and GPT-5.2-Codex, where we found ourselves needing to make many fewer manual edits.

Only thing i'd add re windows is it's taking us some time to get really solid sandboxing working on Windows, where there are fewer OS-level primitives for it. There's some more at https://developers.openai.com/codex/windows and we'd love help with testing and feedback to make it robust.

(I work on Codex) One detail you might appreciate is that we built the app with a ton of code sharing with the CLI (as core agent harness) and the VSCode extension (UI layer), so that as we improve any of those, we polish them all.

(Disclaimer: Am on the Codex team.) We're basically trying to build a teammate that can do both short, iterative work with you, then as you build trust (and configuration), you can delegate longer tasks to it.

The "# of model-generated tokens per response" chart in [the blog introducing gpt-5-codex](https://openai.com/index/introducing-upgrades-to-codex/) shows an example of how we're improving the model good at both.

when was that @sergiotapia? last week we just upped the base rate limit for new API accounts

Hey, I work on Codex—absolutely no way that a user on a Pro plan would somehow silently move to token-based billing. You just hit a limit and have to wait for the reset. (Which also sucks, and which we're also improving early warnings of.)

I do love the vibe of that license

How do you compare the pros/cons of having the summarization built into the call tool, like with Vowel, vs having more control but in separate tools?

For anyone who's genuinely curious about why the pricing ramp, here's the [an internal doc with some of the debate about the pricing plan](https://multiapp.notion.site/Pricing-What-should-we-charge-f...).

Link expires in 6 days. Most of the discussion is in the comments.

For anyone who doesn't want to load a ton of JS, in short:

# Free

Mostly pairing features. Free because we think that collaborative pairing functionality should be available to everyone, whether or not you can pay. If you're an individual contributor, you should just be able to sign up. Our closest competitor charges $30 a month for just pairing functionality, and as a result many small teams can't afford to use it.

# Standard

Mostly features to help with async communication and documentation. We think that distributed work in it's ideal is "Pair often, write a lot, and minimize meetings."

We think it makes sense to draw the paywall here because a/ The async features cost us more to run, and b/ This problem is something that team leaders or managers care about. And those are the people with credit cards.

We support teams having a mix of Free and Standard seats. Just pay for the power users.

# Enterprise

There are some features that cannot be per-seat: They have to be the whole team or nothing. For example, SSO (yes #ssoTax), API access, bespoke security review etc. For these, we can talk to the team about what their usage will look like in deciding the price.

Hope that helps. We're very open to feedback on this. DM's open at @embirico on Twitter if you have thoughts privately.

(Cofounder here) This is close to our thinking. Comes from seeing how at Dropbox we started with a cross-platform approach on desktop. While it meant that we could quickly achieve consistency, it also meant that we couldn’t use platform-specific tooling on any given platform, like debuggers, without a bunch of custom tooling to fight through the intermediate layers.

We want to try running small teams using the best stack for each platform.

Appreciate this feedback! Our site is ~6 months stale and we're working on updates next week onwards, so this is very timely.

When 7/10 team mates comply and keep it on always, the pressure is on the remaining 3 to turn on their cameras as well.

This is our site being unclear again. Remotion coworking rooms default to audio and video muted. However, we struggling with how to represent Remotion on our site: When you're out of a call or your camera is off, we show users as "selfies" because we think those feel more human that just a green dot. Website viewers often interpret these selfies as being live video.

when you go offline, it is now amplified in terms of visibility [...] This may affect my performance reviews

Candidly, I think that the root symptom of what you're describing is your team/manager. Let me ask you this: Do you want to work on a team that wants you to be at your desk all the time?

Our philosophy at Remotion is to be radically transparent about breaks, to the point of celebrating them. Apart from a few hours of meeting overlap in the middle of the day, we work on our own terms, including taking breaks for walks/errands/etc in the middle of the day. It goes to the point of actively posting photos of our midday breaks in an OOTO channel. Teammates react to those, making a point of saying: "Hey, prioritizing yourself is good. Being offline is good."

pro-privacy zoom alternative

Interesting, will bear in mind.

Thanks, this is a more accurate understanding of what we’re building.

Re video on/off, the defaults in the app can influence a lot here. Our coworking rooms default to audio and video off.

This sounds great in principle and I saw this tried for several years for Dropbox mobile. It was a failed experiment though:

By writing code in a non-standard fashion, we took on overhead that we would have not had to worry about had we stayed with the widely used platform defaults. This overhead ended up being more expensive than just writing the code twice.

https://dropbox.tech/mobile/the-not-so-hidden-cost-of-sharin...

Cofounder here. Yep, this happens and it sucks. We view it as a hard and temporary tradeoff to be loved by few rather than liked by many.

(Cofounder @ Remotion here.) One challenge with hiring macOS devs is that they don't usually come from cookie-cutter backgrounds. For example, they might have been indy devs, or consultants for a while. And those folks often fare poorly in traditional tech interviews. Hiring for macOS led us to drop standard loops in favor of contracts, projects, or however the candidate can best demonstrate skills. We have a recent blog post about "objective-based recruiting" here: https://www.remotion.com/blog/standardized-interviews-stifle...