I had my multi-agent cost strategy backwards. The orchestrator is your heaviest token consumer, so it should be the cheapest model — not the smartest one.

The problem with the obvious approach

When I first started using orchestration plugins in OpenCode, my instinct was straightforward: use expensive, capable models for the main agents and reserve my local model for simple tasks like search or quick edits.

It makes sense on paper. The orchestrator coordinates everything, so it should be the best model, right?

Wrong. The orchestrator is the model that sees the most tokens. Every subagent response, every file read, every intermediate result passes through it. It consumes orders of magnitude more tokens than any specialist agent because it is always in the loop.

The inverted cost model

The insight is simple: run your heaviest token consumer locally, and use paid models only where they earn it.

The orchestrator does not need deep reasoning. It needs to plan, delegate, track progress, and reconcile results. A 27B local model handles that surprisingly well. The agents that actually need capability — the ones doing deep analysis, architecture review, or documentation research — consume far fewer tokens because they are called selectively for specific tasks.

Real numbers from a real session

I resolved a complex issue recently. Here are the actual metrics:

• 342 API calls
• 36.7M tokens processed
• Total cost: $0.31

The setup: OpenCode with Oh-My-Opencode-slim, running Qwen3.6-27B locally as the orchestrator and fixer. The specialist agents used GLM-5.2 (Oracle), DeepSeek-V4-Flash (Librarian, Explorer), and Kimi K2.7-Code (Designer) through OpenCode Go.

The same session with GLM-5.2 as the orchestrator would have cost $16.56.

That is a 53x cost reduction for the same result. 95% of all tokens were processed locally at zero cost.

How Oh-My-Opencode-slim makes this work

Oh-My-Opencode-slim is an agent orchestration plugin for OpenCode by Boring Dystopia Development. It defines six specialized agents, each with its own model assignment:

The Orchestrator stays in the main session loop, coordinating work and delegating to specialists. The specialists run as background agents — they get their specific context, do the work, and return results. The Orchestrator never sees the full token payload of each specialist’s work; it only sees the summary.

This is the key mechanism that makes the inverted model work: the orchestrator sees everything, but the specialists see only what they need.

Why a local 27B model works as orchestrator

Qwen3.6-27B running on my RTX PRO 6000 (96 GB VRAM) via vLLM handles the orchestration role well for three reasons:

1. Planning is not the same as reasoning. The orchestrator’s job is to decompose tasks, track state, and route work. It does not need to solve hard problems — it needs to coordinate people who do.

2. Latency matters. The orchestrator is called on every turn. A local model responds in milliseconds. A remote API call adds seconds of round-trip time, and that compounds across hundreds of calls in a session.

3. Context window is sufficient. The orchestrator needs to maintain session state, not reason about a full codebase. 262K context (reduced from 1M for stability) is more than enough.

Adapting the opencode-go preset

Oh-My-Opencode-slim ships with an opencode-go preset designed for cost-efficient setups using OpenCode Go’s low-cost models. The default configuration uses GLM-5.2 for the orchestrator, Qwen3.7-Max for Oracle, DeepSeek-V4-Flash for Librarian/Explorer/Fixer, and Kimi K2.7-Code for Designer.

My configuration adapts it by routing the orchestrator and fixer to my local model — the two biggest token consumers:

{
  "opencode-go": {
    "orchestrator": { "model": "vllm-pro6000/Qwen3.6-27B", "skills": ["*"], "mcps": ["*", "!context7"] },
    "oracle": { "model": "opencode-go/glm-5.2", "skills": ["simplify"], "mcps": [] },
    "librarian": { "model": "opencode-go/deepseek-v4-flash", "mcps": ["websearch", "context7", "gh_grep"] },
    "explorer": { "model": "opencode-go/deepseek-v4-flash", "mcps": [] },
    "designer": { "model": "opencode-go/kimi-k2.7-code", "mcps": [] },
    "fixer": { "model": "vllm-pro6000/Qwen3.6-27B", "mcps": [] }
  }
}

The change is minimal — two model assignments swapped from remote to local. The effect is dramatic: the orchestrator alone accounts for the majority of token consumption in a session, so making it local eliminates the bulk of the cost.

If you do not have a local GPU, the same principle applies: use the cheapest capable model for the orchestrator. DeepSeek-V4-Flash through OpenCode Go is an excellent option — fast, cheap, and surprisingly competent at planning.

The rule

The orchestrator should be your cheapest, fastest model. The specialists should be your most capable ones.

The orchestrator is a project manager, not an engineer. It delegates, tracks, and reconciles. The Oracle, Librarian, and Designer are the engineers who do the actual work. Give them the best tools. Give the project manager the cheapest desk.

What I got wrong initially

My first setup used GLM-5.2 and DeepSeek-V4-Pro as the orchestrator with local models for simple tasks. It worked well but cost $0.71 per session. Flipping the model assignments — local orchestrator, paid specialists — brought it down to $0.31 while actually improving the workflow.

The orchestrator was the bottleneck all along. Not in capability, but in token volume. Every tool call, every file read, every agent response went through it. Making it local eliminated the cost entirely.

Setup requirements

This approach needs:

• A GPU that can run a 27B model. My RTX PRO 6000 has 96 GB VRAM, but even a consumer GPU with 24 GB (like the 7900 XTX) can run a 27B model in Q4 quantization.
• vLLM serving the model locally. I run it via Docker with gpu-memory-utilization tuned to leave room for KV cache.
• OpenCode with Oh-My-Opencode-slim installed. The plugin handles all the orchestration logic — you just configure which model goes where.
• OpenCode Go account for the specialist models (pay-as-you-go, low-cost models).

Links

• OpenCode — The terminal-based coding agent
• Oh-My-Opencode-slim — Multi-agent orchestration plugin (6.7k stars)
• My previous OpenCode setup post — Full configuration walkthrough
• RTX PRO 6000 Blackwell setup — Hardware and vLLM configuration

I replaced my local model in OpenCode from Qwen3.6-27B to Qwen3.6-35B-A3B in FP8. Here is why, and why the other two options — the smaller 27B and the NVIDIA NVFP4 variant — lost.

Benchmark Setup

Measured with llm-race using the multi-agent parallel workflow:

Multiple independent agents running in parallel — 4 agents, 12 queries, 256 prefill tokens, 4096 output tokens. Independent parallel agents with user queries and tool context.

