51–60 of 405 posts
I’m wondering if it would be possible to use the new skills feature or agents with this. Without the agents or the skills, I don’t know how useful this would be.
We were heavy users of Claude Code ($70K+ spend per year) and have almost completely switched to codex CLI. I'm doing massive lifts with it on software that would never before have been feasible for me personally, or any team I've ever run. I'll use Claude Code maybe once every two weeks as a second set of eyes to inspect code and document a bug, with mixed success. But my experience has been that initially Claude Co…
Yeah this has been my experience as well. The Claude Code UI is still so much better, and the permissioning policy system is much better. Though I'm working on closing that gap by writing a custom policy https://github.com/openai/codex/blob/main/codex-rs/execpolic... Kinda sick of Codex asking for approval to run tests for each test instance
Earlier quoted context omitted.
I suspect the release of Claude Haiku 4.5 was done to help reduce usage costs for Anthropic and any use of Claude Code will differ to it if capacity is limited. EDIT: I had meant defer which is the first time I've made a /r/boneappletea in awhile
"differ"? did you mean "default"?
It's pretty frustrating that every release is IOS first without any timeline or expectation for Android
https://www.reddit.com/r/applesucks/comments/1k6m2fi/why_do_...
It's pretty frustrating that every release is IOS first without any timeline or expectation for Android
Anthropic and Apple have a strategic partnership. It's a bit dicey but still seems to be in play. Which is interesting considering Google is a major investor and Apple is not. Anthropic wants Apple as a paying customer. Apple wants them to bend the knee.
We were heavy users of Claude Code ($70K+ spend per year) and have almost completely switched to codex CLI. I'm doing massive lifts with it on software that would never before have been feasible for me personally, or any team I've ever run. I'll use Claude Code maybe once every two weeks as a second set of eyes to inspect code and document a bug, with mixed success. But my experience has been that initially Claude Co…
Do you find this to still be true with the Sonnet 4.5 model?
I don't want to leak data either way by using some "let's throw SSO from a sketchy adtech company into the trust loop".
I don't want to wait a minute for Anthropic's login-by-email link, and have the process slam the brakes on my workflow and train of thought.
I don't want to wait a minute for OpenAI's MFA-by-email code (even though I disabled that in the account settings, it still did it).
I don't want to deal with desktop clients I don't trust, or that might not keep up with feature improvements. Nor have to kludge up a clumsy virtualization sandbox for an untrusted client, just to ask an LLM questions that could just be in a Web browser.
Earlier quoted context omitted.
Not unusual; most high profile apps ship on iOS first, going back to Instagram [1], which was released October 10, 2010. Instagram shipped their Android version 1.5 years later. [1]: https://www.techtarget.com/searchcio/definition/Instagram
Another, not incompatible explanation is that it's also just easier to develop for a handful of known iOS/iPadOS targets compared to Android's unbounded set of screen sizes and device specs.
Android is simply a much worse platform to make money on. Users spend <25% as much as iOS users. Why would they prioritize that?
We’re moving almost entirely to Codex, first because often it’s just better, and second because it’s much cheaper. It’s a bet that they’re better now, but given capacity and funding, they’ll be better later too. The only edge Claude has is context window, which we do sometimes hit, but I’m sure that gap will close.
The most interesting parts of this to me are somewhat buried: - Claude Code has been added to iOS - Claude Code on the Web allows for seamless switching to Claude Code CLI - They have open sourced an OS-native sandboxing system which limits file system and network access _without_ needing containers However, I find the emphasis on limiting the outbound network access somewhat puzzling because the allowlists invariabl…
Link to the GitHub for the native sandboxing: https://github.com/anthropic-experimental/sandbox-runtime
Using a proxy through the `HTTP_PROXY` or `HTTPS_PROXY` environment variables has its own issues. It relies on the application respecting those variables—if it doesn’t, the connection will simply fail. Sure, in this case since all other network connection requests are dropped you are somewhat protected but then an application that doesn't respect them will just not work
You can also have some fun with `DYLD_INSERT_LIBRARIES`, but that often requires creating shims to make it work with codesigned binaries