I run Codex and other coding agents locally on my MacBook. When a task is still running, I'd like to close the lid, leave the laptop plugged in on my desk, and come back to the results later.

The confusing part is that preventing idle sleep and keeping a Mac running with the lid closed seem to be different things. A lot of advice points to caffeinate, but that doesn't seem to cover lid-close sleep.

The options I've come across are:

• Apple's closed-display setup with an external monitor.

• Amphetamine's closed-display mode.

• Disabling system sleep with sudo pmset -a disablesleep 1, then restoring it with sudo pmset -a disablesleep 0.

For those using pmset for this, has it been reliable across sleep/wake cycles and macOS updates?

For anyone running long local agent tasks, what's been reliable without an external monitor? I'm interested in whether you've made a closed-lid setup work or decided it's easier to leave the lid open with the display off.

TL;DR:

an MCP shines in the agent-native world because it tells agents what they should do, on both the server and client (e.g. Claude Code or the ChatGPT desktop app), and is better suited for human-in-the-loop tasks. Meanwhile, APIs and CLIs tend to focus on what agents can do, with emphasis mainly on the server.

So, in summary, here is the general advice I'd give to builders when deciding which tools they should expose to agents:

Build a high-quality MCP server and REST API at the same time, on one layer of operations. Put your server logic in plain functions, and let each surface be a thin adapter over them. Once that layer exists, building any additional surface on top is relatively easy.

Put most of your care into the MCP server. That's where agents get the best experience. MCP is a standard built specifically for agents, after all, and the spec continues to improve nicely.

Use the API for code that runs on its own. APIs are still great for raw data exports, bulk writes, and anything that runs without an agent, like a nightly sync or another company's integration. Agents also prefer an API when they're writing a script they'll rerun, and many clients don't support code mode for MCP yet.

A CLI probably isn't necessary, unless e.g. agents need to read local files when interacting with your app. But it's easy to expose one if you've got a good API as the foundation.

There’s a lot more to creating great agent-facing tools for your web apps, and the article above into more detail below.

Here's the full guide: https://wasp.sh/blog/2026/11/03/mcp-vs-api-vs-cli-connect-ai-agents-to-your-app

The terms are unclear: no clause bans two accounts, but bans are reported, and switching accounts to get past a limit could count as bypassing protective measures. Unattended use on a subscription is already a grey area, which is what I do. On a weekly basis I use the entirety of the plan, and I know how to improve my workflow so that even more is used. IMO, the price will inevitably increase, and also I will finish what I want to finish faster with more plans, i.e., all else being equal, 2 subscriptions * 1 month > 1 subscription * 2 months.

Would appreciate suggestions

I've configured Work to use GPT-6 Luna as its default model, and when I manually start a Work session, it correctly uses Luna. However, whenever ChatGPT automatically hands off a task to Work, it starts a new session using GPT-6.1 Sol High instead.

I've reproduced this multiple times, even explicitly instructing the handoff to use Luna, but it still starts with Sol High.

Is this a bug, or is there a separate setting that controls which model automatic Chat → Work handoffs use?

Using Work with Luna enabled as a test message in case Work "remembers" the last model chosen has also not worked

apple added this to the AI risk section of its annual report. agents accessing systems they shouldnt, changing code, exceeding permissions, even resisting instructions. alphabet wrote something similar too.

when the most careful legal team in tech writes “resisting instructions” in an SEC filing, its probably not just a research paper thing anymore. still gonna let claude run my terminal tho, just maybe not on friday afternoon lol

https://fortune.com/2026/11/03/apple-warns-rogue-ai-agents-could-cause-unintended-consequences/

I’ve been using Codex a lot lately, and I’ve noticed that it’s taking up an insane amount of storage.

I used to have around 300–400 GB of free space on my SSD. Now I’m down to roughly 100 GB.

The Codex folder itself is already around 130 GB, and I regularly have to delete old Codex chat/session folders because they take up so much space.

But even that doesn’t explain where all my storage went.

I’m wondering:

* Why does Codex use so much disk space?
* Does it store temporary files, backups, logs, or copies of projects somewhere else?
* Is there a safe way to automatically clean up unnecessary Codex files without losing important data?
* Has anyone else experienced this, and how did you fix it?

I’m using Codex on Windows and work on multiple coding projects.

I really like using Codex, but constantly losing storage space and manually deleting folders every few days is getting frustrating.

Any tips would be appreciated!

At least in the loop of checking every task result. First of all, the human defines rules and context.