My homelab workstation (“Tesla”) runs vLLM on a single NVIDIA RTX PRO 6000 Blackwell with 96 GB of VRAM, dedicated to me. I use OpenCode with the Oh-My-OpenAgent plugin for agentic coding — multi-step, autonomous, terminal-driven development.

The question was: which Qwen3.6 quant to run locally?

Option 1: Qwen3.6-27B-FP8

The smaller model. Closer to what I already had.

Quality: marginally lower than 35B on coding benchmarks. Not a dramatic difference, but measurable.

Speed: roughly one fifth the throughput of the 35B. On agentic workflows where the model generates 1000+ token responses, this means waiting three times longer for each turn. In interactive coding, that adds up fast.

Verdict: slower and not much different in quality. The 35B is worth the extra VRAM.

Option 2: NVIDIA’s NVFP4 Variant

Theoretically, NVFP4 offers ~2x bandwidth efficiency over FP8. Weights are smaller, transfer is faster. On paper it makes perfect sense.

In practice on Blackwell with vLLM:

• The marlin dequantization kernel consumes exactly what the smaller weights save in transfer. The theoretical bandwidth advantage evaporates at the dequant step.
• The resulting TPS difference is ~6% — roughly 1.26s vs 1.19s for a 1000-token turn. That is invisible in interactive use.
• There is a measurable quality loss in coding benchmarks compared to FP8. NVFP4 is a real quant, and even a good one, it still quantizes.
• The 17 GB of VRAM savings are irrelevant with 96 GB dedicated to a single user. You are not squeezing models onto a shared H100 server — you have the room.
• The NVIDIA kernels for sm_120 (Blackwell) are not yet mature. The NVFP4 kernels in vLLM nightly still require dequantization workarounds. The FP8 backend, by contrast, uses native Triton with real hardware FP8 support on Blackwell. Simpler, more mature, fewer edge cases.

Verdict: the 2x bandwidth advantage is theoretical. It does not materialize on Blackwell today, it costs quality, and the kernels are not ready.

Option 3: Qwen3.6-35B-A3B in FP8

Quality: highest of the three. The 35B A3B (active 3B sparse) gives the best coding performance in the family.

Speed: good. On my hardware it generates tokens at a pace that feels instantaneous during agentic workflows. The ~6% TPS advantage NVFP4 theoretically has over FP8 is not perceptible in practice.

Backend maturity: FP8 on Blackwell uses Triton natively with real hardware FP8 support. No dequantization workarounds. No nightly kernel hacks. It just works.

VRAM: 96 GB is plenty for a 35B A3B in FP8. No squeezing, no swapping, no patience-testing context limits.

The Conclusion

For this specific setup — RTX PRO 6000 Blackwell, single-user, agentic coding workflow — FP8 is the correct choice.

NVFP4 makes sense on HBM-equipped hardware (H100/H200) where the bandwidth equation is genuinely different, or when you have native NVFP4 kernels without dequantization in vLLM. Neither condition applies here.

The 27B is slower. The NVFP4 has no real speed advantage and loses quality. The 35B FP8 is the sweet spot — best quality, good speed, mature backend, and VRAM to spare.

I went back to the FP8 recipe I started with. Sometimes the simple answer is the right one.

See also: Qwen3.6 Benchmarks & vLLM Recipe — the full benchmark suite and Docker setup behind these numbers.

In the rapidly evolving landscape of Speech-to-Speech (S2S) models, the temptation to move toward “native” multimodal models is strong. However, for building robust, production-ready systems, the Modular Pipeline (STT -> LLM -> TTS) remains an engineering powerhouse.

While S2S offers a glimpse into the future of natural interaction, the Modular Pipeline provides the control, flexibility, and hardware-agnosticism required to build professional software.

The Power of Modular Flexibility

The primary reason for choosing a Pipeline architecture is the ability to decouple components. In AI, the “state-of-the-art” changes every week. A modular approach allows for:

• Hot-swappable Models: Need a faster STT for a specific region? Swap it. Want to use a smaller, local MoE model for low-latency reasoning? Swap the LLM.
• Hardware Heterogeneity: AI is not a monolith. A production environment might span from Mac Minis (optimized for different architectures) to DGX clusters with high-end CUDA support. A pipeline allows you to optimize each step for the specific hardware it runs on.

Resource Efficiency: The Key to Local Deployment

One of the most critical advantages of the Pipeline is its footprint. A native S2S model must handle voice decoding, LLM reasoning, and audio synthesis simultaneously, often resulting in a model size and compute requirement nearly equal to the sum of all three components.

In a Pipeline, tasks are decoupled. The STT can run independently while the LLM and TTS are idle, significantly lowering the hardware overhead for that specific task. While the LLM and TTS may overlap during generation, this can be minimized by using short-response prompts.

This surgical separation of concerns is what makes running a high-quality Voicebot on your own hardware—privately and locally—feasible. It allows for a level of optimization that monolithic models simply cannot match.

The “Intermediate Space”: The Hidden Superpower

One of the most overlooked advantages of the Pipeline is the “space” between the STT and the LLM. This isn’t just a latency cost; it’s a processing opportunity. By intercepting the text stream, we can perform:

1. Speaker Identification: Knowing who is talking before the LLM even sees the prompt.
2. Keyword Forcing: Identifying specific triggers (like “search” or “investigate”) to force specific tool calls or logic paths.
3. Wakeword Management: Implementing robust wake-up logic that is nearly impossible to handle reliably in a continuous S2S stream.

Engineering for Immediacy: Beating the Latency Gap

To compete with native S2S latency, we employ three specific engineering tactics that maximize the efficiency of the Pipeline:

1. Concurrent Transcription

For the STT to be truly efficient, transcription must occur while the user is speaking. The objective is to have the text ready by the moment the Voice Activity Detection (VAD) identifies the end of speech. This requires an STT model capable of keeping pace with human speech in real-time, ensuring the system doesn’t feel like it’s “waiting” for the user to finish.

2. Prioritizing Time to First Token (TFTT)

In our architecture, the paramount metric for the LLM is TFTT. Because user prompts are typically concise, high throughput (Tokens Per Second) is less critical than starting the response immediately. A steady 50 tokens/s is more than sufficient because we don’t need to generate massive paragraphs instantly; we just need to start the “flow” of conversation as quickly as possible.

