Start at a higher current. Taper before finishing.
- Predicted charge time
- 35 – 42 min
- Predicted anode minimum
- +5 – +35 mV
- Predicted peak temperature
- 38 – 47 °C
Test infrastructure for hardware teams.
Agents choose the next physical test and run solver tests within rules your team sets once. Bench tests go to a qualified person.
- 0.24 min
- gap to the best reference charge
- 5 of 8
- experiments run in the demonstration
- $1.27
- spent on model calls
Battery fast-charge results, simulated. No physical cell was charged.
The agent's proposed charge protocol, before the solver run. Background footage is published graphite microscopy.
For teams waiting on the lab
We start with US hardware teams where bench time holds up the next build. Their test queues grow as engineers and agents produce more designs.
- Batteries and energy storageCell and pack tests tie up cyclers while teams check how charging affects heat and degradation.Live today
- Data-center hardwareRacks and power shelves need load tests. Liquid cooling adds flow conditions to a crowded thermal test plan.
- RoboticsActuators and packs need repeated load tests to expose wear that a short run misses.
- Power electronicsChecking converter and drive efficiency across changing loads ties up the bench. Temperature checks add to the queue.
Battery fast-charge campaigns are live today. We plan to expand into the other markets shown here.
Designs multiply. Benches don't.
Most teams still run a fixed test matrix, even as engineers and agents add designs to the queue.
- The test queue keeps growing.
- The agent uses earlier results to choose the next test and records its prediction before the run.
- The test plan falls behind.
- When a result changes what you need to learn, the agent adjusts the next test.
- Solver runs wait for approval.
- Set spending and runtime caps for solver tests, along with a run-count limit. Eligible runs proceed on their own.
- A pass becomes a debate.
- Translucent checks every limit and compares the result with the baseline using preset pass criteria.
- The next program loses context.
- The agent can read earlier results and the reasoning behind each test when planning the next program.
Give the model a test loop
Translucent connects the model to your solver. Each result informs the next test it chooses.
| The model on its own | The model on Translucent |
|---|---|
| Suggests a test from the context you provide | Chooses the next test and predicts a range for each quantity it expects to change |
| Needs a way to run the proposed test | Runs solver tests within standing rules; sends bench requests to a qualified person |
| Writes an explanation of the result | Checks the result against criteria your team set before the run |
| Depends on you to supply earlier results | Reads earlier results before choosing what to test next |
| Needs separate tooling to check its work | Lets you re-check the work offline without our keys |
Choose the next test
Test-data tools keep measurements accessible. Simulation tools calculate what a design might do. Translucent agents use results to choose the next test, with solver limits and pass criteria set by your team.
| Capability | Translucent | Test data platforms | Agents and copilots | Simulation AI |
|---|---|---|---|---|
| Choose the next test | Uses campaign results to pick the next experiment | Does analysis change the test plan? | Do proposals use earlier results? | How does a prediction guide the next test? |
| Predict before running | Records expected ranges before each run | Are predictions saved with measurements? | Are predictions saved before the run? | Can you compare predictions with later results? |
| Run within standing rules | Runs solver tests under spending and runtime caps, with a run-count limit | How are solver limits enforced? | Who sets and enforces run limits? | Are run limits enforced outside the model? |
| Apply fixed pass criteria | Checks results against the team's pass criteria | When are acceptance criteria set? | Can the agent change the criteria? | What determines whether a result passes? |
| Re-check the whole campaign | Recomputes requests and checks file hashes offline | What can you reproduce from an export? | What remains after the agent session ends? | Can you re-check the full campaign? |
| Bring another agent | Connects any agent over MCP under the same rules | Can agents read the campaign history? | Does the history stay intact when you change agents? | Can agents access solver runs and results? |
- Evidence for the next decisionYour agent can compare earlier predictions with results when choosing the next test.
- Keep limits when models changeYour team keeps its test limits in place as new agents connect.
- Revisit earlier resultsEarlier results remain available for comparison, including when your team tightens a limit.
Train on the tests you've run
We are developing Translucent Cloud to fine-tune open-weight models on your campaigns, with your permission. We want to improve test choices for your hardware.
- Training starts with your permissionCloud will train on your campaigns only with your permission.
- Open-weight modelsWe are building around models whose weights are available for fine-tuning.
- Predictions paired with outcomesEach campaign keeps the agent's predictions alongside the test results.
The test loop runs today. Cloud is in development, and we have not shown a fine-tuning gain on these campaigns.
Keep control of each test
Connect an agent to the system you're testing. Translucent tracks each proposal through to its checked result and keeps the supporting evidence.
- AgentsConnect any agent over MCP. Each gets the same tools and rules. No agent can approve its own work.
- SystemsConnect your solver and define its allowed parameters. Translucent rejects proposals outside those bounds.
- Standing rulesSet solver spending and runtime caps once, along with a run-count limit; eligible runs proceed on their own.
- RunsSolver experiments run on the server. A qualified person carries out each physical test and uploads the result.
- Checks and evidencePass criteria are fixed before the run. The supporting evidence stays available for an offline re-check.
- Recorded battery demonstrationRe-checked offline
- AgentProposed 1.5C, then 1.4C, then 1.1C, then 0.8C
- PredictionCharge time of 35 – 42 min
- EngineerApproved the request
- SolverReturned a charge time of 37.17 min
- EngineerRaised the plating margin to +25 mV after the fourth experiment
- RuleRechecked earlier results against the tighter margin
- Simulated demonstration. An engineer approved every request by hand.
Follow one battery test
This demonstration is simulated. An engineer approved every request by hand. No physical cell was charged.
- Start with the failing baselineThe baseline took 28.2 min and reached 51.2 °C, breaking the 45 °C ceiling as well as the +25 mV anode margin.
- Choose the next testThe agent proposed a tapered charge and predicted 35–42 min before the solver ran it.
- Check the resultThe charge took 37.17 min and met the limits: anode potential was +25.9 mV and cell temperature was 44.5 °C.
- Verify the campaignOffline verification recomputed the requests and reported “131 files intact, 17 requests re-checked”.
-
Baseline, re-run on the solverFails the limits Fast charge with excessive heat
- Charge time
- 28.20 min
- Anode, lowest
- +7.3 mV
- needs ≥ +25
- Cell, hottest
- 51.2 °C
- needs ≤ 45
-
Result and verdictResult hidden See what the solver returned
Choose the final charge rate, then show the recorded result to compare it with the prediction.
1.5 · 1.4 · 1.1 · 0.8C
- Charge time
- 37.17 min
- Anode, lowest
- +25.9 mV
- needs ≥ +25
- Cell, hottest
- 44.5 °C
- needs ≤ 45
This charge meets both limits. It takes longer than the failing baseline.
-
Re-check, offlineIntact $ uv run translucent verify fastcharge-demo.loop.json 0 findings re-checked, 0 match; 131 files intact, 17 requests re-checkedLedger 5d5e9db6…1f64. The check recomputes each request and checks every file's hash, without our keys.
0.24 min from the best
On the LG M50 fast-charge benchmark, the agent came within 0.24 min of the reference search's best protocol. It matched the reference search on the held-out case. With the same 8 experiments, the model without feedback and constrained Bayesian optimization both finished slower.
| Case | Translucent agent | Same model, no feedback | Constrained Bayesian optimization | Reference search |
|---|---|---|---|---|
| A · 25 °C | 33.79 | 36.29 | 42.62 | 33.55 |
| B · margin raised to +25 mV | 37.17 | 44.29 | 42.62 | 37.13 |
| C · 15 °C, held out | 34.13 | 39.50 | 45.98 | 34.13 |
Published microscopy of graphite during charging and discharge.
The benchmark is simulated under a frozen battery model; no physical cell was charged. Model calls cost a median of $1.13–$1.22 per campaign. The agent deliberately probes limits. In cases A and C, a median of 4 of 8 experiments broke a limit, compared with 2 of 8 for Bayesian optimization. Account for those failures when planning physical tests.
The paper trail
See why each test ran and how the result informed the next decision. Scroll through the documents or choose a tab. This campaign is simulated.
Start at a higher current. Taper before finishing.
| Window | State of charge | Rate |
|---|---|---|
| 1 | 10 – 27.5 % | 1.5C |
| 2 | 27.5 – 45 % | 1.4C |
| 3 | 45 – 62.5 % | 1.1C |
| 4 | 62.5 – 80 % | 0.8C |
Reasoning, from the request
At high state of charge the anode potential is lowest and heating peaks, so holding 1.5C through steps 3 and 4 caused both the 7.3 mV minimum and the 51.2 °C peak. Front-loading current early, when the cell is cooler, and tapering late should recover the limits with less time lost than a uniform cut.
Prediction, written before the run
| Charge time | 35 – 42 min |
|---|---|
| Anode, lowest | +5 – +35 mV |
| Cell, hottest | 38 – 47 °C |
Content hash 04c8320618fd71c302db56f7fd6b3707ac4aad25540ec6868096a0e3a60b03cd
Hold a +25 mV plating margin
| Limit | Version 1 | Version 2 |
|---|---|---|
| Anode, lowest | ≥ +10 mV | ≥ +25 mV |
| Cell, hottest | ≤ 45 °C | ≤ 45 °C |
Reason given
Cell-to-cell spread in anode potential: hold a 25 mV plating margin.
What changed
After the engineer tightened the plating margin, Translucent rechecked every earlier result. Three faster protocols fell below the new margin, at +16.7, +17.7 and +12.3 mV.
The earlier verdicts remain alongside the revised comparisons.
The candidate meets the limits
| Quantity | Baseline | Candidate | Limit |
|---|---|---|---|
| Charge time | 28.20 min | 37.17 min | |
| Anode, lowest | +7.3 mV | +25.9 mV | ≥ +25 |
| Cell, hottest | 51.2 °C | 44.5 °C | ≤ 45 |
The candidate meets both limits. Its charge time is longer than the failing baseline.
Under the same limits, the fastest single-step constant-current charge takes 70 min at 0.6C.
A candidate for a physical test
The best protocol took 37.17 min. The campaign ran 5 of 8 experiments and spent $1.27 of its $1.50 model-call budget.
Still unresolved
- The +25.9 mV margin is within 1 mV of the limit, and the model's voltage runs 70–160 mV above the cell records, so the anode potential may be optimistic.
- A physical cell must be tested before these simulated results can be confirmed on hardware.
The record supports the simulation result; physical validation remains open.
Your team sets the limits
- Set solver limits once.Your team sets spending and runtime caps plus a run-count limit; standing rules authorize only eligible solver runs.
- Qualified people run bench tests.A qualified person receives the physical test request, including its prediction and pass criteria.
- No agent can approve its own work.Connecting a different agent over MCP keeps the same approval rules.
- Comparisons set the outcome.When the comparisons do not settle the outcome, it remains unresolved.
- Recheck results when limits change.Earlier results are compared again when your team changes a limit, and both verdicts remain in the record.
- Verify the work offline.The offline check recomputes each request and checks file hashes without keys from Translucent.
Re-check the recorded campaign
uv run translucent verify web/public/fixtures/loop/fastcharge-demo.loop.jsonVerify the computations and file hashes on your own machine. Physical behavior still needs a bench test.
Before you start
Does a person approve every test?
No. Your team sets standing rules once, with spending and runtime caps plus a run-count limit for solver tests. Eligible solver runs proceed on their own, while bench tests always go to a qualified person. The recorded demonstration used manual approval for every request.
Does Translucent run our hardware?
No. The agent writes a bench request with its prediction and pass criteria. A qualified person runs the test and uploads the result.
What can we use today?
Battery fast-charge campaigns are live, with open-source code on GitHub. We plan to expand to data-center hardware and robotics, as well as power electronics. Translucent Cloud is in development.
What do the battery results prove?
The results show how the agent chose charge protocols under a frozen battery model. They are simulated; no physical cell was charged. The recorded demonstration is separate from the benchmark.
How much does a campaign cost?
Model calls cost a median of $1.13–$1.22 per benchmark campaign. Product pricing and bench-test costs are outside that figure.
Will you train on our data?
Translucent Cloud is in development. It will train open-weight models on your campaigns only with your permission. We have not shown a fine-tuning gain.
Can we use our own agent?
Yes, any agent can connect over MCP. It gets the same tools and rules, and cannot approve its own work.
Can we check a campaign ourselves?
Yes. The offline command recomputes each request and checks every file's hash without keys from Translucent. The code is open source on GitHub.
Start a campaign
More designs will reach your lab. Make the next test count.
Our agents choose the next physical test, starting with battery fast charge. The benchmark is simulated. Physical validation is the next step.