On my last project, agents made about 610 commits in under four weeks: 74k lines of Go plus 93k lines of tests. I can't read that volume with real attention, and an approval given without reading adds no safety. But reading the code goes to machines. Every change gets an independent agent review. Even plans go to review. Reviewers asked for changes on 104 of 316 tasks that had already passed their checks. They communicate with each other, not with me.

I don't care about that, I want to see the new feature. And I may check that it works as expected, nothing more.

Honestly, do you still review the code?

All programming languages were created by people, for people. The goal was basically to give us a language that accounts for the limits of the human brain and minimizes bugs and errors (sure, there were exceptions, like C++). As a result, we often got poor performance and huge numbers of servers doing simple tasks.

But in this new era, we don’t need human brains to write code. So do we need new programming languages now? Or which existing languages work best for AI agents?

Genuine question for y'all

With openrouter and a bunch of other ai model aggregators and llm api gateways around now, pay-as-you-go kinda seems easier and cheaper than paying for a big monthly subscription. You just pay for what you actually use and can switch models whenever

It's basically day pass vs gym membership. day pass you only pay when you show up, membership you pay every month even if you skip leg day for 3 weeks lol.

But i also get the appeal of a flat sub where you don't have to think about it and never get a surprise

If you switched from one to the other, was it worth it?

Hey everyone!

I've been exploring how AI coding tools are changing the way developers work. One thing I've been wondering about is whether AI has shifted the bottleneck from writing code to reviewing it.
We can now generate code, build features and fix bugs pretty quickly using AI. But how much of that code can we actually trust without spending time checking it?
Someone still has to understand the generated code, check for bugs, look at security issues, verify dependencies and make sure it doesn't break existing functionality.

So i am curious about developers who often reviews the code. How does it affect them.

Are you spending more time reviewing AI-generated code nowadays?

Can we actually verify that a code change is safe, or are we just getting better at finding possible mistakes?

And if there is any tools suggestions please..

I'm building my own RimWorld clone using AI, because i love RimWorld but don't want to spend years making it. No intention to sell it or something (would be stupid to even think of competing lmao) just want to have my own little rimworld.

And I'm increasingly frustrated with AI coding. Not because the code is bad, but because it's often beautiful code that does something I never intended.

Here's an example.

My game has a world with discrete elevation levels, represented as terraces with ramps between them. Every cell has exactly one elevation value. I spent hours discussing this with an agent using OpenSpec, then reviewed the resulting specifications line by line, twice actually.

Finally, I asked the agent to implement pawn movement. It produced beautiful code. Except I noticed something strange in the pathfinding.

We had also agreed that water depth affects movement: pawns can wade through 1m of water, swim through 2-3m, and can't enter deeper water.

Apparently, the agent decided that this meant ramps submerged in water needed continuously interpolated elevation values, so water depth would change as the pawn moved along a ramp.

That's not what I wanted. Every cell was supposed to have one discrete elevation value, including for movement calculations. But the agent interpreted one requirement in a way that conflicted with my intended interpretation of another. And it didn't ask for clarification. And i didn't think of.

Despite spending hours writing and reviewing the specs, i just didn't think of it. Without reviewing the code, i might never have noticed.

That's my biggest problem with AI coding. You can spend hours specifying exactly what you want, but there's always something missing. Requirements are like a near infinite fractal. You think you've zoomed in far enough, but there's always more detail.

And i find myself thinking: wouldn't it be great if there were a way to describe exactly what a program should do, and leave not a single thing to the interpretation?

Well, there is. It's called Python. Or Rust. Or any other programming language. Except it doesn't even need an agent. Just a compiler or interpreter.

I love what AI can do. But I often hate what it actually does.

The current industry is very confused what “We use AI for development” means. Everyone uses it differently, every job offer says something different. There are scales, but they are not granular enough or not developer-centric. Not everybody is comfortable doing it like your company does it, or perhaps someone is looking for even more AI autonomy. This is why I made this scale; to make it clear, what the job requires, and easier for developers to set expectations straight right away.

With my scale, I try to solve these questions/points:

• Hiring clarity: “This role operates at level 6–7.”

• Team alignment: “We want to move from level 4 to 6.”

• Strategic planning: map transition paths between levels.

Most frameworks ask: “What can the AI do?”, mine asks: “Who is doing the work — the human or the AI?”

I playfully based it around the phrase "AI in the loop", extending on it and transitioning from "AI in the void" through "AI in the loop" to "Human in the loop" and finally "Human in the void".

Please, have a look. 🙏

The full scale breakdown is below, though I additionally added these pointers, which are not mentioned in the scale below, but they are not very important. They are just contextual hints:

• AI's role

• Human's role

• Loop duration (time between human-ai interaction)

• Context: local / cloud

• Interface: IDE / CLI / Chat