3. The Immediacy Tricks

We use two clever tricks to create a sense of instantaneity:

• Prompt Engineering: We instruct the LLM to begin its responses with short, affirmative anchors like “Yes,” “Agreed,” or “Let’s go.” This provides an immediate conversational hook.
• Sentence Parsing: We implement a parser that splits the LLM’s text stream by punctuation (commas and periods). As soon as the parser detects a complete phrase, it fires the TTS engine. This allows the system to start speaking the first part of the answer while the LLM is still generating the remainder of the message.

Handling the “Human” Side: Barge-in and Emotion

A common critique of the Pipeline is the loss of emotional prosody and the latency of sequential steps. However, these are solvable engineering problems:

• Barge-in: Because we manage the threads, we can instantly kill a TTS playback or an LLM generation the moment the STT detects the user has started speaking again. This is crucial for natural flow.
• Emotion Tagging: We don’t need a native S2S model to “feel” emotion. By using an STT that detects sentiment and passing that as a metadata tag (e.g., [User](sad) I don't know what to do today), the LLM can still generate a contextually aware, empathetic response.

Conclusion

S2S is a marvel of research, but the Pipeline is a masterclass in engineering. It trades a small amount of native latency for a massive amount of control, debuggability, and production reliability. For anyone building a Voicebot that needs to do more than just “chat”—that needs to act—the Pipeline is the way to go.

Follow the project on Twitter: Voicebot updates

Running powerful AI models locally requires a careful balance of VRAM management, quantization techniques, and inference engine optimization. With my NVIDIA PRO 6000 Blackwell AI Workstation Max-Q (96GB), I’ve managed to find a “sweet spot” configuration that allows me to run two of my favorite high-performance models simultaneously for different purposes.

The Setup

I currently run two distinct vLLM instances to power my primary AI workflows:

1. For OpenCode (Programming): I use Qwen3.6-27B-FP8. This model is exceptional for coding tasks, and the FP8 quantization allows it to run efficiently while maintaining high precision for complex logic.
2. For Hermes Agent (General & Reasoning): I use gemma-4-12B-it-qat-int4. This model is incredibly nimble and offers great reasoning capabilities for my agentic workflows.

By balancing the gpu-memory-utilization between these two services, I can keep both models active and responsive in the same environment without OOM (Out of Memory) errors.

How I Launch the Services

I manage these deployments using Docker Compose. The core of the setup involves two separate vLLM containers with specific configurations tailored for each model’s requirements (such as specific KV-cache types and max sequence lengths).

You can find the full configuration in my docker-compose.yml file:

# vLLM for Qwen3.6-27B-FP8
  vllm-qwen:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    restart: unless-stopped
    shm_size: "32G"
    privileged: true
    environment:
      - VLLM_LOGGING_LEVEL=info
      - VLLM_HOST_IP=0.0.0.0
      - HF_HOME=/root/.cache/huggingface
      - HF_TOKEN=hf_....baA
      - FLASHINFER_DISABLE_VERSION_CHECK=1
      - FLASHINFER_CUDA_ARCH_LIST=12.0f
      - VLLM_MOE_FORCE_MARLIN=1
      - CUTE_DSL_ARCH=sm_120a
      - PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
      - VLLM_ALLOW_LONG_MAX_MODEL_LEN=1
      - TRANSFORMERS_VERBOSITY=warning
    volumes:
      - ./huggingface:/root/.cache/huggingface
      - ./vllm_cache:/root/.cache/vllm
    ports:
      - "8005:8000"
    command: >
      Qwen/Qwen3.6-27B-FP8
      --served-model-name Qwen3.6-27B-FP8
      --trust-remote-code
      --host 0.0.0.0
      --port 8000
      --tensor-parallel-size 1
      --kv-cache-dtype fp8_e4m3
      --gpu-memory-utilization 0.70
      --max-model-len 262144
      --max-num-seqs 16
      --max-num-batched-tokens 32768
      --enable-chunked-prefill
      --async-scheduling
      --reasoning-parser qwen3
      --enable-auto-tool-choice
      --tool-call-parser qwen3_coder
      --mm-encoder-tp-mode data
      --default-chat-template-kwargs '{"enable_thinking": true, "preserve_thinking": true}'
      --speculative-config '{"method":"mtp","num_speculative_tokens":1}'
      --override-generation-config '{"temperature":0.6,"top_p":0.95,"presence_penalty":0.05,"repetition_penalty":1.05}'
      --language-model-only
      -O3
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 120s
    logging:
      driver: "json-file"
      options:
        max-size: "20m"
        max-file: "5"

# vLLM for gemma-4-12B-it-qat-int4
  vllm-gemma:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    restart: unless-stopped
    shm_size: 16g
    privileged: true
    environment:
      - VLLM_LOGGING_LEVEL=info
      - VLLM_HOST_IP=0.0.0.0
      - HF_HOME=/root/.cache/huggingface
      - PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
      - HF_TOKEN=hf_....baA
    volumes:
      - ./huggingface:/root/.cache/huggingface
      - ./vllm_cache:/root/.cache/vllm
    ports:
      - "8006:8000"
    command: >
      google/gemma-4-12B-it-qat-w4a16-ct
      --served-model-name gemma-4-12B-it-qat-int4
      --tensor-parallel-size 1
      --max-num-batched-tokens 8192
      --gpu-memory-utilization 0.25
      --kv-cache-dtype fp8
      --max-num-seqs 1
      --max-model-len 131072
      --enable-auto-tool-choice
      --tool-call-parser gemma4
      --chat-template examples/tool_chat_template_gemma4.jinja
      --reasoning-parser gemma4
      --async-scheduling
      --language-model-only
      --speculative-config '{"model":"google/gemma-4-12B-it-assistant","num_speculative_tokens":4}'
      -O3
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 120s
    logging:
      driver: "json-file"
      options:
        max-size: "20m"
        max-file: "5"

This configuration represents the best way I’ve found so far to maximize the potential of my Blackwell hardware, providing a robust backend for both coding-heavy automation and general-purpose AI agency.

The tests were performed on an NVIDIA RTX PRO 6000 Blackwell Max-Q GPU. Below are the results for the four models evaluated.

Benchmark Results

1. Qwen/Qwen3.6-35B-A3B-FP8

2. nvidia/Qwen3.6-35B-A3B-NVFP4

3. Qwen/Qwen3.6-27B-FP8

4. sakamakismile/Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP

vLLM Deployment Recipe

To launch the Qwen/Qwen3.6-35B-A3B-FP8 variant on Blackwell hardware, use the following Docker Compose configuration. Note the flashinfer attention backend required for FP8 KV cache support.

Other models require different recipies.

services:
  vllm:
    image: "vllm/vllm-openai:nightly"
    runtime: nvidia
    restart: unless-stopped
    ipc: host
    shm_size: "32G"
    environment:
      - VLLM_LOGGING_LEVEL=info
      - VLLM_HOST_IP=0.0.0.0
      - HF_HOME=/root/.cache/huggingface
      - HF_TOKEN=hf_Il....KbaA
      - FLASHINFER_DISABLE_VERSION_CHECK=1
      - FLASHINFER_CUDA_ARCH_LIST=12.0f
      - VLLM_MOE_FORCE_MARLIN=1
      - CUTE_DSL_ARCH=sm_120a
      - PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
      - VLLM_ALLOW_LONG_MAX_MODEL_LEN=1
      - TRANSFORMERS_VERBOSITY=warning
    volumes:
      - ./llama-server/huggingface:/root/.cache/huggingface
      - ./llama-server/vllm_cache:/root/.cache/vllm
    ports:
      - "8000:8000"
    command: >
      Qwen/Qwen3.6-35B-A3B-FP8
      --served-model-name Qwen3.6-35B-A3B-FP8
      --trust-remote-code
      --host 0.0.0.0
      --port 8000
      --tensor-parallel-size 1
      --dtype auto
      --kv-cache-dtype fp8_e4m3
      --attention-backend flashinfer
      --moe-backend marlin
      --gpu-memory-utilization 0.96
      --max-model-len 262144
      --max-num-seqs 32
      --max-num-batched-tokens 65536
      --enable-chunked-prefill
      --enable-prefix-caching
      --async-scheduling
      --reasoning-parser qwen3
      --enable-auto-tool-choice
      --tool-call-parser qwen3_coder
      --structured-outputs-config.backend xgrammar
      --default-chat-template-kwargs '{"enable_thinking": true, "preserve_thinking": true}'
      --speculative-config '{"method":"mtp","num_speculative_tokens":2,"moe_backend":"triton"}'
      --override-generation-config '{"temperature":0.6,"top_p":0.95,"presence_penalty":0.05,"repetition_penalty":1.05}'
      --language-model-only
      -O3
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 120s
    logging:
      driver: "json-file"
      options:
        max-size: "20m"
        max-file: "5"

Phase 1: Curiosity and Manual Copy-Pasting

It all starts with curiosity. You download a local LLM, open a chat, and start asking it things. You copy answers by hand. Sometimes they work, sometimes they don’t. But curiosity is enough to keep you interested.

The flow is simple: you think, the model responds, you copy. There’s no automation, no integration. It’s like having a pair programming partner who talks slowly and hallucinates sometimes. But it’s enough to experiment.

Phase 2: Frustration

Then comes the reality check. Small local models promise a lot but deliver very little. They generate code that looks fine but has subtle bugs. They break imports. They forget contexts. Productivity drops below what you’d have without AI.

This is the “AI slop” phase: generated code nobody understands, nobody trusts, and nobody wants to maintain. You start doubting. Is this worth it? Or are we just playing with expensive toys?

Phase 3: The Qualitative Leap

Then comes the moment when something changes. A new model, a leap in reasoning quality, and suddenly things start working. Not everything, but enough for the friction to disappear.

It’s like when you went from writing code by memorizing syntax to understanding what you wanted to express. The tool disappears and what remains is the work.

Phase 4: The Virtual Team Illusion

Once you trust agents, the natural instinct is to replicate what you already know: teams with roles. You create a “PM” agent that plans, a “dev” agent that codes, a “QA” agent that tests. It seems natural. It makes sense.

But soon you discover it doesn’t work. Agents aren’t people. They don’t need functional role divisions — they need cognitive depth divisions. It’s not that one “plans” and another “codes”. It’s that some tasks require deep reasoning while others require mechanical execution.

The most common mistake is treating agents as mini-people. They aren’t. They’re tools with different levels of power. And mixing them for organizational convenience rather than cognitive necessity is the perfect recipe for chaos.

Phase 5: The “Man-in-the-Middle” Trap

When the virtual team illusion collapses, many programmers fall into the opposite trap: reviewing everything. Every diff, every line, every decision. At first it seems responsible. You’re being careful.

But soon you discover the paradox: while the agent works, you do nothing. When you work (reviewing), the agent is idle. You’re creating a human bottleneck where there shouldn’t be one.

Productivity doesn’t scale because the human becomes the limiting factor of the system. And the more you trust the agent, the more frustrating it becomes to have to review its work. It’s like having a Ferrari and driving at 30 km/h.

Phase 6: Automated Validation, Strategic Oversight

The final phase (for now) arrives when you understand that trust isn’t built by reviewing the agent’s work, but by building systems that validate the work automatically.

For code: tests that are generated and executed with every change. No passing tests, no integration. Validation is binary and automatic.

For thinking: reviewer agents. For research and planning, there are no tests to pass, but you can use a second agent with a critic role to review the first one’s work. It’s like automated code review applied to documents, plans, and architectural decisions.

You’re no longer the filter. You’re the architect of the validation system.

And Phase 7…

I don’t know that one yet. You’ll probably discover it when you stop looking for it.

What I do know is that evolution isn’t linear. You’ll return to earlier phases with new perspective. Phase 6 isn’t a destination, it’s a starting point. And every qualitative leap in models will redefine what you thought you knew about programming with AI.

If you’re in Phase 5, don’t worry. Phase 6 exists. And Phase 7… that’s built along the way.

I replaced my AI coding workflow with OpenCode running a 10-agent orchestration system, backed by a mix of free-tier models and a local 27B model on my homelab workstation. Total monthly cost: cheap.

Why OpenCode?

I have been thinking about local AI coding agents for a while. The constraints were clear: no Anthropic, no OpenAI, and definitely no Chinese providers for personal work. I want full control, reasonable cost, and the ability to iterate without hitting API rate limits or watching token bills spiral.

OpenCode is a provider-agnostic, open-source coding agent that runs entirely in the terminal. It has a TUI for interactive sessions and a CLI for one-shot tasks. Critically, it supports arbitrary model providers through its plugin system, which means I can route different tasks to different models — free tier for quick queries, a local 27B model for medium work, and reserve paid models only where they earn it.

Installing OpenCode

OpenCode has three installation methods. The install script is the simplest:

curl -fsSL https://opencode.ai/install | bash

After installation, authenticate your model providers. OpenCode has a free tier called OpenCode Zen that gives you access to several models at no cost:

opencode auth login

Check your configured providers with:

opencode auth list

I use both OpenCode Zen (free tier) and a local vLLM provider running on my homelab.

Updating OpenCode

To update it, just execute command upgrade:

opencode upgrade

Oh-My-OpenAgent: The Multi-Agent Harness

This is where OpenCode gets interesting. Oh-My-OpenAgent is a plugin that transforms OpenCode from a single-model agent into a multi-agent orchestration system. It defines 10 specialized agents, each responsible for a different role in the coding workflow:

Installing Oh-My-OpenAgent

The plugin installs through npm or bun. But don’t do that: just follow the instructions in their Github

Paste this prompt into Claude Code, AmpCode, Cursor, or any agent:

Install and configure oh-my-openagent by following the instructions here:
https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/refs/heads/dev/docs/guide/installation.md

Epic!

The plugin generates a configuration file at ~/.config/opencode/oh-my-openagent.json. This is where the magic happens — you assign models to agents and categories.

Running Oh-My-OpenAgent

Once installed and configured, Oh-My-OpenAgent activates automatically when you run OpenCode. The plugin intercepts tasks and routes them to the appropriate agent based on the task category.

You can validate the installation with:

npx oh-my-openagent doctor
# or
bunx oh-my-openagent doctor

Model Selection Strategy

This is the most important configuration decision. Oh-My-OpenAgent lets you assign different models to different agents and task categories. My strategy is 100% free and local — no paid API calls.

Free Models from OpenCode Zen

OpenCode Zen offers several models free of charge. The current lineup (as first of June 2026) includes:

Check the current list at any time with:

curl -s https://opencode.ai/zen/v1/models | python3 -m json.tool

Models with -free in their ID are the free tier offerings. This list changes frequently, so always verify.

Local Model

My homelab workstation (which I call Tesla) runs a local model via vLLM. This is my anchor for tasks that need to be fast and private:

{
  "provider": {
    "vllm-pro6000": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Tesla VLLM",
      "options": {
        "baseURL": "http://192.168.1.47:8005/v1"
      },
      "models": {
        "Qwen3.6-27B": {
          "name": "Qwen3.6-27B",
          "limit": {
            "context": 262144,
            "output": 65536
          }
        }
      }
    }
  }
}

