Portal by Spotify cut my Claude Code token usage by 90%

- listing modes - this gate, other gate - canonical stuff etc.

would've been nice if Claude produces such output now and then. with 4 agents doing my stuff on a daily basis, I feel like vomiting at some point, not mere nausea, but disgust. damn Codex seems to fare better at this imho.

curiously I've tried many times to instruct it to not produce this nonsense, but _deus ex machina_ always finds a way around it. wonder if these "instructions" are actually treated as restrictions, rather than... mere obstacles. like - you can try to plumb a river, it always finds its way around plumbing.

This is a Claudism, right? I feel like I never saw "gated" used this way before it.

That property would be very useful here, but I don't see how it would be achievable using LLMs.

So fable and opus use opus to explore. Sonnet uses sonnet.

I replaced my built in explore agent with one hardcoded to sonnet low effort.

https://github.com/anthropics/claude-code/issues/72940

You kids don't get it, it's not about the tokens, it's about the principle of the thing. No self-respecting real programmer would accept the loss of even a few tokens over programmatic efficiency and cleverness.

The app was done in 2011. They could make a massive improvement across the board with a single git reset --hard command.

And no, the problems you described are not there.

On my Windows 11 laptop it takes about 2sec to start and basically any song starts in less than a second.

Maybe it's Apple making Spotify crappy on Mac to promote iTunes?

I wonder if the macOS build has a bunch of static libraries it has to load first.

Related: https://bedrocknews.com/article/technology/2026/apr/11/ai-im... and https://www.headphonesty.com/2025/01/spotify-ghost-artists-c...

Just skip Spotify at all.

More specifically, I'm talking about tapping the '...' on a track for the options menu. That should be latency-free, and used to be.

as someone on the internet once said, it's good that no-one at Spotify realised that people would buy the subscription much faster if it was a crying baby soundbite playing every time instead of an advertisement

The comment above shows this type of people don't understand it. Yet they are the ones getting hired due to formal qualification. Those who do are at the intersection of design, engineering and computer science. The latter give you enough experience to understand the culture to recreate familiar _look and feel_.

  - Write ~1 paragraph of developer instructions (AGENTS.md): Use subagents for tasks that can be decomposed, worked on in parallel, or delegated. Describe common examples. I put a reference to a "how to use subagents" skill for more details. The "skill" isnt' always read (as subagents arent always useful) which saves some tokens. But you pay the once-per-session read-skill cost when its relevant.
  - Describe how to use subagents in ~1 page or less (SKILLS.md): use them for sub tasks. select model size/quality based on task ambiguity, scope, unbounded work, or conflicting requirements. Use reasoning effort for complexity, interdependence, or ambiguous success criteria. How to evaluate complexity & common subtask examples across the spectrum. give tasks a relevant name like "model-family_version_reasoning-effort_task-description" so you can actually understand what theyre doing by name.
  - in dev instructions (SKILLS.md) provide a table of agent names (low complexity summarizer, bounded implementation, complex implementation), model+effort (gpt-5.6-luna medium, gpt-5.6-luna high, gpt-5.6-sol medium), and short description of 2-3 task "types" for each.
  - Explain they can use "default" or specify their own custom model settings if needed.
  - Define your list of subagent profiles in ~/.codex/agents/ which matches names (low_complexity_summarizer.toml) from previous. In each you'll need to set model, reasoning, and `developer_instructions` that describe *how* to do a task, *not what* to do.

  - IMO subgent profiles are "task centric" because `developer_instructions` are required. You can't just specify model & reasoning, you also have to give valid developer_instructions that will be merged in to every session/prompt. I address this by defining a few different agents for tasks that are commonly encounted like summarization, synthesis, planning, implementation, etc. The different agent profiles (~2-5 per category) will "scale" the model + reasoning based on the complexity and ambiguity. This work pretty well in practice. And you don't need to over due it, the harness/agent can still launch a "custom" profile that uses the parent sessions developer instructions.
  - You need to use agent profiles with codex because "v2" models (terra & sol) can't launch "v1" models (luna). There are a couple of code paths to avoid this, the agent profile is the simplest. 

This should have been the entirety of TFA.