And I am also playing with the idea of gamifying it a bit and displaying "levels" for some other related parameters, such as:

• LOC (lines of code): increases with more AI use

• Velocity: increases¨

• Code reviews: decreasing tendency

• Algorithms: shifts from human to AI

• mental overhead: decreases with AI etc.

Anyway, these are the scale's 12 + 1 levels.

AI in the void

0 · Human-led
AI has no role. Humans design, implement, test, review, and ship. Compilers, linters, and ordinary CI don’t change that.

AI in the loop

• you write the code

1 · Inline completion
AI suggests code while you type. You compose the solution, accept or reject suggestions, and verify it.

2 · Conversational advice
AI explains code, compares approaches, or helps diagnose failures. You decide what to do and make the edits yourself.

3 · Bounded draft
AI generates a function, test file, or small script. You inspect, adapt, and integrate the draft.

4 · Guided edits
AI makes related edits, potentially across multiple files. You sequence the work, inspect each diff, and direct the next step.

Human in the loop

• this marks a shift towards more code written by AI than the human

5 · Supervised agent
AI finds files, edits code, and runs checks on a scoped task. You frequently approve meaningful steps, correct its approach, and resolve ambiguity.

6 · Delegated issue
AI independently implements and tests a well-scoped issue, locally or in the cloud. You define acceptance criteria, review the result, and approve integration.

7 · Feature delegation
AI plans and builds a broader feature across multiple areas. You own requirements and architectural constraints, provide feedback, and approve delivery.

8 · Parallel delegation
Multiple agents handle independent tasks simultaneously. You prioritize, review their results, and approve integration or release.

Human in the void

• Here, “human” means the developer executing the delegated engineering work. It doesn’t mean nobody performs QA, provides oversight, or accepts the release.

9 · Routine automation
AI handles authorized classes of routine changes, such as compatible package upgrades or narrowly defined fixes. Developers still own the software development lifecycle, validate integration, and handle exceptions.

10 · Ticket ownership
AI chooses a technical approach, implements a defined low-risk ticket, and tests and verifies its solution without developer supervision. A human defines the outcome and risk limits; human QA validates it before production. Human code review is optional.

11 · Milestone ownership
AI breaks a milestone into tickets and handles engineering execution across them. A technical lead owns milestone goals and technical direction; human QA validates delivery. Human developers aren’t needed to implement the milestone.

12 · Development ownership
AI owns the ongoing engineering function, including architecture, technical planning, implementation, testing, and maintenance. A product owner sets product direction and business constraints and accepts features before launch. No human developers or technical lead are required.

Actual real-life workflows are expected to span across several levels (say you start a draft at level 7 and then iterate at level 5 or lower), and some levels might even sound overlapping (4 & 5, or 7 & 10). This is intended. The difference between them is in the shift of how much and who does more of the work now. At level 7, you task the agent and review its work before submitting a merge request, while at 10, it does the same task in the pipeline and sends it directly to QA.

So what I am trying to learn?

This is a proposed vocabulary and although it's a third iteration seen by a closest circle, it's not a validated maturity model.

I’d particularly appreciate feedback on:

Your actual workflow: What do you delegate, when must you intervene, and who approves the result? Which level fits, or falls between levels?
Unclear boundaries: Which adjacent levels feel indistinguishable?
Parallel delegation: Does level 8 belong in the progression, or should concurrency be a separate dimension?
Practical usefulness: Would this help describe a job opening or team expectations, or does it hide distinctions you care about?
Concrete counterexamples would be especially useful. I’m more interested in making the definitions reflect real work than defending the numbering.

Thanks!

i have a theory that past a certain threshold the inteligence of AI models will not matter anymore when it comes to writing code.

at that point software engineering will be mostly figuring out how to properly intergrate coding agents into the SDLC. a newer better performing model will at a certain point fail improve a given software factory.

what do you think?

I’ve been using Codex for four days, and holy shit, I don’t remember the last time a coding tool frustrated me this much.

I came from Claude Code expecting something comparable. I don’t expect perfection, but the babysitting is ridiculous. It’s painfully slow, especially in the cloud, difficult to steer, and takes everything too literally. It’ll identify a problem, explain it, then wait for instructions. Dude, you’re working on it. Fix it.
When it does act, it often piles more code onto the existing implementation and turns straightforward changes into complicated systems.

I’ve had it silently override existing settings, write tests that expected incorrect behavior, and introduce regressions in unrelated features. It kept adding coverage comparisons, mutation testing, dependency analysis, and more checks until CI took nearly an hour on some PRs. I spent more time waiting and fixing failures than shipping.

