Choosing the Right Qwen Model for Each Task (Lessons from NaLog Agent)

06 November 2026 29 mins read

When I wrote up NaLog Agent (the Qwen-powered memory agent that helps smallholder rice farmers in Isan decide when to pump), I listed the models it uses in a few bullet points and moved on. Flash for memory extraction, Plus for writing the reply, Max for the reasoning loop, VL for photos. It read like a neat, deliberate design.

Honest answer: I picked those tiers by feel during a hackathon. They felt right. Thinking where decisions are made, no thinking where you’re writing two friendly sentences in Thai, the cheapest model for background chores. But “felt right” is not a number, and on a platform for people who count diesel litres, I should know exactly what every turn costs and what I’d lose by going cheaper.

So I measured it. Same farmer questions, same demo farm, nine different ways of assigning Qwen models to the agent’s jobs (including the newer Qwen3.7 and Qwen3.8 models that production doesn’t use yet), three runs each, real calls to Model Studio and official list prices. This is what came out.

The Qwen line-up in NaLog Agent

NaLog Agent splits every farmer turn into jobs, and each job has its own model tier:

models: {
  router: process.env.MODEL_ROUTER || 'qwen3.6-flash',  // memory extraction, adjudication
  chat:   process.env.MODEL_CHAT   || 'qwen3.6-plus',   // farmer-facing reply (Thai/English)
  reason: process.env.MODEL_REASON || 'qwen3.7-max',    // agronomic reasoning + tool calling
  vision: process.env.MODEL_VISION || 'qwen3-vl-plus',  // field photos
},
thinkingTiers: ['reason'],  // only the reasoning loop gets chain-of-thought

Thinking is switched per call with the Qwen3 enable_thinking flag on the same OpenAI-compatible DashScope endpoint I use everywhere else:

if (/^qwen3/.test(model)) {
  params.enable_thinking = config.dashscope.thinkingTiers.includes(tier);
}

These are the models and what they cost on Model Studio (Singapore list prices in USD per million tokens, as published on 6 November 2026, before any caching or batch discounts):

Model Job in NaLog Agent Thinking Input Output
qwen3.7-max Reasoning loop with tools On $2.50 $7.50
qwen3.6-plus Composing the farmer’s reply Off $0.50 $3.00
qwen3.6-flash Memory extraction, contradiction checks Off $0.25 $1.50
qwen3-vl-plus Reading field photos Off $0.20 $1.60
text-embedding-v3 Memory vectors for DashVector n/a $0.07 free
qwen3-rerank Re-ordering recalled memories n/a $0.10 free

Model Studio already lists a newer generation than what NaLog Agent runs today, so I priced and tested those too:

Model Tested as Input Output
qwen3.8-max Reasoning loop $2.00 $6.00
qwen3.7-plus Reply writer, reasoning loop $0.40 $1.60
qwen3.8-flash Memory extraction, reasoning loop $0.15 $0.47
qwen3.7-flash Memory extraction, reasoning loop $0.03 $0.13

qwen3.7-flash is priced by request size, and that’s its under-32K tier, which every NaLog call fits in (so it’s older than qwen3.8-flash, but much cheaper). Newer models, lower prices across the board. On paper, upgrading is a free win. It wasn’t quite.

Note that reasoning tokens are billed as output. That one detail explains most of what follows.

How I tested it

I ran the agent locally in demo mode (the bundled Kut Chum farm in Yasothon, local storage, only a DashScope key) and logged the tokens, latency and tool calls of every single model call. Four scenarios:

  1. English sensor question: “Does Paddy 3 need pumping now?”
  2. The same question in Thai: “แปลง 3 ตอนนี้ต้องสูบน้ำเข้าไหมครับ”
  3. General knowledge: “What is AWD and why does it save water?” (no tools needed)
  4. Field photo: a real KhawTECH paddy photo with “How does this field look? Is the water level OK?”

