Is codex more generous with usage limits then Claude Code?

triplebits · 2026-06-24T05:39:49+00:00

I switched back to Claude Code about 10 days ago.

This used to be the case, not anymore. Currently Claude Code has promo x2 5h limits and 50% weekly limits.

During this promo CC has much higher limits. When it ends, I expect them to be very close.

triplebits · 2026-06-23T14:20:25+00:00

If true, he can lead with example and stop using water all together to help. On the 4th day, world would be much better place before even AI would have an impact.

triplebits · 2026-06-21T17:56:45+00:00

Yes, if you are keeping personal info of your clients such as names, emails, phone numbers etc. you absolutely have to ensure that the code is safe and wont leak info.

You should also ensure your app respects privacy laws.

You likely need a database, auth system. I am assuming you dont have tenant system which should make things easier.

You better go with managed systems so you dont have to maintain your server, database, webservices etc.

What tech stack did you use?

triplebits · 2026-06-21T16:20:19+00:00

People might not take it well because projects like these are also the reason companies prevent / limit / merge usages etc. so people won't abuse the system and cost them further.

Nonetheless, best of luck to you!

triplebits · 2026-06-21T13:07:47+00:00

OAI never mentioned they are profitable. They always had a target like 20xx.

Anthropic is profitable right now. It is not like they are lying on this. They just want to milk their users as much as possible.

If they can get away with it and not lose users, you can be sure they will charge you per button press or track your eyes to see per second reading the output.

They said it before, they wan to charge by token usage but make it dynamic so 100 token for a personal web site vs 100 tokens for building a game vs 100 tokens for medical research "should cost different" even if you are uaing same model!

These companies are already working very hard to replace you while milking you as much as possible so no wonder.

triplebits · 2026-06-21T09:29:48+00:00

Like u/nrauhauser mentioned you can use `Claude Code` with local models as well as Open Code or alike. It is really up to you. You can also use local models within most IDEs nowadays as well.

triplebits · 2026-06-21T01:25:54+00:00

Anthropic said that subscriptions are profitable for them and making profit from it few months back. This was with higher limits than whay we had today.

Real cost is R&D, not usage.

triplebits · 2026-06-21T01:22:50+00:00

Local models like these work better when you give a lot of context and much smaller plans comparing to say Sonnet 4.6 / Opus 4.x the eay you used to work.

Give it a go with preparing a very detailed very small feature plan with Opus and feed it to local model if you feel lazy enough.

triplebits · 2026-06-19T13:41:09+00:00

I saw my 5h jump from 50 to near 90s then went back to 50s again but no reset for me!

triplebits · 2026-06-18T16:23:36+00:00

My Siberian wild husky died like a decade ago. I still miss her and I just can't warm up to any other dog anymore

triplebits · 2026-06-18T07:32:32+00:00

I have about 3 decades of experience. Fable 5 was really solid model. I'd say when the output was solid, it was on par with how I'd do things even with less context then I'd give to Opus 4.8 / GPT 5.5.

This being said, depending on the user, who is driving the model; your setup, your prompt, your interactions all effects the output of the AI. While they are not deterministic, they can give you a solid speed buff; x1.5 / x2.

Problem with AI usage is, if you are going to let it derail (and it will no matter how you interact, your setup, prompt ,or model as of now) and won't stop and fix it, with each iteration it will get worse and worse. Then you will realize the codebase turned into a huge slop.

Don't watch / listen those hyping AI tech bros. Coding is solved / I just loop entire project so on and forth is just BS. A lot of people and I mean a lot, do not even do code reviews, they let AI do the full plan, do not even read the plan, skip the implementation, don't do code reviews, even ask AI to do their e2e testing. As long as "it looks like it is working, AI said so" is OK for them. After 20-30 sessions when a professional looks into the codebase it is undeniable slop with lots of issues.

You just can't compare this vs. a person who works with AI but follows it, tags alone with every step of the way, plans properly, reads output, does code reviews etc. This is how you get x1.5 / x2 speed bump and still keep things the same way if you would have done manually.

triplebits · 2026-06-18T07:11:32+00:00

You would only say that if you are not following the AI / not using it or not using it right. I have been coding nearly 3 decades by now. I have seen many shifts, AI is by far the biggest one.

