AI coding agents have moved well beyond suggesting a few lines of code. They can inspect an existing project, investigate a problem, propose a plan, edit multiple files and review the resulting changes. For developers, that can turn hours of repetitive work into a much shorter supervisory task.
OpenAI's Codex is one of the clearest examples. The arrival of GPT-5.6 made the tool more capable, but it also exposed an uncomfortable question: what happens when a developer's productivity becomes dependent on intelligence rented from another company?
That question matters to more than developers. If an agency or internal team relies heavily on an AI platform, changes to its limits can affect delivery estimates, project costs and the availability of support. The clever assistant in the corner can quietly become part of the company's infrastructure, without offering the certainty normally expected from infrastructure.
When an assistant becomes part of the delivery process
Using AI occasionally is fairly low risk. A developer might ask it to explain an unfamiliar error, suggest an approach or help draft a test. If the service is unavailable, the work continues more slowly.
The relationship changes when an AI agent is given complete development tasks. The developer may begin by describing the required outcome, then allow the agent to explore the project, make changes and respond to review feedback. Over time, estimates and working habits can become based on that assistance being available.
This can be highly productive. It can also create a dependency that is easy to overlook because there is no dramatic migration or long-term contract. The change happens one useful prompt at a time.
Eventually, losing access to the agent may feel less like losing a search tool and more like losing a member of the delivery team.
The weekly limit is the new five-hour limit
Codex previously applied a five-hour usage window alongside its longer-term allowance. In July 2026, OpenAI removed the five-hour restriction for paid users, leaving the weekly allowance as the limit developers actually need to manage.
The removal was welcomed. Short usage windows could interrupt a productive session even when plenty of weekly capacity remained. The trouble is that GPT-5.6 can consume the weekly allowance surprisingly quickly, particularly when using its more capable Sol model with higher reasoning settings.
This has produced a recurring developer joke: the weekly limit has become the new five-hour limit.
That is an exaggeration for many users, but it captures a genuine planning problem. Codex usage is not a simple count of questions. It depends on the model selected, the amount of project context processed, the length of the conversation, the tools used and the output generated. As explained in our article about AI tokens and context, the text visible in the prompt may represent only a small part of the work being processed.
Two development tasks that look similar on a project plan may therefore consume very different portions of the allowance. A percentage meter offers visibility, but it does not tell a developer how many bugs, features or working hours remain.
Recent reports from Codex users describe weekly allowances disappearing during a single working day. These are individual reports rather than proof that every account is affected in the same way, but the volume of concern shows how difficult the system can be to predict.
Why repeated resets have created more uncertainty
Thibault "Tibo" Sottiaux, who leads Codex at OpenAI, has periodically announced resets for Codex and ChatGPT Work users. Developers who have exhausted their allowance understandably welcome them, and his posts regularly attract requests for another refill.
For users with most of their allowance remaining, the effect can be less generous than it first appears. Some have reported that an automatic reset also moved their next scheduled reset date. Someone receiving a small top-up today may then wait longer for the full allowance they expected later in the week.
That behaviour has not affected everyone equally, and some users have received banked resets they can activate themselves. Even so, it highlights the difference between additional capacity and predictable capacity.
A development team cannot plan confidently around the possibility that someone at the provider might announce a reset on social media. The problem is not a lack of goodwill. It is that the rules governing a professional tool can feel informal, changeable and difficult to translate into reliable working capacity.
The dependency is larger than usage limits
Codex is the current example, but the concern applies to proprietary AI coding platforms generally. The provider controls the models, commercial terms and access rules. A company building its workflow around one of them inherits several risks:
- Capacity risk: an allowance can be exhausted before planned work is complete.
- Pricing risk: included usage, paid credits and model costs can change.
- Availability risk: outages or model-capacity restrictions may interrupt active work.
- Model risk: a preferred model can be updated, replaced or removed.
- Knowledge risk: important project reasoning may remain inside private conversations instead of project documentation.
- Skills risk: developers can lose familiarity with work they routinely delegate and no longer examine closely.
- Data risk: companies must understand what source code and business information are being shared, along with the provider's plan-specific data and retention controls.
None of these risks means that AI coding agents should be avoided. They mean the tool should be governed with the same care as any other external service that becomes important to delivery.
Using AI without making it a single point of failure
A resilient AI-assisted workflow keeps the developer in control of the project, even when the agent performs a substantial amount of the work.
- Keep requirements, architectural decisions and current project status in documentation that the team controls.
- Review generated changes rather than treating a completed agent task as a completed development task.
- Maintain conventional source control, testing, deployment and rollback processes.
- Use lighter models for routine work and reserve the most expensive reasoning settings for problems that justify them.
- Avoid placing passwords, customer data or unnecessary commercially sensitive information into prompts.
- Record enough reasoning that another developer can continue without access to the original AI conversation.
- Estimate projects without assuming that unlimited AI capacity will always be available.
- Retain the ability to work manually or use an alternative provider when necessary.
The strongest use of AI is not blind automation. It is a partnership in which the machine provides speed and breadth while a human retains context, judgement and responsibility.
Codex may become more predictable. Usage limits may improve, and competition may encourage providers to offer clearer allowances. Developers should hope for that and continue asking for fairer, more transparent access.
In the meantime, AI can be an extraordinary lever, but it should not become the only load-bearing wall. A development process remains healthy when the tool can disappear for a day without taking the team's understanding of the project with it.