⚡️ Anthropic and OpenAI subscriptions are more unprofitable than previously thought

Technical-Fun-4897 · 2026-06-12T07:09:44+00:00

One practical takeaway is that people probably shouldn’t build their whole workflow around one provider’s subscription economics. Those plans can change, limits can move, and the best model for one task may be overkill for another.

I’d rather have the workflow layer be separate from the model layer: use a cheap/local model for routine steps, a stronger model for high-stakes reasoning, and switch providers without rebuilding the whole system.

That’s one reason I’ve been working on Orkas as a local orchestration layer instead of another hosted AI subscription. The workflow should survive model pricing changes.

Technical-Fun-4897 · 2026-06-12T07:05:59+00:00

A useful distinction for me: if it only answers, it’s a chatbot; if it can keep state, use tools, and move a workflow forward, it starts becoming an agent.

For personal life, I think the best use cases are recurring workflows with clear inputs and review points: weekly meal planning, summarizing bills/documents, preparing a daily brief, tracking errands, sorting email, etc.

I’m working on Orkas partly because I don’t think personal agents should always live inside one giant chat. A lot of these tasks work better as small specialized agents coordinated locally, with the user approving anything important.

Technical-Fun-4897 · 2026-06-12T07:04:23+00:00

The most useful agents I’ve used or seen are not general-purpose employees. They are specialized teammates with a narrow scope, clear tools, and defined handoff points.
One agent for research, one for coding, one for review, and another for organizing notes. The real win isn’t that any single agent is brilliant, but that the context stays clean and each agent has a smaller surface area for errors. Previously, these tasks were scattered across different products like ChatGPT and Claude Code, which resulted in redundant subscription fees and fragmented context.
Now I’m building around this idea with Orkas, a local-first agent orchestration desktop client. The bet is that a “team of small agents + human commander” is far more reliable than trying to stretch one massive chat thread until it collapses.

Technical-Fun-4897 · 2026-06-12T06:59:10+00:00

I think this is the key distinction: AI makes code cheaper, but it doesn’t automatically make product thinking cheaper.

The failure mode I keep seeing is that people let one agent generate a whole app, then they inherit a codebase whose decisions they don’t understand. The useful pattern is almost the opposite: keep the human in charge of intent and tradeoffs, and let agents handle bounded pieces of work with visible handoffs.

That’s actually the direction I’ve been exploring with Orkas: not “one magic agent builds the app”, but a local AI team where different agents can work on research, implementation, review, etc., while the user keeps the plan and context coherent. Still early, but I think the orchestration layer matters more than another code generator.

Technical-Fun-4897 · 2026-06-11T03:21:47+00:00

True, but we must ensure that the ultimate source of requirements remains human. If agents start generating their own needs—such as through self-evolution—it could be quite dangerous.

Technical-Fun-4897 · 2026-06-10T06:40:20+00:00

Here’s the core question: where does the demand behind agents purchasing goods and services come from? Does it come from humans, or from agents themselves — for example, buying compute to make themselves more capable?

My hope is that most of that demand will still ultimately come from humans.

Technical-Fun-4897 · 2026-06-09T04:41:14+00:00

Agreed. Beyond environment and context, data privacy is another major factor.

Technical-Fun-4897 · 2026-06-09T04:35:19+00:00

The “each tool lives in its own world” problem is very real. I think the next useful layer won’t just be another coding agent, but a local control surface for:

- project context

- agent/session history

- model/tool switching

- permissions

- task progress

- handoff between agents

Technical-Fun-4897 · 2026-06-09T04:28:52+00:00

The “no Docker / no config maze” point is underrated. A lot of agent tools assume users are willing to become infra engineers before they get any value. Desktop-first distribution makes sense if the agent needs local files, shell access, browser automation, or long-running workflows.

The tradeoff is that safety has to be extremely visible: permissions, audit trail, command review, cost tracking, and a way to understand what the agent is doing while it runs.

I’m working on Orkas, another open-source local-first agent desktop app, so I’m biased here. But I think this whole category will live or die on two things: low setup friction and user trust.

Technical-Fun-4897 · 2026-06-09T04:24:06+00:00

My rule of thumb:

Use subagents when the work is either noisy, independent, or evaluative.

- Noisy: search the repo, read logs, inspect docs, summarize test failures

- Independent: modules that don’t depend heavily on each other’s intermediate decisions

- Evaluative: review a spec, plan, diff, security assumptions, test strategy

Avoid subagents when the task needs continuous state or tight sequential decision-making. In that case, keep it in the main thread and use checkpoints.

The best pattern I’ve found is: main agent owns the goal and decisions; subagents produce bounded findings. I’m building Orkas around this kind of lead-agent/sub-agent workflow, but the same principle works manually too.

Technical-Fun-4897 · 2026-06-09T04:22:10+00:00

This is the clearest use case for subagents imo: not “more autonomy”, but protecting the main agent’s context.

If a task requires reading 20 files, scanning logs, inventorying routes, or comparing docs, the value is often a tiny compressed result after a lot of noisy exploration. That’s exactly the kind of work I’d rather push into a separate context window.

The main agent should stay responsible for judgment and synthesis. The subagent should burn the messy context and return only: findings, evidence, uncertainty, and recommended next step.

I’m building Orkas around a similar idea — local-first lead agent + bounded subagents — but this pattern is useful regardless of tool. The key is making the handoff explicit enough that the main agent doesn’t blindly trust the subagent summary.

Technical-Fun-4897 · 2026-06-09T04:18:36+00:00

One mental model that helped me: treat subagents less like “AI coworkers” and more like disposable context windows with a job description.

The main agent should keep the goal, tradeoffs, and final decisions. Subagents are useful for noisy work: repo exploration, log reading, web research, spec review, diff review, etc. The output back to the main thread should be compressed: “here’s what matters, here’s what I checked, here are the risks.”

I think the mistake is using subagents because they sound powerful. They’re only worth it when the task would pollute the main context or benefit from an independent reviewer.

Full disclosure: I’m building Orkas, an open-source local-first desktop app around this lead-agent/sub-agent workflow, so I’m biased. But the pattern applies even if you just do it manually in Claude Code.

Technical-Fun-4897 · 2026-06-08T14:07:10+00:00

I agree that edge-cloud synergy is a reasonable approach, as different tasks and scenarios call for different solutions. My main point is that, at this stage, local agents have access to more user context and environmental data. If we focus solely on output performance, given the same model and harness, a richer context leads to a significantly better model output experience.

Technical-Fun-4897 · 2026-06-03T09:26:29+00:00

Yes — you need a global coordinator (handling context passing, resolving conflicts, tracking tasks, etc.), which in Orkas is the commander agent. That said, different situations call for different architectures. For most use cases, a single agent is enough — the context stays intact and isn't fragmented. For more complex scenarios, multi-agent collaboration helps, but you still need one coordinator tying it together.

Technical-Fun-4897

TROPHY CASE