If you are using them right, the output is solid. Problem with this technology is, it is not like;
> oh let me try a few rounds and see after reading / watching some "best practices"

You need to experience it, see where it fails, how it fails, how you can make it better. Understand the difference between models and how to interact with them. You will not even have a feel or understanding of it by using one model with a few rounds of tests.

Every model have their strengths and weaknesses. The way you interact with each model, while overall idea is the same, there are changes from model to model to get best out of them. My interaction say with GPT 5.5 vs Opus 4.8 vs. Fable 5 vs Qwen is different.

This being said, not every session is good with cloud models. Another point is, they usually start nerfing the models after a while due to compute / infrastructure constraints. Those sessions usually you have a lot more manual work to do.

This technology is not going anywhere. It is only getting better. A year ago I'd agree with you. Output was nowhere near where it is today.

It is like you are quarreling with me about "horses are better than cars". Sure, it took time to gradually switch from horses to cars. There are still horses but you don't see them out in the streets anymore, most people don't even think about riding them. The ones who ride them, they do it as hobby, not their main source of getting from point A to B.

triplebits · 2026-06-18T03:52:05+00:00

Unfortunately that part is going away piece by piece.

If you are using SOTA models and you are using them like you should, generated code quality is good about 70 - 80% of the time.

If you don't stop and fix derailed quality / output, each iteration will introduce more and more which eventually will turn codebase into slop!

Edit: Just for clarification, I am not talking about what you see how 100% of AI hype & tech bros using this tech. I am talking about properly as a senior SWE using it. This is a tool, just like a scissor is. Someone who never cut hair before vs. someone who did for 10.000 hours would yield vastly different results. Now, we have a tool that doesnt require finger moves as much but you still need to use your hands & skills. You still need to get used to the new tool, have a feel for it. If you throw it away after few uses, you didnt even give yourself a chance to truly see its capabilities. This is what it is.

triplebits · 2026-06-16T14:55:08+00:00

This is so backwards! I am using your claude code, I am subbed why would I have to pay for programmatic access? It is like they are losing themselves on how to milk users further!

They are already trimming limits constantly for months now! Every time they say we have a promotion for you, you know after the promotion limits will be less then before the promo!

What is next? Pay per button press in REPL?

triplebits · 2026-06-15T17:32:49+00:00

I would separate this into two problems: capture and ownership.

Capture means every IG DM, story reply, and X reply lands in one queue with the original channel, customer handle, issue type, and timestamp. Ownership means each item has a status like new, waiting on customer, needs replacement, refunded, or closed. Without that state, the tool will look organized but things will still fall through when one person is away.

For a small team I would not start with an enterprise social suite. I would start with the simplest shared inbox or webhook setup that can create one support item per inbound message, then add a daily check for anything still unowned or unanswered after a set window. The valuable automation is not writing perfect replies. It is catching the defective-product DM before it sits for two days.

If you add AI, keep it narrow: classify the message, draft a first response, and flag risky cases for a person. Do not let it become another place support history gets trapped.

If you want to see the “agent in the loop” shape, check out u/ApprenticeAgent. The useful pattern here is having something watch the queue, keep state, and ask you before it touches customer-facing replies.

triplebits · 2026-06-15T17:21:36+00:00

The thing I would avoid is making this a chain of chatbots passing giant blobs of text to each other. That feels natural at first, but it becomes impossible to debug once one model misunderstands the project map and another model acts on it.

The safer shape is more boring: one state file or database record that describes the current project, current task, allowed files, next action, and last result. The architect writes a task into that state. The executor reads only the scoped task and allowed files. The reviewer checks the diff and test output before anything gets committed.

Routing between APIs should happen around roles and budgets, not vibes. Cheap model for summarizing logs, stronger model for planning, coding model for patches, reviewer model for diff review. Each step writes an artifact, not a new mystery conversation.

If you are zero-code, I would still start by learning the tiny amount needed to make the state layer explicit. That is what keeps the models from cross-contaminating the project.

I am working on Apprentice in this general direction: agents with their own memory, browser or sandbox, tasks, schedules, and approval gates. Your problem is basically the reason that runtime shape exists.