This gives me a Qwen3.6-27B model running on an RTX PRO 6000 (96 GB VRAM). It is my fallback for every agent — fast, private, and free.

Agent Model Assignments

Here is my free-tier strategy, mapping models to agents:

The key insight: heavy agents get free frontier models, lightweight agents use the local model. MiniMax M3 is the workhorse — it is a genuine frontier model with 1M context window, multimodal support, and sparse attention that competes with paid options on coding benchmarks.

The local model anchors Explore and Atlas because those are fast, low-complexity tasks. Sending a grep query to a remote API wastes time and tokens. A 27B local model handles search and general support in milliseconds.

Category Model Assignments

Oh-My-OpenAgent also supports task categories — different model assignments based on what type of work is being done:

The golden rule: always include the local model as either primary or final fallback. This ensures the system never dead-ends.

Picking the Right Models

When selecting models for Oh-My-OpenAgent, I follow these principles:

1. Check OpenCode Zen first — the free model lineup changes. Always verify with the API before committing to a configuration.

2. Classify by behavior, not just benchmarks:
   • Claude-like models follow instructions well and handle complex prompts (big-pickle, qwen3.6-plus-free).
   • GPT-like models are principle-driven and autonomous (deepseek-v4-flash-free).
   • Gemini-like models have different reasoning patterns, good for vision (nemotron-3-super-free).
   • Utility models are fast and cheap for simple tasks (mimo-v2.5-free).

