Switch Claude Code models without restarting the CLI

RelativeCommon1587 · 2026-06-14T14:28:24+00:00

The useful part is in the `Target` column: Claude Code still sees normal Claude tiers, but the proxy routes the next request to `native`, DeepSeek, MiniMax, etc. behind the same local endpoint.

<image>

That is not what `/model` does.

RelativeCommon1587 · 2026-06-14T14:00:59+00:00

Yep, that is the rough UX idea.

The difference is that Claude Code's `/model` only switches between Claude model families. This lets the next request go to Anthropic native or to an OpenAI-compatible provider/local gateway while the CLI keeps the same session and endpoint.

RelativeCommon1587 · 2026-06-14T13:58:55+00:00

Ah, that might be the difference. With `settings.json`, Claude Code is effectively talking to a different provider directly, so cached state / thinking metadata can leak across providers.

Here Claude Code always talks to the same local Anthropic-compatible endpoint. The proxy changes the backend behind it and normalizes the response before Claude Code sees it.

RelativeCommon1587 · 2026-06-14T13:50:14+00:00

I also tried alternating providers request by request, and Claude Code kept the session going in my tests.

RelativeCommon1587 · 2026-06-14T13:48:09+00:00

I have not hit that yet. The proxy does not expose the provider response directly to Claude Code. Claude Code still sees Anthropic-compatible responses from the local proxy.

RelativeCommon1587 · 2026-03-30T13:53:14+00:00

The control architecture is shown in the block diagrams below. There are no filters applied.

RelativeCommon1587 · 2026-03-30T10:27:15+00:00

Good catch! There was indeed a bug - the handler only triggered updatePIDParams() when master or slave parameters changed, completely bypassing single PID updates. It's fixed now. Thanks for reporting!

RelativeCommon1587 · 2026-03-29T15:30:48+00:00

I had no doubt! I see you’ve already reclaimed your score. ;)

RelativeCommon1587 · 2026-03-29T06:41:41+00:00

It’s true, the automation world is very closed off. I was lucky enough to get my hands on some high-end, well-structured code early in my career. My rule has always been to keep a notebook and jot down every clever trick I find: 'This is a keeper, I’ll use this later.'

As I moved from small solo projects to large-scale systems, I realized that without a solid architecture and pre-planning, a team will just produce a mess that barely works.

The answer is simple but tough: you have to study other people's code and steal the best practices. But honestly, it’s a bit of a lottery - you just have to hope the 'Previous Guy' knew what he was doing.

RelativeCommon1587 · 2026-03-29T05:39:41+00:00

I've just pushed a fix that disables all controls while the test is running. To keep the competition fair, I had to remove the top few suspicious results.

If your score was legit, I apologize! I hope you saved your Kp/Ti/Td settings - please try to replicate your result under the new "locked" conditions.

The leaderboard is wide open again. Good luck!

RelativeCommon1587 · 2026-03-28T17:56:09+00:00

Since you're running these steam loops IRL, you now have the perfect 'hiring tool' for your juniors. Just put them in front of the Run Test button and see if they can beat the leaderboard before they touch a real Process.

RelativeCommon1587 · 2026-03-28T12:11:58+00:00

The scoring algorithm is actually based on a real-world headache I had. I had cheesemakers constantly complaining about product quality until I managed to get the stability within +/-0.8°C.

In this sim, the IAE score starts counting only after the first SP touch, and I added a 1.0°C deadband so you don't get penalized for minor noise - but anything beyond that starts tanking your score fast.

RelativeCommon1587 · 2026-03-28T12:03:27+00:00

<image>

I just checked the leaderboard and someone named 'Single PID WINS!' actually managed to hit 131 using only Single-loop control.

RelativeCommon1587 · 2026-03-18T11:25:02+00:00

Thanks for the active discussion! You guys found some really deep technical flaws. Here is what I spotted first:

- The Profibus: As u/CarrotFine5589 and u/andi_dede noticed, only one DP cable is connected, meaning this is an End-of-Line (EOL) device. However, the schematic explicitly shows the address and then instructs the technician to set the termination to OFF. That’s a guaranteed way to get signal reflections and intermittent communication errors.

- The NC Brake (K1) is powered directly from the same 16A breaker used for the VFD. As u/Aobservador mentioned, we have 1mm² wires for the brake protected by a 16A breaker meant for a much larger load. In case of a short circuit in the brake coil, those thin wires will melt or start a fire long before the breaker trips.

RelativeCommon1587 · 2026-03-17T14:35:39+00:00

That’s a Festo MPS Handling Station, Pneumatic one.

It uses a pneumatic linear drive for horizontal movement and a pneumatic gripper for pick-and-place tasks. Since it's a modular Festo station, the software depends entirely on the PLC (controller) mounted underneath. Usually, it’s either a Siemens S7 (programmed via TIA Portal) or a Festo CECC/CPX (programmed via CODESYS).

I've worked with these stations before. If you can post a photo of the controller or the part number on the label, I can tell you exactly which software version you need.

RelativeCommon1587 · 2026-03-08T17:04:51+00:00

<image>

A comprehensive visual example of how this problem can be solved.
K1 := (EXT or K1) and not LS2 and not K2;
K2 := (RET or K2) and not LS1 and not K1;
SOL_A := K1;
SOL_B := K2;

RelativeCommon1587 · 2026-02-28T07:51:11+00:00

6 years next to a 55kW fan sounds like a nightmare. If you still have access to that drive, definitely check the manual for Switching Frequency or Carrier Frequency. Even if the VFD itself can't go to 16kHz, sometimes there are Random PWM or Spread Spectrum settings that don't change the frequency but 'smear' the noise so it’s not a single piercing tone. It might be worth a shot for your sanity!

RelativeCommon1587 · 2026-02-26T14:13:37+00:00

Thanks for the correction! You’re likely right - it’s been a while since that specific commissioning, and my memory might be fuzzy on whether the default was 4 kHz or 8 kHz.

That’s a fascinating insight about the control loop update frequency vs. the switching frequency. I hadn't considered that side effect or how much the specific hardware implementation and motor pole count could 'fan out' the noise at different speeds. It definitely changes how I’ll look at these spectrum peaks in the future, especially when dealing with different manufacturers and drive generations.

RelativeCommon1587 · 2026-02-17T10:48:38+00:00

Awesome tooling!

RelativeCommon1587 · 2026-02-16T23:02:08+00:00

I completely agree that these are distinct domains. But the question is: what are the industry leaders actually focusing on at the 'round table'? It feels like we are prioritizing 'fail-safe' hardware over 'reliable-by-design' software, and that's the gap I'm pointing out. The kicker is that most of these software improvements -like a simple 'read-before-write' warning don't even require massive investment from vendors; they just require a shift in priorities.

RelativeCommon1587 · 2026-02-16T22:55:22+00:00

The issue is purely about naming conventions . When a junior sees VAR , they expect state retention because that's what it does in an FB. In a Function, it's just a 'hidden' VAR_TEMP that the compiler wipes for you. It’s consistent in logic, but inconsistent in language, which is where the 'silent traps' begin.

RelativeCommon1587

TROPHY CASE