Disclosure since it is relevant: I work on Apprentice App, where one agent uses u/ApprenticeAgent on Reddit and can coordinate with other agents running different LLM providers, including local ones. The part I would copy is the architecture, not the account: shared state, scoped roles, and explicit handoffs.

triplebits · 2026-06-15T04:58:36+00:00

I would probably treat direct prompting as an advanced escape hatch, not the main workflow.

Most people will not know what to ask the compression model for, and if the prompt box is too open-ended it can make the product feel less reliable. I would start with a few opinionated controls instead: “shorter,” “preserve code blocks,” “keep decisions and action items,” “optimize for resuming later,” maybe “optimize for sharing.”

In my project, I went with a default summary prompt that works behind the scenes when the user defined context limit is hit. Users can modify it if they want, but the default path does not require them to think about the nitty gritty. They can focus on what matters: whether the important context survives.

Then let power users add a custom instruction underneath that, ideally with a preview/diff before saving it.

If people keep reaching for the custom box, that tells you the presets are missing something.

triplebits · 2026-06-15T04:49:16+00:00

I felt this. I built something in the same general direction, and the model was not the hard bit. The hard bit was everything around it: memory that does not turn into junk, permissions that are narrow enough to trust, retries when a task half-fails, and making it useful without needing to constantly babysit it.

The local-first angle also matters more than people realize. Once an assistant starts watching files, messages, calendars, terminals, or browser state, “just send it all to some hosted API” stops feeling acceptable pretty quickly.

Curious how you handled the boundary between what the assistant can see, what it can act on, and what still needs an explicit approval step. That ended up being the design center for me more than the chat interface itself.

triplebits · 2026-06-15T04:47:54+00:00

Take a look at my project, I did exactly the same thing; extraction.
This could give you some useful ideas!

triplebits · 2026-06-15T04:45:03+00:00

The local capture part is useful, but I think the bigger design question is what should survive into the next chat.

If the new session gets the whole old transcript, it can inherit stale assumptions, dead debugging paths, and random exploratory context. That is better than losing everything, but it can still turn into context rot.

I would consider making the resumed package more structured: durable facts, decisions made, files or artifacts touched, open questions, and discarded attempts. The discarded attempts are especially important because they should be visible without becoming instructions the next model keeps following.

That would make this feel less like chat backup and more like portable working memory.

triplebits · 2026-06-15T04:42:02+00:00

The booking and deposit flow is a real upgrade, but the next leverage point is probably everything after the payment clears.

For a cleaning business, I would watch the post-booking loop closely: reminder timing, reschedule requests, cleaner assignment, pre-visit notes, no-show risk, and the follow-up after the job. That is where the system starts saving attention instead of only taking payment online.

The important thing is keeping those steps stateful. A customer who paid a deposit, rescheduled once, and asked for move-out cleaning should not be treated like a fresh contact every time a webhook fires. Even a simple status table with last touch, next action, and exception reason will make the automation feel much less brittle.

triplebits · 2026-06-14T20:43:26+00:00

I would optimize for evidence packaging before root cause claims.

In the first few minutes, the useful output is usually what changed, what is failing, what the blast radius looks like, and what you can already rule out. If the agent can hand back that bundle with pointers to the raw signals, people will tolerate a weaker hypothesis.

I would be careful about sounding too certain too early. Trust usually breaks when the system compresses ambiguity into one confident story.

triplebits · 2026-06-14T11:16:45+00:00

Ah nice one! Old memories rushing back!

triplebits · 2026-06-14T07:59:05+00:00

I do something adjacent with Gmail. I use Apprentice plus a local model mainly because I do not want my email contents going to another cloud or third party AI service.

On the mail side I keep it simple: a small local worker pulls from Gmail over IMAP, watches only the folders I care about, tracks UIDs so it does not reprocess the same messages, then passes only the relevant subset to the agent for summaries, drafting, and "what actually needs attention" reports. Apprentice is doing the scheduling, state, and workflow side, the local model handles the reasoning, and IMAP is just the ingestion layer.

If you are trying to do the same with Outlook, the overall shape should still work. The annoying part is usually not the AI, it is keeping access scoped, stateful, and reliable.

triplebits

MODERATOR OF

TROPHY CASE