3. Hephaestus needs deep reasoning — this agent does autonomous, multi-step coding. It cannot run on lightweight models. MiniMax M3 or DeepSeek V4 Flash are the minimum viable free options.

4. Cross-reference benchmarks — I check ArtificialAnalysis.ai for coding leaderboard rankings and cost-efficiency scores. The free tier lineup shifts, but the relative ordering between free models tends to be stable.

5. Local model as anchor — it is always present. Fast, private, zero-cost. Use it for Explore, Atlas, and any category where latency matters more than capability.

Gitea Integration via MCP

One of the most powerful parts of my setup is connecting OpenCode to my self-hosted Gitea instance. This lets me say things like “resolve issue #34” and have OpenCode actually look up the issue on Gitea, read its description, implement the fix, and commit it.

Installing the Gitea MCP Server

Gitea provides an official MCP (Model Context Protocol) server:

go install gitea.com/gitea/gitea-mcp@latest

This gives you a gitea-mcp binary that speaks the MCP protocol over stdio.

Configuring Gitea MCP in OpenCode

Add the Gitea MCP server to your opencode.json:

{
  "mcp": {
    "gitea": {
      "type": "local",
      "command": ["gitea-mcp", "-t", "stdio"],
      "environment": {
        "GITEA_HOST": "http://192.168.1.47:3000",
        "GITEA_ACCESS_TOKEN": "your-access-token-here",
        "GITEA_INSECURE": "true"
      },
      "enabled": true
    }
  }
}

Replace GITEA_HOST with your Gitea instance URL and GITEA_ACCESS_TOKEN with a personal access token that has repository read/write permissions. The GITEA_INSECURE flag is only needed if your Gitea uses self-signed HTTPS or HTTP.

The Gitea MCP server exposes tools for issue management, repository browsing, pull requests, and more. Once connected, OpenCode agents can call these tools directly.

Using Issue References

With Gitea MCP configured, you can reference issues naturally:

opencode run "Research issue #34 — explain what it's about and what needs to be done"

Or for full resolution:

opencode run "Resolve issue #5 — fix the bug described in the issue and commit the changes"

OpenCode will:

