I've been using Claude Code as my primary agent orchestration tool for a few weeks now. Running cron-style loops for browser automation through a remote Playwright instance. Haven't tried Codex at this depth yet, but from what I've seen it's more focused on code generation while Claude Code is more of a general-purpose agent runtime. The things that make Claude Code powerful for me are the persistent session with tool access, the ability to run background tasks on schedules, and the hook/skill system for customization. If Codex matches that plus adds better async execution (Claude Code's scheduled tasks die when the session ends), it could be compelling. But for now Claude Code handles my use case better than anything else I've tried.
I mostly use claude code for coding purposes. According to my experience, claude code is unbeatable in terms of coding and UI. But I feel like chat gpt is better for architectural decisions. But I haven't tried codex, BUT I am listening a lot now that its limits are far better than claude code and that it is good in terms of value for money.
Interesting approach. I've been running a similar setup using Slack as the control plane for browser automation agents. The main challenge with messaging apps as control planes is handling long-running tasks and state management. Telegram's bot API is actually nicer than Slack's for this since you get more granular message editing.
agreed. the long-running tasks i handle with immediate-background and continually edit message with updates, along with fork-and-reconcile semantics so you don't have to queue messages. also having a supergroup with separate topics for different sessions works really well.
the separate topics approach along with allowing other processes to enqueue messages into the session stream solves state pretty tidily, see "the session as decision-maker" in the linked report
Backend Engineer at British Council, architecting Agentic AI systems for one of the world's largest cultural organizations. Building AI agent orchestration layers and LLM-powered backend services that automate complex examination workflows across 100+ countries. Previously built a FinTech SaaS from zero at Marquee Equity and solo-shipped an AI-powered interview prep platform (ProTechStack.com)
I’ve always felt they weren’t really worth it for performance per dollar spent. For C++ work I just use a non-Mac workstation. For lighter workloads the Mac Mini is very capable already.
The Studio (Stud IO™) is the new Mac Pro - it's not "worth it" unless you need the most performance period - or you have money to spare.
Or you really, really need to drive eight displays from a single machine.
For "home user" stuff a Mac mini or MacBook is going to do everything you ever need (in fact, they have the problem where the M1 systems are still perfectly capable, six years later).
You think they will skip M4 ultra? May be they slowly plan to launch ultra chips alternate years since the development costs are high and demand is niche.
If they do a 1TB m5 ultra, I too would be configuring one for sure.
I hope so! I already have the M4 mini pro - would like to bump up the prompt processing time and the memory bandwidth at the same time with the new M5 matmul changes.
Senior Backend Engineer with 5+ years building scalable systems across FinTech, EdTech, and AI. Currently at British Council architecting exam platforms for millions of concurrent users. Solo-built a Go-based scraping engine that extracts structured data from 200M+ company records, and an AI interview prep platform with 100K+ users (ProTechStack.com). No over-engineered stacks — Go, PostgreSQL, Playwright, and headless Chrome. Looking for early-stage roles.
I agree that reading every dependency isn’t realistic. But “not reading the code” as a principle feels risky.
In my experience, abstractions hold until they don’t. The first time you hit a production incident and the docs stop helping, reading the source stops being academic and starts being survival.
We once had a performance issue caused by a library making assumptions about concurrency that weren’t obvious from the API. The fix only became clear after stepping through the source.
I think the real skill isn’t avoiding reading code, it’s knowing when to escalate from trust to understanding.
For glue code or low stakes utilities, sure. For auth, billing, or core infra, I’d argue reading at least the critical paths pays dividends.
So last week I tried Gemini pro 3, Opus 4.6, GLM 5, Kimi2.5 so far using Kimi2.5 yeilded the best results (in terms of cost/performance) for me in a mid size Go project. Curious to know what others think ?
I predict Gemini Flash will dominate when you try it.
If you're going for cost performance balance choosing Gemini Pro is bewildering. Gemini Flash _outperforms_ Pro in some coding benchmarks and is the clear parento frontier leader for intelligence/cost. It's even cheaper than Kimi 2.5.
