Start at a higher current. Taper before finishing.
- Predicted charge time
- 35 – 42 min
- Predicted anode, lowest
- +5 – +35 mV
- Predicted cell, hottest
- 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 used in the recorded campaign
- $1.27
- of model calls for that campaign
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
US hardware teams face a growing test queue as engineers and agents produce more designs. We start where bench time holds up the next build.
- 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 testing, while liquid cooling adds flow conditions to an already crowded thermal test plan.
- RoboticsActuators and packs need repeated load tests to expose wear that a short run misses.
- Power electronicsConverters and drives need efficiency and temperature checks across changing loads, tying up the bench between designs.
Battery fast-charge campaigns are live today; the other markets are where we plan to expand.
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.
- We choose the next test from the results so far, with a prediction written before it runs.
- The matrix outlives the question.
- The agent changes its next test when a result changes what the team needs to learn.
- Solver runs wait on someone.
- Standing rules let solver tests run on their own, with caps on spending and runtime plus a limit on run count.
- A pass becomes a debate.
- A rule set before the run compares the result with the baseline and checks every limit.
- The next program starts cold.
- The campaign keeps the reasoning behind each test alongside its result, so the agent can read that evidence later.
Give the model a test loop
A prediction needs a test behind it. Translucent connects the model to your solver and carries each result into its next decision.
| The model on its own | The model on Translucent |
|---|---|
| Suggests a test from the context you provide | Chooses the next test with a predicted range for each quantity it expects to change |
| Needs a way to execute its proposal | Runs solver tests within standing rules; sends bench requests to a qualified person |
| Writes an explanation of the result | Gets a verdict from the rule your team set before the run |
| Depends on you to supply earlier results | Reads the campaign record before choosing what to test next |
| Needs separate tooling to check its work | Leaves a record you can re-check offline without our keys |
Own the next-test decision
Your test-data tools keep measurements accessible; simulation tools calculate what a design might do. Translucent puts an agent to work choosing the next test, with rules that govern the run and its verdict.
| Capability | Translucent | Test data platforms | Agents and copilots | Simulation AI |
|---|---|---|---|---|
| Choose the next test | Uses campaign results to pick the next experiment | Check whether analysis changes the test plan | Check whether proposals use earlier results | Check how a prediction becomes a test choice |
| Predict before running | Records expected ranges before each run | Check for predictions alongside measurements | Check whether predictions are saved before execution | Check whether predictions stay linked to later results |
| Run within standing rules | Runs solver tests under spending and runtime caps, with a run-count limit | Check how rules reach the runner | Check who sets and enforces execution limits | Check whether execution limits sit outside the model |
| Apply a fixed pass rule | Computes the verdict under the team's rule | Check how acceptance criteria are fixed | Check whether the agent can change the criteria | Check how a computed result becomes a verdict |
| Re-check the whole campaign | Recomputes requests and checks file hashes offline | Check what an export lets you reproduce | Check what survives outside the agent session | Check whether the full campaign can be re-checked |
| Bring another agent | Connects any agent over MCP under the same rules | Check agent access to campaign context | Check whether changing agents preserves the record | Check agent access to solver runs and results |
- Evidence for the next decisionEvery campaign pairs predictions with outcomes your agent can use when it chooses another test.
- Rules that survive a model changeYour team keeps its test limits in place as new agents connect.
- A record that stays usefulEarlier 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 customer campaigns, with the customer's authorization. The aim is better test choices on your hardware.
- Training starts with your permissionCloud will use your campaigns for fine-tuning only if you authorize it.
- Open-weight modelsWe are building around models whose weights are available for fine-tuning.
- Predictions paired with outcomesCampaign records preserve what the agent expected alongside what the test returned.
Translucent Cloud is in development. The test loop runs today; we have not yet shown a fine-tuning gain on these campaigns.
Your rules travel with every test
Connect an agent to the system you're testing. We carry the test from proposal to a checked result, with the evidence kept alongside it.
- AgentsBring any agent over MCP; each gets the same tools and rules, and none can approve its own work.
- SystemsDefine the system's allowed parameters and connect its solver so proposals outside those bounds are refused.
- Standing rulesSet solver spending and runtime caps once, along with a run-count limit; eligible runs proceed on their own.
- RunsSolver experiments execute on the server, while physical tests wait for a qualified person to run them and upload results.
- Rules and recordA rule fixed before the run judges its result, and the campaign keeps the evidence for an offline re-check.
- From the recorded battery campaignRe-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
- RuleCompared earlier results again under the tighter margin
- Simulated demonstration. An engineer approved every request by hand.
Follow one battery test
A recorded demonstration, 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.
- Apply the ruleThe result took 37.17 min and met the limits, with the anode at +25.9 mV and the cell at 44.5 °C.
- Re-check the recordThe offline check 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
Pick a last step, then show the recorded result above 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
Slower than the failing baseline, and it meets the limits that baseline breaks.
-
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 best protocol the reference search found and matched it on the held-out case. Given the same 8 experiments, the model without feedback and constrained Bayesian optimization both ended 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.
These results are 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 probes limits on purpose: in cases A and C a median of 4 of 8 experiments broke a limit, against 2 of 8 for Bayesian optimization, a cost to weigh before planning physical tests.
The paper trail
See why each test ran and how its result changed the next decision. Scroll through the record, or choose a tab. Simulated; no physical cell was charged.
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
The engineer tightened the plating margin, and every earlier result was compared again under it. Three faster protocols now sit below the new margin, at +16.7, +17.7 and +12.3 mV.
The record keeps the earlier verdicts 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 takes longer than the failing baseline and meets the limits the baseline breaks.
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.
Agents pick the tests. Your rules hold.
- Solver runs have a boundary.Your team sets spending and runtime caps plus a run-count limit; standing rules authorize only eligible solver runs.
- Bench work stays with people.Every physical test goes to a qualified person with the request and prediction, plus the pass rule.
- The agent cannot approve itself.Any agent connected over MCP gets the same rules and cannot approve its own work.
- The conclusion is computed.The outcome follows the comparisons, including an unresolved result when the evidence cannot settle it.
- A tighter limit changes the verdict.Earlier results are compared again when your team changes a limit, and both verdicts remain in the record.
- You can check the work.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.jsonRe-check the computations and file hashes on your own machine. This checks the recorded evidence; it does not establish how a physical cell will behave.
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. For bench work, the agent writes the test request and its prediction, with the pass rule included. A qualified person runs the test and uploads the result.
What can we use today?
Battery fast-charge campaigns are live, and the code is open source on GitHub. Data-center hardware, robotics and power electronics are planned markets. Translucent Cloud is in development.
What do the battery results prove?
They show how the agent chose charge protocols in simulation under a frozen battery model. 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. That figure covers model calls only; it is not a product price or a bench-test budget.
Will you train on our data?
Translucent Cloud is in development and will fine-tune open-weight models on customer campaigns only with authorization. The results shown here do not demonstrate that fine-tuning improves performance.
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.
We choose the next physical test, starting with battery fast charge. The benchmark is simulated; the next proof belongs on the bench.