1. Call the Gitea MCP issue_get tool to fetch the issue details
2. Read the description, comments, and labels
3. Understand what needs to be done
4. Make the code changes
5. Commit and (optionally) submit a pull request

You can also ask OpenCode to list open issues, triage them, or summarize the state of a repository. The Gitea MCP server supports issue listing, commenting, label management, and more.

Configuring Your Working Directory

For OpenCode to resolve #issue references correctly, make sure you run it inside the cloned repository that matches your Gitea instance:

cd ~/projects/my-repo
opencode run "Fix issue #42"

OpenCode will match the local .git remote to your Gitea MCP configuration. If the remote is on your self-hosted Gitea, the agent will use the MCP tools. If it is on GitHub, it will use the GitHub integration instead.

Configuring Language Server Protocols (LSP)

OpenCode supports LSP servers for language-specific intelligence. This is essential for getting accurate code suggestions, type checking, and refactoring support.

Here is my LSP configuration for Rust:

{
  "lsp": {
    "rust-analyzer": {
      "command": ["/Users/danielvela/.cargo/bin/rust-analyzer"],
      "extensions": [".rs", ".toml"]
    }
  }
}

For other languages, the pattern is the same — specify the command path and the file extensions the server should handle. Common LSP servers include:

LSP integration gives OpenCode type awareness, import resolution, and accurate code completion. Without it, the agent is working blind on language-specific details.

Using OpenCode: Daily Workflow

One-Shot Tasks

For bounded tasks that do not need iteration, use opencode run:

opencode run "Add retry logic to the API client and update the tests"

You can attach files for context:

opencode run "Review this config for security issues" -f config.yaml -f .env.example

Force a specific model:

opencode run "Debug why the tests fail in CI" --model opencode/minimax-m3-free --thinking

Interactive Sessions

For iterative work, launch the TUI:

opencode

This opens the terminal interface. Use Ctrl+X M to switch models, Ctrl+X N for a new session, Ctrl+X L to switch sessions, and Ctrl+C to exit.

Monitoring Progress

One important thing: the TUI is not easily monitorable from outside. If you need to automate or supervise sessions, prefer opencode run over the interactive TUI. The one-shot mode gives you complete output when finished, while the TUI redraws with ANSI escape codes that make external monitoring unreliable.

For long-running tasks, use the --model flag explicitly. Without it, OpenCode may try to resolve the default model from opencode.json, which can cause ProviderModelNotFoundError if the provider prefix is missing:

# Correct — includes provider prefix
opencode run "Refactor auth module" --model vllm-pro6000/Qwen3.6-27B

# Wrong — will fail with ProviderModelNotFoundError
opencode run "Refactor auth module" --model Qwen3.6-27B

Session Management

Check your token usage:

opencode stats

List past sessions:

opencode session list

Resume your last session:

opencode -c

Lessons Learned

The local model is more valuable than I expected. A 27B model on a dedicated GPU handles code exploration, quick fixes, and simple tasks faster than any remote API. The latency advantage is enormous — sub-second responses versus the 10-30 second round-trip to a cloud provider. Reserve free tier and paid models for tasks that genuinely need more capability.

MiniMax M3 is the free-tier workhorse. At SWE-Bench Pro scores around 59%, it competes with models that cost real money. The 1M context window means you can feed it entire codebases, and it actually uses that context effectively. The sparse attention mechanism gives it 15.6x speed advantage on long contexts compared to dense attention.

Oh-My-OpenAgent changes the workflow. Instead of manually picking which model to use for each task, you delegate to the orchestrator. Sisyphus figures out whether a task needs deep reasoning, quick search, or creative exploration, and routes it accordingly. The agent model assignments are the configuration surface — once set up well, the system runs itself.

Gitea MCP is the missing piece. Issue-driven development — “fix issue #34” — is how I actually work. Connecting OpenCode to my self-hosted Gitea via MCP makes this seamless. The agent reads the issue, understands the scope, implements the fix, and commits it. The tea CLI and gitea-mcp together form a complete local development loop.

Putting It All Together

My complete opencode.json looks like this:

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": ["oh-my-openagent@latest", "opencode-agent-skills"],
  "mcp": {
    "gitea": {
      "type": "local",
      "command": ["gitea-mcp", "-t", "stdio"],
      "environment": {
        "GITEA_HOST": "http://192.168.1.47:3000",
        "GITEA_ACCESS_TOKEN": "your-token-here",
        "GITEA_INSECURE": "true"
      },
      "enabled": true
    }
  },
  "lsp": {
    "rust-analyzer": {
      "command": ["/Users/danielvela/.cargo/bin/rust-analyzer"],
      "extensions": [".rs", ".toml"]
    }
  },
  "provider": {
    "vllm-pro6000": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Tesla VLLM",
      "options": {
        "baseURL": "http://192.168.1.47:8005/v1"
      },
      "models": {
        "Qwen3.6-27B": {
          "name": "Qwen3.6-27B",
          "limit": {
            "context": 262144,
            "output": 65536
          }
        }
      }
    }
  }
}

And oh-my-openagent.json defines the agent and category model assignments shown above.

Next Steps

The obvious upgrade path is a second GPU. I am considering an additional RTX PRO 6000 to serve larger models — 70B and beyond — that do not fit in 96 GB of VRAM. Two GPUs would let me run separate vLLM instances for different model sizes, routing them through the same provider configuration.

Beyond hardware, the next iteration is better issue automation. I want OpenCode to not just resolve individual issues but to triage entire repositories — scan open issues, prioritize by impact, and batch-fix related bugs in a single session. Oh-My-OpenAgent is already set up for this; it just needs the right prompt.

I’m an iOS developer who got curious about local LLMs and ended up building a homelab with two NVIDIA GPUs, three machines, and way too many Docker containers. This is how it came together.

Why a Dedicated AI Workstation?

It started as curiosity. I wanted to experiment with local models — run them privately, iterate quickly, not depend on cloud APIs. But consumer GPUs felt inadequate for the sizes I cared about. You hit VRAM walls fast when you want to serve a 27-billion-parameter model without collapsing into swap.

So I committed to a proper build: a workstation designed from day one to host inference, image generation, and all the plumbing around it. I named it Tesla.

The Hardware