The nice thing about the paddy question is that it has a right answer. Paddy 3 was sitting at around -12 cm, the farmer’s AWD trigger is -15 cm, so the correct advice is “not yet, but soon”, and the agent should not prepare a pump proposal. That let me score behaviour, not just cost.

Then I ran the same scenarios through nine configurations. Five on the models NaLog Agent uses today:

  • Production: Max reasons (thinking on), Plus writes, Flash extracts. What runs today.
  • Max everywhere: one model for every job with thinking on everywhere (the “just use the best model” approach).
  • Max, no thinking: production, but with thinking switched off on the reasoning loop.
  • Plus 3.6 reasons: qwen3.6-plus replaces Max in the reasoning loop (thinking on).
  • Flash 3.6 reasons: qwen3.6-flash replaces Max in the reasoning loop (thinking on).

And four on the newer generation, all with qwen3.7-plus writing the reply:

  • Newest tiered: production’s shape on the newest models. qwen3.8-max reasons, qwen3.8-flash extracts.
  • Plus 3.7 reasons: qwen3.7-plus reasons, qwen3.8-flash extracts.
  • Flash 3.8 reasons: qwen3.8-flash reasons and extracts.
  • Flash 3.7 reasons: qwen3.7-flash reasons and extracts.

Three runs each, 90 farmer turns in total. Small numbers, so read the results as signal, not gospel.

The results

Averaged over the three text scenarios:

Configuration Cost per 1,000 turns Tokens per turn Median turn time Time to first event Premature pump proposals
Max everywhere $37.42 9,397 25.6 s 2.1 s 1 of 6
Newest tiered (3.8-max) $29.24 14,655 50.7 s 3.0 s 2 of 6
Production (tiered) $18.69 7,657 17.3 s 2.2 s 0 of 6
Max, no thinking $14.09 6,729 8.0 s 6.7 s 0 of 6
Plus 3.6 reasons $8.77 11,267 23.9 s 2.0 s 6 of 6
Plus 3.7 reasons $4.19 8,304 18.0 s 2.4 s 1 of 6
Flash 3.6 reasons $4.12 8,257 14.7 s 1.7 s 0 of 6
Flash 3.8 reasons $2.26 9,143 14.3 s 1.8 s 1 of 6
Flash 3.7 reasons $1.03 9,042 14.0 s 1.8 s 0 of 6

And with a photo attached:

Configuration Cost per photo turn Median turn time Premature pump proposals
Max everywhere $0.081 61.7 s 2 of 3
Newest tiered (3.8-max) $0.045 64.4 s 2 of 3
Production (tiered) $0.032 35.9 s 0 of 3

What the numbers say

Thinking is where the money goes

Running Max with thinking on every job costs twice as much as the tiered setup and is slower, for answers that were no better.

The per-call numbers show why. With thinking on, Max spent an average of 1,051 reasoning tokens to write a four-sentence reply (18 seconds), a job Plus does without thinking in about 4 seconds for roughly a tenth of the price. Background memory extraction is worse: Max with thinking burned 942 reasoning tokens to produce a small JSON object and took almost 18 seconds. Flash does the same extraction in 1.4 seconds for about 1/33 of the cost.

None of that thinking is visible to the farmer. It’s pure overhead on jobs that don’t need deliberation. Even in production, more than 90% of every turn’s cost is the Max reasoning loop. Everything else (Plus writing, Flash extracting, the embeddings and the reranker) is rounding.

Turning thinking off is fast, but it feels slow

The cheapest way to keep Max is to switch its thinking off. Turns drop from 17 seconds to 8, and cost drops by a quarter. On paper, that’s a great trade.

Then look at time to first event. With thinking on, the browser gets something to show (thinking deltas, a tool call firing) in about 2 seconds. With thinking off there’s nothing to stream until the reply starts, so the farmer stares at an empty screen for 6.7 seconds on average. I already learnt that lesson the hard way: farmers saw “Thinking…” and gave up. A faster turn that feels dead is not an improvement.