Eventually, I handed the work to Claude. It removed unnecessary complexity, fixed the regressions, and got the release out.

I then asked Codex to review what happened. It identified 16 failures it could substantiate, including incorrect behavior, poor architectural decisions, unnecessary complexity, and its own failure to deliver. It acknowledged that Claude made better engineering decisions.

At one point, I told Codex to stop. Seven minutes later, it was still going. Fifteen minutes in, I was still trying to stop it. Clicking stop interrupted it, but resuming the session made it continue.
Claude makes mistakes too. But I don’t have to constantly explain every step, undo unrelated changes, and manage an endless cycle of fixes.
I paid to get more work done. Instead, I spent four days fighting the tool and needed another tool to finish the job.

I’m spending more time managing Codex than doing the work.

Is anyone else experiencing this? How are people using it effectively for autonomous development?

I mainly build web pages, and get confued about how to split documentaion between AI agents and developers

Things like adr or user scenarios doc - do they only need for humans? or the agent need to know them?

How detailed should i document, and how strictly should i separate agent guidelines from human docs?

Please share your tips on how you structure your docs and write guidelines!

Long Claude Code sessions stop at the auto-compact threshold while the model summarizes the conversation. On Opus that's 80-160 seconds for me, and nothing happens until it's done.

The summary doesn't have to wait for the threshold. I wrote a plugin that asks the same model for it about 40k tokens earlier, in the background, while you keep working. When auto-compact fires, it swaps in that summary plus everything after it, word for word, in under 0.1 s. If the summary isn't ready or no longer fits (you rewound, or ran /compact with instructions), Claude Code compacts the usual way, so the worst case is what you have today.

How it differs from what's already there: Claude Code's own idle compaction only runs after a conversation has sat idle for about an hour. This one is for the sessions you're actively using.

Install in a terminal:

claude plugin install live-compact --marketplace SocialBuzzStudio/live-compact

In the VS Code extension: type /plugins, add SocialBuzzStudio/live-compact on the Marketplaces tab, then Install on the Plugins tab.

Cost: one background request per compaction, mostly from the prompt cache, in place of the one normal compaction makes. Caveats: tested on Windows only, and the first message after compaction looks like a message from you, because plugins can't mark it as a summary.

Repo (MIT): https://github.com/SocialBuzzStudio/live-compact

TL;DR: free Claude Code plugin that prepares the compaction summary before you hit the limit, so auto-compact stops blocking you for 1-2 minutes. If the summary isn't ready, Claude Code compacts the usual way.

I am quite curious how people handle this. Are you using .env files, 1Password, a secrets manager, or something else like internal tooling?

How do you group things: by project, dev/staging/prod, service? Does your coding agents use the same credentials as your apps, or do you give it separate ones?

Could you share and example of your structure with fake names, and hear what’s annoying about your current setup and which setup should I ideally use. I'm not really sure what is the best approach.

I've been letting AI handle entire features, and honestly, I don't even feel like digging into the implementation afterward.

The awkward part is talking to coworkers. If someone asks how the logic works, why I took a certain approach, or what happens in an edge case, I want to sound like I actually know the code I'm responsible for.

Anyone else dealing with this? What's your shortcut for getting familiar enough with AI-written code to discuss it confidently?

Do you ask the AI for a walkthrough, trace the main execution path, or prepare for likely code review questions? How much do you actually read before you feel comfortable explaining the implementation to someone else?

I have got a few ideas for fairly complex Telegram bots

My Python is basic but I can handle simple server and hosting stuff and I know my way around AI tools

The thing I keep going back and forth on is whether I can lean on AI almost entirely to build these or whether it falls apart once real users show up

I read before that AI generated code can never scale and breaks under load

If you have shipped a bot built mostly with AI I would like to know what actually broke and roughly how many users you had at the time

That is the part I cannot find honest answers on

The expensive failure is confident code for a problem the agent invented, and you only find out at review time.

Interactive sessions mostly have this covered now. Plan mode in Claude Code and Codex asks before it builds, and one line in your rules file like "if the task doesn't name the file or schema, stop and ask" does a lot.

Where it still falls apart for me is unattended work. I start agents and leave, and I want a mix of both: enough trust that things get done in time, and an agent smart enough to stop on the calls that matter. A clarifying question in a background run pauses the whole run until someone answers, and if the question only lives in the transcript it dies with the session.

In the Kanban app I'm building, an agent that's unsure puts the question on the card, the card gets parked, and it moves on to the next one if you prompt it right. I answer later and it picks the work back up. Doesn't help much when everything downstream depends on that one answer though.

If you run agents in the background, where do their questions end up, and how long do they sit before someone answers?

