In my setup, the orchestrator also drives a lot of the design and planning, and the less capable models get inputs from the more capable models by responding back up the chain. The more capable models also review everything that is produced by the cheaper models.

I've also had systems that invert this and allow cheaper models to call out to more capable models when they need to, but in my observation I found them quite bad at knowing even when to call out and I find wrapping the cheap models a bit more reliable in that problems tend to get caught before they bubble up to the user.

  * Orchestrator: Opus 5.5
  * Feature lead: GPT 6.1 Sol
  * Worker: Muse Spark 1.3 Contributor

GPT 6.1 Sol is surprisingly efficient too, I've been impressed with it.

My orchestration skill setup is https://github.com/beefsack/processed-beef/

I feel GTA 6 will be the last mainline GTA that we run on our local systems.

My group don't play competitively, we hop on for a bot bash once a week and the AI is a lot of fun to play against. I'm excited for them to finally release on Steam because that will lower the barrier to entry and increase exposure because the game definitely deserves success.

That doesn't guarantee maanHimself is the original author, but it's looking likely.

This happens to me more commonly in large projects (>100k LOC) and in those projects it seems to happen every few sessions. I feel this specific benchmark would be impacted by this more than the smaller contrived benchmarks.

[1]: https://github.com/openai/codex/issues/37524

  "provider": {
    "alibaba-token-plan": {
      "models": {
        "qwen3.8-max-preview": {
          "limit": {
            "context": 1048576,
            "output": 65536
          },
          "modalities": {
            "input": [
              "text"
            ],
            "output": [
              "text"
            ]
          },
          "name": "Qwen3.8 Max Preview"
        }
      }
    }
  }

Just like with real work, it's valuable to break down big tasks into small tasks that you can knock over in a single session. When a session does start getting too big, you just need to ask the agent to reply with a comprehensive handover report and paste it into a new session.

When leaders are both technical and open about these sorts of things it makes me feel like I can trust that they are invested in supporting and improving their products.

To be honest though, I've gotten to the point where I prefer the OpenCode UI. A big win for OpenAI is you can log in to your subscription in OpenCode, whereas this is not trivially achievable for a Claude subscription.

I was getting some really impressive cost efficiency today in OpenCode with the following:

  * Main session agent: gpt-5.6-sol (high) via OpenAI subscription
  * General purpose subagent: deepseek-v4-pro (high) via OpenCode Go subscription
  * Using `obra/superpowers` for subagent driven workflows
  * The main session only being allowed filesystem read permissions and everything else delegated

GPT 5.6 was picking up on quality and functional issues from DeepSeek and having it resolve them cleanly, and I didn't even get close to my quotas whereas I can usually blast through them. I feel as people get more comfortable with subagents and mixing and matching models in their daily work, Anthropic's walled garden stance will start to hurt them.

You can work around a lot of the memory issues for large and complex tasks just by making the agent keep work logs. Critical context to keep throughout large pieces of work include decisions, conversations, investigations, plans and implementations - a normal developer should be tracking these and it's sensible to have the agent track them too in a way that survives compaction.

I set up my directives to maintain a work log for all work that I do. I instruct Claude Code to maintain a full log of the conversation, all commands executed including results, all failures as well as successes, all learnings and discoveries, as well as a plan/task list including details of what's next. When context is getting full, I do a /clear and start the new session by re-reading the work log and it is able to jump right back into action without confusion.

Work logs are great because the context becomes portable - you can share it between different tools or engineers and can persist the context for reuse later if needed.

There's some jank relating to fractional scaling on Wayland unfortunately, but I keep one monitor without scaling so when I want to play I just launch the puzzles on that.