It also used fewer tools. Without thinking, Max never once called recall_memory in these runs. It answered from the memories already in the prompt. Correct today, but that’s the step where farmer-specific history comes in, and I don’t want it skipped silently.

The newest Max made every turn more expensive

qwen3.8-max is 20% cheaper per token than qwen3.7-max, so I expected the newest tiered setup to be the easy upgrade. It came out 56% more expensive per turn and almost three times slower (50.7 seconds median).

Not because each call costs more. A single reasoning call with 3.8-max was actually about 11% cheaper. It’s because the model does more. Where 3.7-max made 1.7 reasoning calls per turn, 3.8-max made 3.0: it pulled sensor history, the farm overview and the irrigation history, saved memories nobody asked it to save, and called get_paddy_status for “What is AWD?” in every single run. Every extra round trip re-sends the whole conversation, so tokens per turn nearly doubled (14,655 vs 7,657), and each call was slower too (12.4 seconds median vs 7.4).

It was also the most interventionist model I tested. It proposed pumping in 2 of 6 sensor questions, in 2 of 3 photo turns and, once, in its answer to the general question about AWD. To be fair to it, most of those proposals weren’t random. The demo calendar says Paddy 3 is on day 21 of 21 of its vegetative stage, and 3.8-max reasoned that panicle initiation (which needs continuous flooding) is next, so better to refill now. That’s real agronomy, and the most thoughtful reading of the data of any model in the test. But the farmer’s rule is -15 cm, and a pump proposal in reply to “what is AWD?” is not what anyone asked for.

The lesson: price per token told me nothing about price per turn. In an agent, cost is price × tokens × how many loops the model decides to run, and that last factor changed between two versions of the same model. Re-measure every time you upgrade.

Plus is not a cheaper Max

This one surprised me most. Swapping Max for qwen3.6-plus in the reasoning loop cut the bill by half, but Plus used more tokens per turn (11,267 vs 7,657), took longer, and in 6 out of 6 sensor questions it prepared a pump-ON proposal for a paddy that hadn’t reached its trigger yet:

I have prepared a recommendation to turn the pump ON for Paddy 3. Please approve or reject it in your app. […] The water level is currently -11.9 cm and dropping fast (about 5.6 cm per day). It will reach the -15 cm refill trigger in roughly 13 hours.

You can see the logic (“it’ll get there soon, let’s be proactive”), but it’s the wrong call for a farmer whose explicit preference is to wait for -15 cm to save fuel. That’s exactly why the agent has no “turn pump on” tool and everything goes through human approval. Safety held. But an agent that cries wolf every time trains farmers to approve without reading, and that’s how diesel gets wasted.

Plus 3.6 is a great writer. As the decision-maker in a tool loop, it was too eager.

qwen3.7-plus is a different story. In the same seat it prepared a premature proposal in 1 of 6 sensor questions instead of 6 of 6, used fewer tokens than 3.6-plus and cost $4.19 per 1,000 turns, about half of what 3.6-plus did. Six questions are too few to crown it, but the eagerness looks mostly fixed.

Flash punched way above its weight

I expected Flash to fall over in the reasoning loop. It didn’t. At $4.12 per 1,000 turns (4.5x cheaper than production) qwen3.6-flash got every sensor question right in both languages, never proposed a premature pump action, and had the fastest first event of the lot.

The newer Flash models push the floor down further. qwen3.8-flash did the same job for $2.26, and qwen3.7-flash for $1.03 per 1,000 turns: about a tenth of a cent per farmer turn, 18 times cheaper than production, with the right answer in all 6 sensor questions. 3.8-flash slipped one premature proposal in 6, which at this sample size I wouldn’t read much into. What’s clear is that Flash-class reasoning is now cheap enough to not even show up on the bill.

Before anyone rips out Max: these were routine questions with a clear threshold. The turns where I’d expect Max to earn its keep are the messy ones: unprompted sensor alerts, contradictory memories (the diesel → electric pump switch), photos that don’t match the sensor story. Max everywhere still proposed pumping in 2 of 3 photo turns, so even Max isn’t immune. The obvious next experiment is routing by difficulty: Flash for routine status questions, Max when an alert fires or the evidence conflicts.