Tesla is built around the AMD Ryzen 9 9950X, 96 GB DDR5, and an ASUS ROG Crosshair X870E Hero motherboard with dual PCIe x16 slots. Nothing exotic beyond that — the interesting part is the GPU selection.

Why the RTX PRO 6000?

The RTX PRO 6000 Blackwell gives you 96 GB of VRAM in a workstation card. That is the number that matters for local LLMs. At FP8, a 27B model fits comfortably with room for context. At FP16, you can still load larger models. There simply isn’t a consumer card in this range — the GeForce RTX 5090 tops out at 32 GB.

Yes, it costs more than a consumer flagship. But once you factor in that you avoid monthly cloud bills for heavy usage, the ROI starts to look reasonable. And for development work where you iterate dozens of times a day, not waiting on an API call changes everything.

The secondary RTX 3060 (12 GB) arrived from my gaming rig, Bolt. I moved the 7900 XTX to Bolt for gaming and brought the 3060 here — a cheap CUDA-capable card that handles secondary image generation tasks without eating the PRO 6000’s memory.

It Is Not Just Capacity — Bandwidth Matters More

Capacity tells you whether a model fits. Bandwidth tells you whether it runs at a usable speed. This distinction is critical when comparing dedicated GPUs to unified-memory systems like Apple Silicon.

Chips like the M4 Pro or M5 Max advertise large amounts of unified memory — 48 GB, 64 GB, even 128 GB on Max variants. On paper, that looks like plenty. In practice, the memory bandwidth available to the neural engine is a fraction of what a dedicated GPU offers. An RTX PRO 6000 moves data at ~2 TB/s over its 680-bit bus. An M4 Pro shares its bandwidth pool across CPU, GPU, and Neural Engine, effectively delivering far less to the inference workload.

The consequence is stark: on Apple Silicon, only Mixture-of-Experts (MoE) models are practically usable at scale. MoE models activate only a subset of their parameters per token, so they demand less throughput despite their total size. Dense models — which use all parameters for every token — starve for bandwidth and crawl.

On a dedicated NVIDIA GPU, dense models fly. A 27B dense model at FP8 on the PRO 6000 generates tokens at speeds that feel responsive. The same model on an M4 Pro can be orders of magnitude slower, making it impractical for interactive work.

And it is not just about speed. Dense models tend to carry more knowledge and capability per parameter than their MoE counterparts. They were trained on broader corpora, with richer instruction tuning. Losing access to dense models because of bandwidth constraints means losing access to a significant portion of what modern LLMs can do.

That is why, for serious local inference, a dedicated GPU is not a luxury — it is a requirement.

The Rest of the Homelab

Tesla doesn’t work alone. Here’s the full picture:

Bolt — Ryzen 5 5600X, 32 GB, RX 7900 XTX. Pure gaming machine running Nobara Linux. Where the AMD GPU belongs.

Microx — Ryzen 7 5700G, 64 GB, 2×8 TB HDD mirror. Runs TrueNAS Scale as my NAS with AdGuard Home, Plex, and Transmission.

Mac Mini M4 Pro — 14-core, 64 GB. The daily driver for Xcode and iOS development.

MacBook Air M5 — Portable work and travel.

What Runs on Tesla

Tesla hosts roughly twenty services, all orchestrated through Docker Compose and exposed behind an nginx reverse proxy with Cloudflare tunnels for external access:

The PRO 6000 handles both vLLM and ComfyUI — they rarely peak at the same time, so 96 GB is enough for both workloads sequentially. The 3060 catches overflow image generation jobs.

Lessons Learned

VRAM capacity and bandwidth are both bottlenecks. Capacity determines what fits, but bandwidth determines what runs at a usable speed. Unified-memory systems like Apple Silicon look impressive on paper — 64 GB, 128 GB — but their shared bandwidth makes dense models painfully slow. Only MoE models remain practical there. A dedicated GPU with a fat memory bus is what you need for serious inference.

Dual GPUs help more than you think. Even a modest secondary GPU like the 3060 frees you from fighting over the primary card. Image generation and inference can overlap without killing each other.

Docker Compose is the glue. Twenty services on one machine sounds chaotic until you realize they’re all declared in a single compose file. Start, stop, update — one command.

Self-hosting teaches you about dependencies. You don’t just run an LLM server. You need a registry, a reverse proxy, a search backend, headless browsers, queues… The ecosystem grows organically. Having it all local is satisfying precisely because it’s messy.

Next Steps

The motherboard has two PCIe x16 slots. The second one is empty. When the workload demands it, a second RTX PRO 6000 goes in — doubling to 192 GB of VRAM for even larger models or concurrent workloads. Until then, one card is plenty.

The dream is simple: local models that rival cloud quality, running on hardware I control, in my own office. We’re getting close.

For the uninitiated, Nostr works like this: Users create cryptographically signed “notes” (events) in client apps, which are then published to relays – essentially decentralized servers that store and distribute these events. Relays don’t control the content (they can’t alter it without breaking signatures), but they act as hubs for discovery and propagation. Clients pull data from multiple relays, giving users full control over what they see and share. It’s chaotic in the best way, reminiscent of the early internet, and it opens the door to a ton of innovative applications. Let’s break down some of the coolest ones that are already out there or could be built, grouped by category for clarity.

Social Media and Communication Apps

Nostr’s core strength lies in decentralized social networking, making it a natural fit for Twitter-like platforms but with way more freedom.

• Microblogging Clients: Apps like Damus (the OG iOS client) and Amethyst (Android powerhouse) let you post short updates, follow users, and engage in threads without a central authority banning you. Nostter offers a web-based Twitter vibe, while Nostur brings it to iPhone and macOS.
• Chat and Instant Messaging: Beyond public posts, Nostr supports end-to-end encrypted DMs and group chats. Think Slack or MS Teams alternatives – DinoDaddy_arrived on Reddit suggested building E2EE chat apps that integrate seamlessly with Lightning Network for micropayments.
• Video Conferencing: Hivetalk combines Nostr with Lightning for video calls, perfect for decentralized meetings.
• Forums and Closed Groups: Using sub-protocols like NIP-29, you can create censorship-resistant forums or private communities, ideal for niche discussions without Big Tech oversight.

Content Creation and Sharing

Nostr isn’t limited to text; it’s a playground for all kinds of media and long-form content.

