So the comparison is not about replacing Amber's tariffs. It is about replacing SmartShift's control model.
Amber positions SmartShift as a personalised battery plan built from forecast prices, forecast solar and forecast household usage. SoCrates is a browser-based energy automation platform with explicit rules, live telemetry, manual overrides, history, ROI and public decision tools.
The real trade-off
Amber SmartShift is for people who want Amber to own the optimisation logic.
SoCrates is for people who want to keep Amber pricing, but stop handing battery strategy to a retailer-managed black box.
That is the cleanest way to frame it.
Amber's own help content describes SmartShift as repeatedly updating a battery plan as forecasts change. SoCrates' shipped automation engine is rule-based and deterministic: rules are evaluated on a recurring cadence, sorted by priority, and the first fully matching rule wins the cycle.
Amber's biggest strength is also the thing that eventually frustrates people
SmartShift is attractive because it removes work. Amber gives users a managed optimiser, two automation modes, and some manual control options in the app. For plenty of households, that is enough. They do not want to write rules. They want Amber to make the calls.
Amber describes the two main modes as Battery Booster and Earnings Optimiser, with the difference largely being how aggressively the algorithm uses battery cycling budget.
But the same design creates the limit.
You are not really telling the battery what to do. You are choosing Amber's operating style, then hoping the optimiser shares your priorities.
That is where users start hitting the wall.
The black-box problem is not imagined
Amber's support material now covers common SmartShift behaviour questions such as why manual commands take time to action, why SmartShift appears inactive, why charging may not happen in the very cheapest interval, why charging can occur in a demand window, why solar might still export during negative feed-in conditions, and why the battery can sit in preserve charge.
That is the tell.
The issue is not that users are confused by one-off quirks. The issue is that managed optimisation inevitably creates moments where the user sees behaviour they would not have chosen themselves.
And when that happens, Amber can explain the optimiser, but it still owns the optimiser.
SmartShift wants to be the controlling layer
This is the part that matters most in a real comparison.
Amber's own onboarding material tells users to remove time-based battery control settings and disable external control devices where those would conflict with SmartShift. In AlphaESS onboarding, Amber says time-based controls in the AlphaESS app will override SmartShift and should be removed. In Sigenergy onboarding, Amber says external control devices connected to the system must also be disabled.
That is not a small detail.
It means SmartShift is not just another input. It expects to be the authority over battery behaviour.
That is fine if you want Amber to be the authority. It becomes a problem if you do not.
Amber's manual controls do not really solve the ownership problem
Amber does provide manual controls. But Amber's own docs say these are requests to override SmartShift's automation plan, and that they generally take around 3-5 minutes to be executed. Amber also explains that the request passes through Amber, its integration partners, and then the inverter layer before the result shows up.
That matters because it reinforces the product model.
You are still working inside Amber's control system. You are not authoring the battery logic. You are asking Amber's control system to pause or bend for a moment.
If your main frustration is, "I want to be able to tell the battery exactly what I want here," that is not the same thing.
SoCrates is not trying to be a retailer optimiser
SoCrates is a different kind of product.
The current shipped platform supports live telemetry, Amber and AEMO pricing inputs, weather-aware automation, quick control, direct scheduler editing, automation history, audit, ROI analysis, curated rule templates, a public ROI calculator and a public battery wear estimator.
Its rule engine is explicit: AND-only logic, numeric priorities, one winning rule per cycle, with default recurring evaluation at 60 seconds. Background automation continues through the scheduled backend even when the browser is closed. The live site also positions SoCrates as requiring no hardware changes.
That is a fundamentally different proposition.
Amber says: trust the optimiser.
SoCrates says: define the logic, then inspect exactly what happened.
This is where SoCrates is stronger
Seeing the logic
Not just an explanation after the fact, but explicit conditions, actions, priorities and winning rules.
Shaping the objective
Not choosing between Amber's modes, but deciding your own thresholds, reserve logic, forecast logic and rule stack.
Faster operational control
SoCrates supports quick control, direct scheduler flows and immediate automation-cycle triggering from the authenticated app, while unattended automation continues in the backend.
Reviewing what happened properly
Automation history, audit, ROI views, rules library and public decision tools are part of the live product surface.
Keeping Amber pricing without Amber owning the battery strategy
SoCrates supports Amber pricing, but it also supports AEMO. It is an automation layer, not a retailer bundle.
This does not make SmartShift bad
Amber still wins for a very specific type of user.
If you want the least thinking, the least setup after compatibility is sorted, and a retailer-managed optimiser that mostly handles things for you, SmartShift is still the cleaner fit. That is exactly what it is designed to be. Amber's own framing is forecast-led battery optimisation inside its wholesale retail model.
But that is also the dividing line.
Amber works best when you are comfortable surrendering more control.
SoCrates works best when you are not.
The honest comparison
Choose Amber SmartShift if...
You want Amber to manage the battery logic for you, you are comfortable with Amber being the controlling layer, and you prefer a simpler managed experience over writing or inspecting your own automation rules.
Choose SoCrates if...
You want to keep Amber pricing but replace SmartShift's black-box control model with explicit, user-shaped automation; you want history, audit and ROI visibility; and you want a dedicated automation layer without building a full Home Assistant or Modbus stack yourself.
Final word
The soft version of this comparison would say Amber SmartShift and SoCrates are just two flavours of battery automation.
That is not quite right.
SmartShift is a retailer-managed optimisation layer.
SoCrates is a user-controlled automation layer.
SoCrates is not an alternative to Amber tariffs.
It is an alternative to handing battery strategy to SmartShift.
If you still want Amber to own the logic, SmartShift may be enough.
If you want to keep Amber pricing but stop living inside a retailer-managed black box, that is exactly where SoCrates starts to make sense.
SoCrates gives you explicit rules, quick control, audit history, ROI views and public decision tools in one browser-based automation layer.