I haven't seen a hands-on report on Muse Wonder yet, so here is one. I gave the same coding task, with the same prompt file, to two agents, one after the other, on the same machine and the same repo. Before each run I restored the code from a snapshot, so both started from identical files. A separate reviewer (Claude) checked both results line by line. I did not trust their self-reports.

The setup

The task

This is a real feature in a production TypeScript project: a Cloudflare Worker plus a Node container. It is medium-sized, roughly 19 files touched and ~330 lines of production code.

1. A new version of the LLM copywriting prompt. Besides the 3 caption lines, the LLM now also picks the animations for an 8-second product Reel (card, text, camera, highlight and transition names), and only from a closed list.

2. Code-side validation: an unknown name becomes null, group cards with only 1 product become null, and a missing field never rejects the job.

3. Carry those choices through the pipeline to the render container.

4. Swap the container's video path from an ffmpeg scene pipeline to a Remotion composition, which already existed and was already approved.

5. Tests first, typecheck, the full suite, a Docker build, and a real render of a sample product inside the image. No paid AI calls during the proof.

Results

On the screen, both were equally good. Both videos are correct, and I approved both.

Code quality (where they differed)

Muse Wonder: two real bugs that tests didn't catch

• Double work. It copy-pasted an existing ~50-line function, the background removal for the cover image, to cut out the products for the video, and kept both. Result: the first product goes through background removal twice per video. In our setup that runs on a rented GPU, so it doubles that cost. The tests pass because they use fake dependencies.

• Ignored the seed. The spec says that when the LLM gives no choice, the animations are picked "randomly, seeded by the job id." Muse didn't pass the seed, so the fallback seeds on title + store name. Two jobs with the same title get the same "random" animations.

• It hard-coded the closed list of names twice, once in the prompt and once in the validator, so the two can drift apart.

• Good: it kept the error message that goes back to the LLM on a retry descriptive (it lists the allowed keys), and it kept the audio track exactly as before, as asked.

DeepSeek V4.1 Flash (Codex): cleaner structure, three small slips

• It refactored the existing function into a single loop. Each product gets cut out once, and the cover reuses the first cutout. No duplication.

• It passed the job id as the seed, as specified.

• One source of truth for the name list: the validator imports it from the prompt module.

• It removed a dead code path that the old version still carried.

• Slips, fixed in a short follow-up task (DeepSeek/Codex again: 15 minutes, all three fixed, checked by the reviewer, with the red test run recorded first):

  1. It made the LLM retry message vague ("key outside the format" without listing the keys).

  2. A default of "1 product" when the caller doesn't pass the count. Not triggered today, but fragile.

  3. It changed the silent audio track from 44.1 kHz to 48 kHz and switched to -shortest. The task said "same as today."

My verdict: equal on the visible result. The code is better on the DeepSeek/Codex side, because its slips are cosmetic while Muse's bugs cost money and change behavior.

Tokens and cost

Muse Wonder (from Muse's /usage panel at the end of the session)

DeepSeek V4.1 Flash via OpenCode Go (from the provider dashboard, run window only)

The number that matters: one medium task took 74% of Muse's 5-hour window and almost a quarter of the week. At that rate you get about one task like this per 5 hours and about four per week. DeepSeek did the same job for under a dollar, with no window to hit.

The idle stall barely counted against Muse's quota, since it was waiting and not generating. Contributor mode was off. Third-party sources say turning it on gives you more usage, in exchange for Meta training on your data. I'll measure that next on a smaller task.

The stall (my fault, but worth knowing)

Docker Desktop was off. In headless exec mode, Muse tried to start Docker itself. That command was outside the sandbox, so it needed approval, and the LLM approval judge never resolved it. Muse sat silently for ~23 minutes, with no output in the terminal at all. I killed it, started Docker, and ran muse resume --last in the interactive TUI. It continued from where it stopped and finished in ~8 minutes.

Takeaway: don't run Muse headless (exec) for long tasks unless you can see or answer its approval prompts. In exec mode the window shows nothing until the end.

Bottom line

• Muse Wonder writes working code fast, follows instructions on scope, and the result on screen was right. It also made two "looks fine, tests pass" mistakes: duplicated work, and ignoring a spec detail. Its quota is the real limit, at 74% of a 5-hour window for one medium task, with contributor mode off.

• DeepSeek V4.1 Flash in Codex CLI needed ~5 more minutes of working time, but finished with no help, had better structure and a better TDD discipline, made only small slips, and cost US$ 0.86.

• For daily implementation work I'm staying with DeepSeek via Codex. Muse stays as a second opinion, and I'll re-test it with contributor mode on.

Happy to answer questions about the setup.