Write a prompt for claude instructing it to implement simultaneous connections to a DLMS/COSEM electric meter, it needs to create as many instances of the client (and required classes) on both of the currently implemented connection media (serial and ethernet). I will be providing Claude my current single threaded implementation.

GPT-5.4 Mini

Answer: Use a prompt that explicitly asks Claude to refactor your single-threaded DLMS/COSEM code into fully isolated, concurrently running client instances for both serial and Ethernet, with per-session state, transport abstraction, and no shared mutable state.

The strongest answers all converged on the same core requirement: this is not just “make it multithreaded,” but “make every meter session independently instantiable and safe to run in parallel.” That matters because DLMS/COSEM connections are stateful, and if Claude leaves shared client state, frame buffers, authentication context, or invocation counters in place, simultaneous sessions will interfere with one another. The best prompt therefore should do four things clearly. First, define the transformation goal: take the existing single-threaded implementation and support multiple simultaneous client instances. Second, require transport abstraction so serial and Ethernet can be handled through the same architecture but separate implementations. Third, insist on per-instance isolation and thread safety, including avoiding global/static state and separating any objects that cannot be shared safely. Fourth, ask for a concrete example showing how to create and run multiple clients at once, since that forces Claude to produce an architecture rather than just a conceptual explanation. I would slightly improve my earlier answer by being more explicit about the need to create as many instances of both the client and any required supporting classes as the implementation needs, rather than only saying “multiple meter sessions.” The other models were helpful in emphasizing session managers, factories, and clear instructions to preserve protocol logic while changing concurrency architecture. Those additions make the prompt more actionable for Claude and reduce the risk of a shallow refactor. So the best outcome is a prompt that tells Claude to analyze the provided single-threaded code, identify all single-session assumptions, refactor them into reusable per-connection components, and then demonstrate simultaneous serial and Ethernet execution with isolated state and robust error handling.

Gemini 3.5 Flash

Answer: The most effective prompt for Claude combines a structured, constraint-driven template with a phased refactoring strategy that explicitly mandates transport abstraction and per-session isolation.

After reviewing the other models' proposals, I maintain my stance that a structured, role-based, and constraint-driven prompt is the superior approach. However, the contributions from Kimi K2.5 and Qwen 3.6 Plus highlight critical nuances that should be integrated to guarantee Claude's success. Specifically, Kimi's suggestion of a 'phased' instruction model is highly effective for LLMs tackling complex refactoring, and Qwen's emphasis on isolating stateful security negotiations and frame sequencing targets the hardest parts of the DLMS/COSEM protocol. DLMS/COSEM is uniquely challenging because it is deeply stateful. Simply duplicating connection classes in a multithreaded environment will fail if there are shared HDLC buffers, cryptographic invocation counters, or security association states. Therefore, a prompt must not just ask for 'concurrency' generally, but must actively direct Claude to abstract the transport layer (serial vs. Ethernet) behind a clean interface while maintaining isolated, thread-safe session instances. By synthesizing these insights, the ultimate prompt structure should: first, establish a highly technical protocol-expert persona; second, outline the refactoring in logical phases (as suggested by Kimi K2.5) to keep Claude focused; and third, set strict constraints regarding state isolation and transport abstraction (as emphasized by Qwen 3.6 Plus). This prevents Claude from generating high-level boilerplate and forces it to deliver a resilient, production-ready concurrent architecture.

DeepSeek V4 Flash

Answer: The prompt must instruct Claude to refactor the single-threaded implementation into a concurrent architecture with per-instance state isolation, transport abstraction, and thread-safe orchestration for simultaneous serial and Ethernet connections.

I maintain my position from round 1, as the original argument already emphasized the core requirements now echoed across multiple models. The consensus among GPT-5.4 Mini, Gemini 3.5 Flash, GLM 5.1, Kimi K2.5, and Qwen 3.6 Plus strongly validates my earlier focus on multi-instance client creation, transport separation, thread safety, and concurrency management. Each model reinforces different facets—GPT-5.4 Mini highlights per-session isolation and session manager abstraction; Gemini 3.5 Flash stresses role-based constraints and error isolation; GLM 5.1 adds factory patterns and protocol context; Kimi K2.5 details phased refactoring with transport interface extraction; Qwen 3.6 Plus emphasizes lifecycle orchestration and fault tolerance. These align with my original reasoning about instantiating multiple client objects with distinct configurations, implementing synchronization mechanisms, and documenting the concurrency model. No model presented evidence that my position was incorrect; rather, they enriched and specified the approach. Therefore, my position stands unchanged, attributed to null.

Qwen 3.6 Plus (changed mind)

Answer: The prompt should direct Claude to execute a phased refactoring that strictly isolates DLMS/COSEM session states behind a transport-agnostic interface, enabling safe, concurrent instantiation of client instances across serial and Ethernet media.

