How AI companies make it harder to stop working
LinkFor a while, I tried to be sensible with my Codex allowance. I had a weekly limit, so I treated it as a budget. If the next reset was seven days away, I could use roughly 14.3% per day. After two days, I should have used about 28.6%. Spend much more and I might run out before the end of the week. Spend less and I would have room for a larger project later.
Then OpenAI started resetting the limits early. Sometimes Thibault Sottiaux, who works on Codex and ChatGPT at OpenAI, announced a reset on X. Sometimes I opened Codex and found that it had happened without seeing any warning. My remaining allowance had returned to 100%, and the seven-day countdown had started again. At first, this looked like a gift. More usage for the same subscription. But the reset also wiped out what I had saved. If it arrived after two days and I had used only 10%, I had missed the chance to spend another 18.6 percentage points under my original daily budget. Someone who had already burned through most of their allowance received the same fresh 100% as I did. They had extracted more use from the previous cycle because they had spent first. Saving had become the risky strategy.
I stopped preserving my allowance for work I might want to do later in the week. I began using it as quickly as possible because another reset could arrive at any time. After a reset, the pressure became stronger. That new allowance might disappear too. There were days when I exhausted my weekly limit in a single day, partly because I hoped OpenAI would reset it again the next morning. No one told me to do this. Codex did not flash like a slot machine or promise a jackpot. OpenAI was giving me extra capacity, often after an outage or to celebrate a release or adoption milestone. Yet the pattern still changed my behaviour. An unpredictable reward taught me that restraint could leave value on the table, while immediate consumption protected me from missing the next one.
The strangest part was that I could always make the behaviour sound productive. I was not wasting tokens. I was testing a model, improving a project, learning a new workflow, or keeping up with a technology that might reshape my profession. When one project no longer justified another prompt, I could start a different one. There was always something useful I could ask the agent to do. The results were uncertain enough to keep that loop alive. A prompt might produce an excellent solution, a plausible mess, or something close enough that one correction could surely finish it. A failed run did not settle the question because the next run could behave differently. An unfinished task gave me a reason to continue, and an unused allowance gave me a reason to invent another task.
This is where coding agents begin to resemble systems we already know from gambling, gamification and the engagement design of social media. The comparison is not that a prompt is literally a bet, that writing software is the same as playing a slot machine or that using an agent amounts to a clinical addiction. It is about the structure around the activity: uncertain rewards, opaque costs, expiring budgets, surprise resets, near-complete work, status, the absence of a natural endpoint and the persistent suggestion that one more attempt is reasonable. Coding makes this structure harder to recognise because the possible reward is real work. A late night can produce a feature or a tool I genuinely wanted. Productivity gives the behaviour moral cover. It lets a person trade sleep and leisure for another run while believing that the software is saving them time. I want to understand what happens when a tool that promises to give us time back is built and sold through systems that make consuming that time feel rational.
A budget you cannot budget
LinkMy attempt to divide the weekly allowance into seven equal parts assumed that the percentage represented something stable. It did not. Even without the surprise resets, the number on the dashboard could not tell me how much work I still had available.
OpenAI explains that Codex usage depends on the model, the size and complexity of the task, whether the work runs locally or in the cloud, the amount of context, reasoning, tool use, retrieval, and caching. Two tasks that look alike can consume different amounts. Prompt length alone is not a reliable estimate. The company publishes broad ranges for local messages within a five-hour window, but those ranges vary considerably between models. Local messages and cloud chats share that window on Plus and Business plans, and additional weekly limits may apply. The documentation even advises users to check the usage dashboard regularly to understand their pace. (OpenAI, “Codex pricing”)
Anthropic describes its limit as a “conversation budget.” Claude usage depends on the length and complexity of a conversation, the selected model, the features being used, and the effort setting. Usage across Claude, Claude Code, and Claude Desktop draws from the same allowance. On the Pro plan, the session limit resets every five hours and a separate weekly limit resets at a fixed time assigned to the account. Anthropic can also apply other limits to particular models, features, or periods. (Anthropic, “How do usage and length limits work?”) & (Anthropic, “What is the Pro plan?”)
These limits may be reasonable ways to share infrastructure that is scarce and expensive to come by and operate. My objection is not that a limit exists. It is that the subscription gives the user responsibility for rationing something whose practical value cannot be known in advance. A percentage looks precise. Thirty per cent remaining appears to be a fact, but it is not thirty per cent of a project, thirty per cent of a working day, or thirty per cent of a known number of useful answers. It might contain several straightforward fixes. It might disappear into one difficult task with a large codebase, a long conversation, and repeated tool calls. The dashboard measures consumption after it happens, while the decision about whether a task is worth that consumption has to happen before.
Waiting can make that calculation worse. In my experience, returning to a Claude Code conversation after a break can produce a slower response and a much larger jump in usage than continuing it promptly. My hypothesis is that the conversation or part of its context has fallen out of the prompt cache, so the model has to process those input tokens again at the full rate rather than the cached rate. The dashboard does not show me enough to establish whether caching causes the increase. What I can observe is that taking time away can make the same conversation more expensive to resume. The subscription effectively imposes a penalty on pausing. Taking a break is taxed, while pushing forward without stopping preserves the cheaper cached context.
This becomes especially punishing at the boundary between five-hour windows. If I exhaust one window midway through a task, I cannot simply resume after the reset with the whole new allowance available for new work. The agent first needs the existing conversation, code and tool history in context again. I have seen that initial request consume several percentage points, often pushing the new window into double-digit usage almost immediately. If my hypothesis is right, part of the fresh allowance is spent reconstructing work I had already paid to establish in the previous window. The limit therefore creates another reason to keep going while the context is still warm, even when stopping would be better.
This gives the user a second job alongside programming. I have to decide which model a task deserves, whether I should shorten the context, whether a request is important enough for the remaining weekly capacity, and whether a smaller model might preserve more of the allowance. I monitor five-hour and weekly clocks while also trying to hold the actual software problem in my head. I am no longer only managing code. I am managing a bankroll of compute. Calling it a bankroll does not make a prompt a bet in the legal or clinical sense. The comparison describes the budgeting experience. I commit an uncertain amount of a limited resource before I know the quality of what I will receive. The result might save hours, create more work than it removes, or get close enough that abandoning it feels wasteful. Unlike a normal purchase, I cannot compare a clear price with a defined product before deciding.
The limits also divide time in ways that have little to do with the work itself. Software tasks do not naturally fit into five-hour windows. A weekly reset does not know when I have time for a personal project, when I need to sleep, or whether the current task has reached a safe stopping point. The clock belongs to the subscription rather than the project, but I am the one expected to organise my work around it. This is what the surprise resets made visible. I had built a plan around an allowance I did not control. The plan failed in my favour if I looked only at the new 100%, but it still taught me that careful conservation could be punished. The same basic uncertainty remains during ordinary use. I can see what percentage is left, yet I cannot translate it into useful work. Even a perfectly predictable meter would not tell me whether the next prompt would solve the problem or leave me with something almost correct. That uncertainty is what makes one more attempt so easy to defend.
Why one more prompt remains reasonable
LinkNow imagine I ask an agent to add a feature. It reads the repository, makes a plan and changes a dozen files. The implementation looks plausible. Several tests pass but one fails. Stopping now would leave me with code I cannot use, while another prompt needs only the failing test and perhaps a short correction. The agent fixes it, but the full test suite reveals a regression elsewhere. That regression also looks small. Each attempt moves the problem around without quite settling it, and each leaves me with a perfectly sensible reason to make one more.
Software development has always involved uncertainty. I might not know the exact solution, but experience usually gives me some idea of what it takes. I can inspect a failing test, trace the relevant code and estimate whether the repair needs one changed condition or a larger redesign. That estimate may be wrong, but it rests on work I can see and a process I understand. Once I hand the next step to an agent, I lose much of that basis for judgment. Before the response arrives, I do not know whether it will solve the problem completely, fix only the visible symptom, introduce a regression, rewrite more than necessary or uncover further improvements that now seem worth making. I cannot estimate the remaining work because the next prompt may change what the remaining work is.
The model’s non-determinism contributes to this uncertainty, but different output from an identical request is not the main problem. The user cannot know the quality and completeness of the result before generation. One failed attempt does not establish what another attempt, or a slightly revised prompt, will achieve. Research into code generation confirms both parts of this. Repeated requests can produce materially different code, and prompting strategies that include test feedback can improve success over several attempts. (Ouyang et al., “An empirical study of the non-determinism of ChatGPT in code generation”) (Hou and Ji, “Comparing large language models and human programmers for generating programming code”) Trying again is therefore often a reasonable engineering decision. If the first run misunderstood a requirement, I can clarify it. If a test exposes a concrete error, I can give that error to the agent. This resembles ordinary debugging. I observe a failure, supply better information and try a revised solution. The difference is that I can estimate the work involved in making a manual correction before I begin it. I cannot make an equivalent estimate for the correction prompt. It could finish the task in minutes or consume a large part of the remaining allowance and return a different unfinished state.
The difficulty is deciding when that reasoning no longer holds. After the agent has edited twelve files, reverting can feel like throwing away the time spent generating and reviewing them. Nine passing tests make the feature look close enough to rescue. The remaining failure gives me a specific next instruction, which is much easier to act on than the broader question of whether the feature is still worth pursuing. If the next correction breaks something else, my investment has grown and so has the amount of work that another prompt promises to recover.
Gambling research calls continued play intended to recover previous losses “chasing.” The term does not transfer neatly to programming. A gambler cannot repair an earlier losing bet, while another prompt really can repair broken code. In coding, the loss may be time, allowance, attention or damage introduced into the repository rather than money. The resemblance lies in how the purpose of continuing can change. I may begin by asking whether the agent is the best way to complete the feature, then end up trying to prove that the previous attempts were not wasted. Research on chasing losses cannot tell us how often coding-agent users make that shift. It gives us a useful question to ask about our own behaviour. (Auer and Griffiths, “An empirical attempt to operationalize chasing losses in gambling”)
Prompting also gives the user genuine influence over the result. I can add a test, narrow the task, change the model, supply missing documentation or explain why the previous approach failed. Those actions sometimes work, which makes this loop more persuasive than a simple game of chance. It also means I can explain every failure as a defect in my method. Perhaps the prompt was vague, the context file incomplete or the reasoning setting too low. Each diagnosis creates another adjustment to try. Gambling researchers use “illusion of control” for situations in which involvement and choice make people overestimate their influence over chance-driven outcomes. Coding agents are not games of chance, because expertise and feedback plainly matter. The relevant risk is believing that a better instruction has made the next result predictable when it has only changed the odds. (Clark, “Decision-making during gambling”)
Partial progress makes this harder to notice. A large diff, a confident completion message and a mostly green test run all provide evidence that something happened. They do not show whether I saved time after reviewing the code, repairing regressions and checking that the implementation solves the original problem. Activity is easier to see than net progress. Even a poor run can leave behind enough useful-looking work to make abandoning it feel premature. There is no universal number of failed prompts after which persistence becomes irrational. Difficult software has always required iteration, and refusing to retry would discard much of what makes these tools useful. The problem is that I must decide whether to continue before I can know what another attempt will cost or how much work it will remove. The agent supplies no natural dividing line between debugging the feature and debugging the agent. It creates the unfinished work, explains why the work is nearly complete and offers the next action that might finish it. As long as another outcome remains possible, stopping can always be made to look like the less rational choice.
An endless supply of useful work
LinkThe loop does not end when I finally complete a task. Coding agents also change which tasks I am willing to begin. Before I used them, a small personal idea had to survive the prospect of spending an evening setting up a repository, choosing dependencies, building the first interface and writing enough code to discover whether the idea was any good. That effort acted as a filter. Many ideas were interesting, but not interesting enough to claim the hours needed to make them real. An agent weakens that filter. I can describe an idea and receive a repository, a rough interface and a working first version before I have decided how much the project matters to me. This is one of the most valuable things about coding agents. It lets people test ideas that would otherwise remain inaccessible. It also changes the decision I face. I am no longer deciding whether an idea deserves to be started. I am looking at something that exists, runs and appears close enough to improve.
Research on goal pursuit calls this kind of head start “endowed progress.” In one series of studies, progress attributed to the situation rather than the person’s own effort increased commitment when people were still near the beginning of a goal, because the head start made completion appear more attainable. A generated prototype is not a loyalty card or one of the other goals examined in that research, and we do not yet have evidence that developers respond to it in the same way. The comparison still identifies an important change. The agent can supply enough early progress to turn “I could build this” into “I should finish this.” (Zhang and Huang, “How endowed versus earned progress affects consumer goal commitment and motivation”)
A prototype then produces work of its own. The generated application needs tests, accessibility checks, deployment, documentation and decisions about all the features that became apparent only after I could use it. Some of that work may be more demanding than creating the first version. The agent has saved the effort of reaching the prototype, but it has also moved me past the point where abandoning the idea feels free. Deleting a repository that already works in part feels different from never opening the editor.
Unfinished work does not necessarily stay at the computer. A 2026 meta-analysis found that unfinished work tasks were associated with more work-related thought during time off, especially affective rumination. An earlier diary study linked unfinished Friday tasks with impaired weekend sleep through rumination. Neither study examined coding agents or whether they create more unfinished work. They do explain why the failed tests, pending reviews and half-built features that agents leave behind can remain mentally active after the laptop closes. (Wendsche, Weigelt and Syrek, “Unfinished work tasks and work-related thoughts during off-job time”) (Syrek et al., “Zeigarnik’s sleepless nights”)
Running several agents in parallel multiplies this problem. The machine can investigate one bug while another writes a feature and a third updates tests. I still have to understand what each agent changed, judge whether its assumptions were sound and decide what happens next. The agents can create work faster than I can review it. Typing is no longer the bottleneck. My attention is, and every saved hour of implementation can return as several competing requests for judgment.
The agent can also create the next item of work inside an otherwise completed conversation. I have noticed this with Anthropic’s Opus 5 model, which has developed a habit of ending responses with a phrase such as “One thing worth flagging.” The requested task may be finished, but the model introduces another concern just before I could leave. In my experience, these observations are usually unrelated to what I asked or not useful enough to act on. I still have to read and judge them because occasionally the extra concern could matter. It might point to a regression, a security problem or a mistaken assumption. That possibility turns an irrelevant aside into unfinished business. Ignoring it can feel careless, while asking a follow-up keeps the conversation and the usage meter moving. The model has answered my question and supplied the reason for my next one in the same response.
This resembles the endless feed more than it resembles a conventional tool. A social media feed does not reach a final post and tell the user that they are done. It keeps producing another item, while the user has to choose the moment at which an unfinished stream becomes enough. Coding agents can remove the same stopping cue, but the next item presents itself as potentially useful work rather than entertainment. A model can always suggest another test, identify an adjacent problem, offer a refactor or ask whether I want it to continue. These suggestions are not automatically manipulative. Sometimes the agent notices something important, and that occasional value is precisely why its suggestions are difficult to dismiss. A consistently useless afterthought would soon become invisible. An afterthought that is useful once in a while teaches me to inspect the next one.
This is how a tool can save time without giving me more free time. Lowering the cost of one task makes room for another that I would not have attempted before. A finished feature exposes an improvement, and the response announcing its completion may expose another one. There is always useful work available because the agent helps produce both the output and the backlog surrounding it. The gain in capacity is real, but so is the expansion in what I now feel able to take on. Once this becomes the normal workflow, the larger backlog starts to look like capacity that ought to be used. AI companies and the culture around their products also teach users what capable, ambitious use is supposed to look like.
The serious user never slows down
LinkI had heard “not gonna make it,” usually shortened to NGMI, long before people began applying it to software engineering. The phrase made risk-taking look like insight and caution look like a personal defect. If the promised future arrived without you, the slogan implied that you simply lacked conviction and deserved to be left behind. I recognise that same move now when people talk about AI-driven workflows. Disengaging or choosing to work at a measured pace is no longer framed as a personal preference. It is treated as professional obsolescence.
AI companies do not need to use the phrase themselves. They provide the examples from which the culture builds it. Anthropic describes Claude Code as the “first stop” for any programming task within its product engineering team, shows designers setting up autonomous loops that write code and run tests continuously, and celebrates people outside software engineering building applications and internal tools. When the company doubled Claude Code’s five-hour limits in May 2026, it said the changes were for its “most dedicated customers.” (Anthropic, “How Anthropic teams use Claude Code”) (Anthropic, “Higher usage limits for Claude”) These are real capabilities and often useful ways to work. They also give intensive use a flattering identity. The serious user runs more agents, delegates more kinds of work and turns more of the day into output. Social media turns that image into advice about becoming a power user and warnings that anyone who does not reorganise their work around agents is falling behind. Some make the NGMI argument explicit and predict that software engineers who do not adopt coding assistants will lose out as LLM-assisted developers change performance expectations across companies.
I do not think that warning is entirely wrong. An LLM will not walk into an interview and take my job, but someone using one is already in competition with me. They may finish an assignment faster, charge less, maintain more projects or appear more productive because they can generate far more visible work. I use these tools partly because I enjoy them and partly because ignoring them would be a professional risk. What I reject is the conclusion that this pressure is mine to solve through unlimited personal adoption. The companies building coding agents do more than supply a neutral machine. They choose the subscription clocks, usage meters, notifications and defaults through which I experience it. They publish examples of autonomous loops and parallel agents, celebrate their most intensive users and present wider adoption as the direction of professional software development. The product and the story told about the product point the same way. A capable user keeps more agents working and finds more work to give them.
None of this requires a secret plan to keep me engaged. A system can reward a behaviour without its designers having set out to produce that exact effect. I can observe that saved allowance loses its value, another prompt remains difficult to price, unfinished work follows me away from the desk and intensive use receives professional status. Those effects belong in an assessment of the product as it exists. The providers can study them, change the design and decide which behaviour they want to make easier. Early adopters are where such effects are likely to appear first because they use the products more heavily and reorganise more of their work around them. If the problem never spreads beyond that group because the feedback leads to a better product, that would be a success, not evidence that the warning was misplaced.
Yet knowing this does not remove the pressure. I can still spend an evening testing a new model, improving agent instructions or learning how to supervise several tasks at once and call it professional self-defence. The work may genuinely make me better at my job, which is what makes the boundary so difficult to draw. NGMI supplies the social pressure, the agent supplies uncertain but sometimes remarkable results, and the subscription supplies an allowance that loses its value if I do not use it. Together they turn a structural problem into a private routine of keeping up. Adopting an agent and exhausting its limits are plainly different choices, but they begin to feel like points on the same scale of commitment. By the time I reach a limit, stopping can carry more than the cost of leaving the task unfinished. It can feel like choosing to fall behind.
The limit only changes the work
LinkAt work I switch constantly between Claude Code and Codex. I do not do this because I have carefully matched each model to the kind of task it performs best. I do it because both have limits, and I want to make sure that I have started using one before I exhaust the other. If I spend too much of the morning with Claude Code, I risk reaching its limit while the Codex allowance has remained untouched. If I use Codex too heavily, I preserve Claude capacity that may expire without giving me anything in return. I spread work between them to keep both subscriptions productive and to avoid depending on one clock. The result is that choosing a tool is no longer only an engineering decision. It is also an exercise in balancing two supplies of expiring compute. That calculation follows me through the day. I look at the remaining percentages, think about which reset will arrive first and decide whether the current task deserves the provider I am about to use. This is attention I am not giving to the software. The agents are supposed to remove mechanical work so that I can concentrate on judgment, yet their limits add a separate management problem that has nothing to do with whether the code is correct. I have become responsible for keeping two machines occupied without letting either one become unavailable at the wrong moment.
Sometimes I misjudge it or simply stop watching the meter closely enough. A limit arrives while the agent is in the middle of a task. It may have changed several files or left a plan half-executed. Continuing myself is not as simple as opening the last file it touched. I have to understand what the agent intended, inspect what it changed and decide whether the unfinished implementation is still the right approach. Research on interrupted programming describes some of this recovery work. In an exploratory study of 10,000 programming sessions, developers usually navigated through the code and sought other sources of task context before they resumed editing. Only ten per cent of the observed sessions returned to coding within a minute. (Parnin and Rugaber, “Resumption strategies for interrupted programming tasks”) The study examined developers resuming their own interrupted work, not people taking over from an agent. It cannot measure the burden of that handover. It shows that rebuilding task context already costs time when the developer was the person doing the original work.
I often decide not to pay that cost. Instead I switch to work that fits the interruption. I review code an agent already completed, test a feature, inspect another project or write feedback that I can give the agent after its allowance resets. I remain busy and the work is useful. That makes the disruption easy to dismiss, but I am no longer deciding the order of work according to what the project needs or where my attention is strongest. The reset schedule has decided that the implementation pauses now and review happens instead. When capacity returns, I am expected to switch back, reload the task and continue from wherever the machine stopped. The limit has not given me a break. It has rearranged my work.
Continuing manually also begins to feel strangely wasteful. Why spend the effort writing the remaining code myself when the “magic box” can do it after the reset? Discarding what the agent produced feels worse because I have already spent allowance on it. Had I known the task would stop here, I tell myself, I would have used those tokens on something else. This is another version of the chasing problem. The earlier expenditure makes preserving the current attempt feel more important than deciding afresh how the task should be completed. The difference from gambling remains important because the generated code may have genuine value. That value is exactly what makes waiting for the agent, switching providers or reshaping the rest of the day appear reasonable. A usage limit could create a pause in which I reconsider whether to continue working. In practice it keeps the loop alive, but not on my terms. I can move the task, move to another task, or prepare work for the moment the allowance returns. Each choice is productive enough to defend, while none returns control over the day to me. The five-hour window does not need to sell me more credits to influence my behaviour. It has already determined when one kind of work stops, when another begins and when the unfinished task becomes available again.
Productive compulsion has no warning label
LinkI often prepare to leave my desk by checking that every agent is running and has something to do. Leaving a machine idle feels like wasting time that could have been spent making progress while I am away. The habit sounds efficient because sometimes it is. I can return to completed research, a proposed fix or a set of tests that ran without me. But it also means that leaving the desk is no longer a clean end to the session. Before I go, I create several reasons to come back. Each agent may finish, fail or ask for a decision, and I know that my absence is now the thing preventing it from continuing. For a while I even installed the app on my phone so that I could orchestrate agents away from the computer. I quickly noticed what that did to my attention and removed it. The phone turned any moment into a possible “productive” session. I could check whether an agent had finished, read its explanation and send the next prompt without making the deliberate choice to sit down and work. Removing the app restored some friction, but it did not remove the pull. I have still walked back to my computer to see how the agents are doing and send a quick follow-up. The action takes only a minute, which makes it easy to excuse. The task then remains active in my mind, another result is on its way, and the minute becomes an extension of the working day.
I have also continued working at times when I otherwise would have stopped, especially during the period of frequent Codex resets. The possibility of another allowance arriving made unused capacity feel temporary. I could tell myself that I would finish after this task, but finishing one task freed the agent for another, while another surprise reset might reward me for having consumed the previous allowance quickly. None of this looked like lost time from inside the session. I was producing software, learning what the models could do and receiving more value from a subscription I had already paid for. The work itself supplied the justification for continuing it. All this makes harmful agent use harder to recognise. A person repeatedly checking a betting app is culturally understood to be taking a risk. A developer repeatedly checking agents is supervising work. Staying awake becomes dedication, running several uncertain tasks becomes orchestration and exhausting an allowance becomes getting value for money. The code may be useful, which makes those descriptions more than excuses. Yet usefulness does not tell me whether I should still be working, whether I am capable of reviewing the output carefully or what the session displaced. A feature completed at midnight remains a completed feature even if the cost was sleep, attention or time with somebody else.
Other developers have described stronger versions of the same pull. Armin Ronacher writes that after getting hooked on Claude he spent two months prompting excessively, sleeping too little and building tools he ultimately had little use for. (Armin Ronacher, “Agent psychosis: Are we going insane?”) Steve Yegge describes juggling four or five agents at once and struggling to close his laptop before 2 a.m. He calls agentic coding “addictive” and compares its unpredictable results to the intermittent reinforcement of a slot machine. (Steve Yegge, “The Brute Squad”) Simon Willison calls running several coding agents in parallel effective but “mentally exhausting.” (Simon Willison, “Vibe engineering”) Addy Osmani describes five or ten simultaneous sessions generating work faster than a developer can maintain the corresponding mental models. (Addy Osmani, “Human judgment doesn’t leave the software factory. It relocates.”) These are personal accounts, not evidence of how common the behaviour is. They show that the pattern I experienced is not mine alone. The cost of producing another implementation can fall faster than the cost of understanding whether it should exist at all.
Research on working time gives us less dramatic language for the same underlying harm. Work intensification means that more activity is compressed into the working day. Work extensification means that work spreads into times and places that previously sat outside it. A study of IT workers found both patterns in an industry where technical commitment and apparent autonomy can encourage people to work longer and take personal responsibility for keeping their skills current. (Howcroft and Taylor, “Experiences of working time intensification and extensification”) The study predates widespread coding-agent use, so it cannot establish that agents cause either pattern. It gives names to what I experienced. Several agents filled my day with more output to inspect, while remote access carried their supervision beyond my desk. The phone app made this visible because it removed a boundary I still valued enough to restore.
An agent running in the background does not demand attention continuously, but it keeps work available. A notification or the thought that an allowance has reset can bring me back without anyone issuing an instruction. Gamification uses game elements in non-game systems to influence participation, although its effects depend on the users and context. (Hamari, Koivisto and Sarsa, “Does Gamification Work?”) Agentic coding offers a stronger reason to return than a badge or streak. There may be a real solution waiting when I check. That makes each return defensible even when the cumulative pattern is one I would not have chosen in advance.
Technical skill changes what an agent produces, generated work can retain value, and intensive use does not by itself indicate addiction. The concern is control over attention and over the point at which work gives way to the rest of life. Product dashboards account carefully for the resource supplied by the provider. They show percentages, reset times, credits and plan limits. They do not account for the resource supplied by the user. They do not show how long I have remained mentally engaged, how often I returned after intending to stop, how many unfinished agents are competing for attention or whether the saved implementation time became rest or merely more work. The system can appear efficient while transferring its costs into places the meter never records. A tool sold as a way to save time should not measure success only by how much machine capacity I managed to consume.
Make stopping a valid outcome
LinkI began this article with a period in which I tried to use my Codex allowance as quickly as possible because OpenAI might reset it again. Burning through a weekly limit in a day sounds absurd from outside. Inside the system, saved capacity might disappear while spent capacity might be replaced. Every unfinished task offered a plausible next step, and switching between Claude Code and Codex kept the work moving when either product imposed a pause. I was responding to the incentives and escape routes the products placed in front of me.
That does not absolve me of every choice I made, but it changes where the criticism belongs. Telling users to exercise more discipline is inadequate when the product makes conservation feel wasteful, continuation feel productive and stopping feel like falling behind. I do not need to know whether each effect was intended before I can hold the provider responsible for the system it operates. The companies decide how allowances expire, what happens during surprise capacity increases, how prominently reset clocks and percentages are displayed, whether interrupted work resumes efficiently and how aggressively autonomous work is presented as the new standard. A five-hour window is a design choice. A weekly allowance that cannot roll over is a design choice. Calling the heaviest users the most dedicated is a choice. None forces a particular person to continue working, but together they determine which behaviour the product rewards and which behaviour it makes costly. Once those effects are visible, continued inaction becomes a choice too.
Limits may still be necessary. Compute is expensive, shared infrastructure needs allocation and a subscription cannot promise unlimited access to a scarce resource. The alternative is not a product without boundaries. It is a product whose boundaries do not turn the user into a full-time trader of uncertain capacity. Unused weekly capacity could roll over within a cap, and surprise increases could add to what a user saved instead of erasing the value of saving it. The interface could estimate the likely cost of a task, allow a user to set a ceiling before an agent starts and produce a clear checkpoint if that ceiling is reached. Resuming after a reset should not consume a conspicuous part of the new allowance merely to reconstruct the previous session. A dashboard could show how long a person has been engaged and how many agents remain unfinished alongside the provider’s percentages and clocks. Quiet hours could respect working hours chosen by the user. The product could present waiting, saving capacity and ending a session as normal outcomes rather than empty space awaiting another prompt.
Removing the phone app showed me that a small amount of friction can help. I had to notice the effect first, decide that I disliked it and impose that boundary myself. The product had made remote orchestration easy. Restoring a distinction between work and the rest of my day was my own customisation. That pattern is familiar across technology. A company removes friction in pursuit of a more capable product, while the user has to restore it to protect a boundary the product does not measure. Coding agents deserve more scrutiny because engagement looks so much like accomplishment. The feature may work. The tests may pass. The subscription may have delivered excellent value. I can still have spent more of my attention, my evening or my sleep than I intended. Success at the task and harm to the user can exist in the same session.
AI companies promise to give us time back. OpenAI says Codex helps users “write, review, and ship code faster.” (OpenAI, “Codex”) That promise should include some responsibility for the systems that immediately invite us to spend the saved time again. Companies cannot decide when every developer should close a laptop, nor should they. They can stop designing subscriptions in which unused capacity resembles a loss, uncertain progress makes another attempt perpetually reasonable and the most visible measure of success is how completely we consumed what they sold us. A product designed to save time should treat stopping as a successful outcome.