• Blogging and Long-Form Writing: Habla lets you read, write, curate, and even monetize articles over Nostr. Imagine a decentralized Substack where relays handle distribution.
• Bookmarking and Web Annotations: Tools for saving and annotating web content, turning Nostr into a personal knowledge base.
• Media Sharing: Share pictures, voice notes, or videos directly. Spring Browser (Android) focuses on Nostr media, while potential apps could mimic Pinterest for visual boards.
• Decentralized Wikipedia: A collaborative encyclopedia where edits are signed events stored on relays, resistant to censorship.

Collaboration and Productivity Tools

Why stop at social? Nostr’s protocol can power team tools and dev workflows.

• Code Collaboration: Jack Dorsey once bountied a GitHub alternative on Nostr – think decentralized repos with git integration for issue tracking and pull requests.
• Productivity Suites: Alternatives to Salesforce for CRM or OpenTable/Yelp for reservations and reviews, all user-owned.
• File Hosting and Sharing: Use relays for torrent sharing or file distribution, creating a decentralized Dropbox.
• Task Management: Slack-like apps for teams, with events for tasks, reminders, and integrations.

Media and Entertainment Applications

Get ready for fun – Nostr can disrupt streaming and gaming in big ways.

• Music and Podcasting: A Spotify alternative where artists publish tracks as events, monetized via zaps (Lightning tips).
• Video Streaming and Livestreaming: Build YouTube clones with video notes, or apps for live broadcasts distributed across relays.
• Gaming: As mentioned in a Medium series on Nostr, gaming apps could use the protocol for multiplayer coordination, leaderboards, or in-game chats.
• Reddit Alternatives: Nvote is already out there as a decentralized voting and discussion platform.

Commerce and Marketplaces

Nostr’s integration with Bitcoin and Lightning makes it prime for economic apps.

• Decentralized Marketplaces: Peer-to-peer buying/selling like a censorship-resistant eBay, with events for listings and transactions.
• Couchsurfing Clones: Travel apps for hosting and staying, using signed events for reviews and bookings.
• Wallets and Zaps: Tools like lnpass manage keys for Lightning and Nostr, while Zapstore is a web-of-trust app store.
• Liquidity Marketplaces: Liquiditystr enables P2P Lightning swaps over Nostr.

Other Innovative and Niche Uses

The beauty of Nostr is its extensibility – here’s where things get wild.

• Emergency Alerts: Nostr can be used for real-time alerts in crises, leveraging relays for instant distribution.
• Analytics and Dashboards: Nashboard provides network stats, while NosTracker monitors NIP support.
• Bots and Automation: LikZap auto-zaps liked notes, or bots for bridging to other networks.
• Search and Discovery: Specialized search clients or ndxstr for advanced querying.
• Identity and Login: “Login with Nostr” as a DID/VC system for data ownership across apps.

Of course, this is just scratching the surface. With libraries in languages like Rust, Python, and JavaScript (e.g., nostr-tools, nostr-py), developers can whip up custom relays like Chorus or tools like nostcat for debugging. The ecosystem is exploding – check out awesome-nostr on GitHub for an exhaustive list.

In wrapping up, Nostr’s protocols and relays aren’t about replacing one app; they’re about enabling a thousand flowers to bloom in a truly open digital commons. If you’re a builder, dive in – the potential for censorship-resistant, user-sovereign apps is endless. What do you think we should build next? Drop a comment or hit me up on Nostr if you’re there. Until next time, keep decentralizing!

The Core Principle: Value Creation Comes First

The most impactful businesses begin with a purpose beyond profit. They identify a societal need—a gap in health, education, connection, or convenience—and build solutions to address it. Only after delivering that value can a company capture a portion of it as profit, provided it has optimized its operations to balance quality and efficiency.

This approach flips the traditional mindset. Instead of chasing revenue, visionary entrepreneurs ask: What problem can I solve? When the solution resonates, customers respond, and financial success follows as a byproduct. But it all hinges on two critical steps: first, creating genuine value, and second, refining the processes to deliver that value sustainably.

Isaac Carasso and the Danone Legacy

A shining example of this philosophy is Isaac Carasso, the founder of Danone. In the early 20th century, Carasso, a Sephardic Jewish immigrant from Thessaloniki, settled in Barcelona. At the time, many children in Europe suffered from digestive issues and malnutrition, exacerbated by a lack of accessible, nutritious food. Inspired by the emerging science of gut health and the work of Nobel laureate Élie Metchnikoff, Carasso saw an opportunity to make a difference.

He began producing yogurt, a food rich in probiotics that could improve digestion and overall health. In 1919, he founded Danone, naming it after his son Daniel’s nickname, “Danon.” Carasso’s mission was clear: to provide a nutritious, affordable product that would help children grow stronger and healthier. His focus wasn’t on immediate profits but on addressing a pressing societal need.

Carasso’s approach was rooted in value creation. He sourced high-quality bacterial cultures, ensured rigorous production standards, and made yogurt accessible through pharmacies, positioning it as a health product rather than a luxury. By prioritizing quality and purpose, he built trust with consumers. Only later, as Danone grew, did he refine production processes to scale efficiently, capturing value through profitability without compromising his mission.

Lessons for Today’s Entrepreneurs

Isaac Carasso’s story offers timeless lessons for modern businesses:

1. Start with a Purpose: Identify a real problem and build a solution that matters. For Carasso, it was children’s health; for your business, it could be sustainability, education, or community empowerment.

2. Prioritize Quality Over Quick Wins: Delivering value means ensuring your product or service genuinely improves lives. Cutting corners may boost short-term profits but erodes long-term trust.

3. Optimize for Sustainability: Once you’ve created value, focus on efficiency. Streamline operations, reduce costs, and scale responsibly to capture value without diluting your mission.

4. Build Trust Through Impact: Carasso’s commitment to health earned him loyalty that transcended borders. Today, Danone remains a global leader because its foundation was built on purpose, not profit.

Conclusion: Value as the Foundation of Success

Isaac Carasso’s journey with Danone reminds us that businesses thrive when they prioritize societal value over immediate financial gain. Profits are the reward for solving problems effectively and efficiently, not the starting point. Whether you’re launching a startup or leading an established company, the lesson is clear: create value first, optimize relentlessly, and the rewards will follow.

As entrepreneurs and innovators, let’s take inspiration from Carasso’s vision. What value can you bring to the world? Start there, and the rest will fall into place.