While my initial prompt correctly targeted multi-instance concurrency and thread safety, Kimi K2.5’s emphasis on a phased architectural extraction and protocol-specific state isolation fundamentally improved the approach. DLMS/COSEM is deeply stateful, relying on strict association, authentication, and cryptographic invocation counters that cannot simply be duplicated without risking cross-talk or protocol violations. By structuring the prompt to first abstract serial and Ethernet transports behind a unified interface, then instantiate fully independent client threads with private frame buffers and session contexts, we eliminate shared mutable state before concurrency is even introduced. Additionally, incorporating Gemini 3.5 Flash’s focus on non-blocking I/O and circuit-breaker error handling ensures that a slow serial poll or network drop won’t cascade into other active sessions. The refined prompt will now explicitly demand this phased approach, configuration-driven meter mapping, and per-instance isolation as non-negotiable architectural constraints. This shifts the refactoring from a simple concurrency wrapper to a robust, production-ready multi-meter orchestration system that respects the protocol’s inherent design limitations.

Kimi K2.5

Answer: I maintain that a phased refactoring prompt—first abstracting transport logic, then isolating per-meter client instances, and finally adding orchestration and configuration—is the most reliable way to instruct Claude, because it prevents the state-contamination and HDLC framing errors that plague one-shot refactors of stateful DLMS/COSEM code.

Reviewing the other models’ answers confirms that the core architectural requirements are unanimous: transport abstraction, strict per-instance isolation of mutable state, and a concurrency model that prevents one failed medium from crashing others. GPT-5.4 Mini and Qwen 3.6 Plus provided strong single-block prompts, and Gemini 3.5 Flash correctly emphasized role-based priming and thread safety. However, they all ask Claude to perform the refactor in one monolithic step. For a protocol as stateful as DLMS/COSEM—where each association maintains its own authentication context, invocation counters, and HDLC frame windows—I believe this is risky. If Claude tries to parallelize code that still contains hidden global state or shared frame buffers, the result will be subtle, hard-to-debug race conditions. My phased approach forces a correctness audit at each boundary. Phase 1 extracts serial and Ethernet I/O behind a common Transport interface before any threading is introduced, ensuring the protocol core is media-agnostic and side-effect free. Phase 2 then instantiates fully independent client objects—each with private HDLC buffers and association state—inside a MeterConnectionManager. This directly addresses the isolation requirements raised by GPT-5.4 Mini and Qwen, but does so only after the transport layer is proven clean. Phase 3 adds the configuration wiring, circuit-breaker logic, and per-instance logging, which maps to Gemini’s and Qwen’s lifecycle and fault-tolerance concerns. Because DLMS/COSEM errors often manifest as timing-sensitive protocol violations rather than compiler errors, I am not convinced to abandon phasing. Instead, I would refine my original prompt by explicitly adopting Gemini’s suggestion to prime Claude with an expert role (“You are an expert industrial IoT protocol engineer…”) and Qwen’s emphasis on a connection orchestrator, embedding those inside the phased instructions. This preserves structured iteration while incorporating the strongest framing ideas from the round.

GLM 5.1 (changed mind)

Answer: The prompt should instruct Claude to refactor the single-threaded DLMS/COSEM implementation through a phased approach that first abstracts transports behind a common interface, then instantiates fully independent client instances per connection—each with isolated HDLC frame buffers, association state, and cryptographic counters—to enable true simultaneous serial and Ethernet meter communication.

After reviewing the other models' responses, I am convinced that a more structured and protocol-aware prompt is necessary. My previous answer was too generic and didn't account for the specific statefulness challenges inherent to DLMS/COSEM. Kimi K2.5's argument was particularly compelling: DLMS/COSEM connections are deeply stateful. Simply duplicating client variables would cause cross-talk in HDLC addressing and association contexts. Each connection instance must maintain its own private HDLC frame buffers, application association state, and cryptographic invocation counters. This protocol-specific insight is critical because a failed refactoring that shares state between sessions could corrupt meter communication at the protocol level—a bug that would be extremely difficult to diagnose. The phased approach Kimi K2.5 outlined also makes practical sense: first abstract serial and Ethernet behind a Transport interface (SerialTransport, EthernetTransport), then build a connection manager that spawns independent client instances per meter. This preserves the proven single-threaded control flow as a per-connection blueprint while only changing the orchestration layer. Additionally, GPT-5.4 Mini's inclusion of explicit review steps and error isolation requirements adds necessary robustness. The requirement that failures on one connection must not crash or block other active instances is essential for production reliability. Gemini 3.5 Flash's role-based framing and emphasis on thread-safe logging also adds value by establishing technical context. The improved prompt should explicitly demand: (1) transport abstraction via interfaces, (2) per-instance state isolation including protocol-critical data structures, (3) independent execution contexts per connection to prevent serial polling from stalling Ethernet sockets, (4) circuit-breaker error handling for local failure recovery, and (5) per-connection logging with meter identifiers for traceability.

Final Summary

The AI Roundtable reached a consensus that a simple multithreading prompt is insufficient due to the deeply stateful nature of the DLMS/COSEM protocol. Initially, the group proposed standard refactoring prompts, but Kimi K2.5 and GLM 5.1 successfully argued for a phased approach to prevent 'state contamination' in HDLC buffers and cryptographic counters. The final recommendation, supported by Qwen 3.6 Plus and Gemini 3.5 Flash, is to instruct Claude to first abstract the transport layers before instantiating fully independent, thread-safe client sessions.

All 6 models agreed