# 7B Model Chokes on Multi-Call Comparisons — Here's How I Fixed It > Source: > Published: 2026-08-04 16:45:33+00:00 # 7B Model Chokes on Multi-Call Comparisons — Here's How I Fixed It The setup: a PyBaMM digital twin simulating an LG M50 21700 cell, wrapped as six [MCP](/en/tags/mcp/) tools over stdio. A LangGraph ReAct agent backed by `qwen2.5:7b` via Ollama picks the tools and narrates the results. The six tools: — static cell description`cell_info` — constant-current discharge (runtime, capacity, energy)`simulate_discharge` — CC-CV charge (charge time, energy input)`simulate_cccv_charge` — ranks multiple charge rates in one call`compare_charging_strategies` — compares multiple discharge rates in one call`compare_discharge_rates` — capacity fade over N cycles via SEI growth`simulate_degradation` Single-tool questions worked great from day one. Ask "how long at 1C?" and the agent calls `simulate_discharge(c_rate=1.0)` , reads the result, and answers. Reliable.The break came with comparisons. Ask "2C versus 0.5C" and the natural ReAct pattern is two sequential `simulate_discharge` calls — one per rate. On `qwen2.5:7b` , this reliably failed. The model would chain one call, get the result, then either stop or hallucinate a second answer. No error thrown — just a confident, well-formatted response missing half the data. Exactly the kind of quiet failure the physics-grounding was supposed to prevent, just moved up one layer from number generation to tool orchestration. It wasn't the only rough edge. `llama3.1:8b` at one point printed tool calls as literal JSON text instead of invoking them, so no simulation ran at all — that's what pushed me to `qwen2.5:7b` . Separately, the agent would sometimes speculate about *why* a number looked a certain way: labeling delivered capacity above the 5.0 Ah nominal rating as "inefficiency" or "over-discharge" when running above nominal capacity at gentle rates is just normal cell behavior. The root issue isn't model size — it's planning horizon. A two-call comparison isn't one decision; it's several in sequence: call tool A, hold its result in context, decide to call tool B with different arguments, hold that result too, then reason over both. That's a chain the 7B model loses track of. The fix was collapsing comparison logic into single-call tools. Instead of asking the model to chain `simulate_discharge` twice, I built `compare_discharge_rates` and `compare_charging_strategies` to run multiple simulations server-side and return a ranked result. The model now makes one call, gets a complete answer, and there's no multi-step planning to fail. The prompt I use for the agent: ``` You are a battery engineering expert assistant. You have access to simulation tools that run real electrochemical models. Always use the appropriate tool for the question asked — never guess at numbers. If a comparison is needed, use the comparison tools. Only speculate about results after you have the data. Keep answers concise and grounded in the simulation output. ``` This isn't just about smaller models — it's about designing tools that match the planner's actual capacity. Every tool I build now goes through the same filter: what's the minimum number of sequential calls a 7B model can reliably chain? If the answer is more than one, I fold the logic into the tool itself. [Next How to Spot the Real GigaChat (and Avoid the Fakes Draining Your →](/en/threads/4936/)