A `@Configuration` class has one `@Bean` method call another `@Bean` method directly — `return new OrderService(pricingClient())` — expecting it to behave like an ordinary Java method call. Twice in the same context, that call returns the same singleton object both times. Why, mechanically, does that happen, and what changes if the class is annotated `@Configuration(proxyBeanMethods = false)`?

@Configuration classes are themselves CGLIB-proxied by Spring — the same mechanism used for @Transactional and friends, applied to the configuration class itself — specifically so that calling pricingClient() from inside another @Bean method doesn't actually run the method body a second time. The proxy intercepts that call, recognises it's asking for a bean the container has already built and cached as a singleton, and returns the existing instance instead of letting the raw method execute again. It looks and reads exactly like a plain Java method call, and that's precisely what makes it easy to miss that it isn't one. @Configuration(proxyBeanMethods = false) turns off that interception: the configuration class is no longer proxied, calling pricingClient() becomes an ordinary method invocation that genuinely re-executes the method body, and two calls now construct two separate, uncached objects — which silently breaks any code relying on the earlier singleton-sharing behaviour.