Vision is the cheapest call in the turn

Everyone assumes the multimodal call is the expensive one. In NaLog Agent, reading the photo with qwen3-vl-plus cost about $0.0004. Reasoning about the photo afterwards with Max cost around 70 times more.

The real problem with photos was reliability. In one of the six photo turns, Model Studio timed out downloading the image from my CDN, the retry-with-backoff kicked in, and that turn took 91 seconds. The agent degraded gracefully and answered from the sensor data alone, but a minute and a half is a long time to wait in a paddy. Serving photos from OSS in the same region as Model Studio (or sending the bytes directly) is a better bet than hoping it can fetch a public URL quickly.

Watch the language of the cheaper writer

In 2 of 12 Thai replies written by Plus, a Chinese phrase slipped into the middle of the Thai sentence (预计在, “expected to”, and 接近, “close to”). It’s a small thing, but to a farmer in Yasothon that’s noise in an otherwise perfect answer. None of the Thai replies written by Max had it, and neither did any of the 12 Thai replies written by the newer qwen3.7-plus (which is also about 20% cheaper per reply than 3.6-plus).

Same lesson as the Thai/English language flip I wrote about before: if it matters, check it in code. A regex for Han characters in a Thai reply is a few lines, and regenerating the rare bad reply with Plus is still far cheaper than writing every reply with Max.

Embeddings and reranking: pick once, then stop thinking about it

text-embedding-v3 and qwen3-rerank barely register on the bill (cents per million tokens). They matter for a different reason: the embedding model is a contract with your vector store. NaLog’s DashVector collection lives in text-embedding-v3’s vector space, so moving to a newer embedding model means re-embedding every farmer’s memories. And newer ones are already there (text-embedding-v4, qwen3.7-text-embedding). Cheap to call, expensive to change.

How I’d pick a Qwen model today

After all this, my rule of thumb for Qwen on Model Studio looks like this:

  • qwen3.7-flash for background jobs: memory extraction, classification, contradiction checks, summaries. Thinking off. Good at structured JSON, and a memory extraction cost about a tenth of what it did with qwen3.6-flash.
  • qwen3.7-plus for writing: farmer-facing replies, explanations, translations. Thinking off. Cheaper than 3.6-plus and clean Thai in my runs, but still verify the language in code if you serve anything other than English or Chinese.
  • Max for decisions that cost money when wrong: tool loops that end in an action. Thinking on, streamed to the UI so the wait is visible. For NaLog that’s still qwen3.7-max, because 3.8-max cost more per turn and acted more.
  • Flash before Max for routine reasoning: at about a dollar per 1,000 turns, it’s worth measuring. It may be enough for the boring 80% of turns.
  • qwen3-vl-plus for images: cheap per call. Host the images close to Model Studio.
  • Never put thinking on a job whose output is prose or JSON. That’s where most of the waste was.
  • Re-run the numbers on every model upgrade. A new version is a new behaviour, not just a new price.

None of this would have shown up without the token count NaLog Agent returns with every response. If your agent doesn’t report cost per turn yet, start there.

Try It Out

The agent is open source at github.com/khawtech/nalog-agent. Run the Docker demo with only a DashScope API key, and every model tier is an environment variable (MODEL_ROUTER, MODEL_CHAT, MODEL_REASON, MODEL_VISION, QWEN_THINKING_TIERS), so you can repeat the comparison with your own questions.

Next on my list is routing by difficulty: qwen3.7-flash for the routine “do I pump?” questions, Max only when a sensor alert fires or the memories disagree. If it holds up, most turns will cost a tenth of a cent, and Max gets the questions that actually need it.


StoryScope score: 50/100

Share: Link copied to clipboard

Tags:

Where: Home > Technical > Choosing the Right Qwen Model for Each Task (Lessons from NaLog Agent)