OpenAPS's original loop lets a temporary-basal command live for only 30 minutes

Dana Lewis beside an early OpenAPS rig, in a photograph published in 2016. The visible tangle of medical devices, commodity computing, radio hardware, and software is not incidental: the system's architecture exists to make those boundaries explicit. Photograph published by Gitter and freeCodeCamp.[7]

Every five minutes, OpenAPS asks a safety-critical question: should an insulin pump temporarily raise, lower, or keep its basal rate? Its answer never receives permanent authority. The original reference implementation gathers a fresh glucose reading and pump history, calculates insulin already active in the body, produces a proposed action with a human-readable reason, and checks that proposal against several limits. When action is required, it asks the pump to set or cancel a temporary basal—typically 30 minutes in the basic design—then verifies the pump-reported state.[1][2][4]

A “closed loop” can sound like a sealed appliance: sensor data enters, insulin comes out, and the intelligence lives somewhere opaque in between. OpenAPS is nearly the opposite. That makes it worth reading as open-source architecture, even for engineers who will never operate it. The system does not become safer merely because its code is public. Its more interesting move is to give each five-minute decision less authority than the entire application appears to possess.

This is a study of system design, not a build guide or medical recommendation. Insulin dosing is safety-critical, hardware compatibility is narrow, and legal and clinical rules differ by jurisdiction. An international consensus found meaningful evidence for open-source automated insulin delivery while explicitly declining to recommend it universally over commercial systems or outside local governance.[6]

A loop of artifacts, not a magic model

The oref0 repository describes its tools in three verbs: monitor, predict, and control.[2] Those categories map onto separate questions.

Monitoring asks what is true now. OpenAPS reads a continuous glucose monitor when a new value arrives—normally every five minutes—and queries the pump for its programmed profile, recent boluses, temporary basal history, reservoir and status. The resulting state includes recent glucose deltas, insulin on board, basal schedule, insulin sensitivity, target range, carbohydrate information when supplied, and user preferences.[1][4]

Prediction asks where that state may be heading. The core determine-basal.js logic combines the current reading with short- and longer-window glucose deltas, expected insulin activity, recent deviation from that expectation, and several projected glucose paths. It does not reduce uncertainty to a single confident forecast. Its output retains values such as eventual glucose, minimum guard glucose, insulin-only predictions, and—in configurations that use it—unannounced-meal predictions.[4]

Control asks whether a forecast justifies a pump command. In the original oref0 path, the result is first a temporary-basal recommendation: a rate and duration, or no change, accompanied by a reason field that records why the branch was taken. Later SMB-enabled configurations can also recommend a microbolus; that actuation difference matters and returns below.[1][2][4] A calculation can be inspected without actuating anything; an enactment can be compared with the suggestion that preceded it; and a loop that chose to do nothing can explain which input or limit blocked action.

The architecture is distinctly Unix-like. Longer-lived settings, current observations, calculated state, and suggested or enacted actions are represented as small artifacts passed between tools rather than hidden inside one permanent process. The point is not aesthetic purity. When the physical outcome matters, a reviewer needs to ask four different questions: Were the inputs fresh? Was the calculation internally coherent? Was the command inside configured limits? Did the device actually accept it?

The proposal is fenced at several layers

The original oref0 design narrows actuation at several layers.

First, it uses temporary basal rates rather than ordinary bolus commands. A repeated bolus command could accumulate insulin each time it is sent. Reissuing the same temporary basal keeps a rate in force; it does not multiply that rate. The basic reference design uses 30-minute temporary basals, so the command expires. If communication stops and no new decision arrives, the pump returns to its pre-programmed basal therapy.[1]

Second, the algorithm does not get to choose any basal rate it wants. With the default multipliers, maxSafeBasal is the lowest of the pump's own maximum, three times the highest scheduled basal rate, and four times the current scheduled basal rate. The corresponding configuration keys are max_daily_safety_multiplier and current_basal_safety_multiplier. On a different axis, max_iob in oref0 0.6.0 and later caps the total insulin on board from basal, SMB correction, and bolus insulin that the loop will allow to accumulate while treating above-target glucose.[1][5]

Third, missing or contradictory evidence is itself an input. The reference design says OpenAPS should fall back to the programmed basal when required information is absent or points in conflicting directions. After issuing a command, the rig queries the pump again to confirm that the pump reports the requested temporary basal as active.[1] A successful function return is therefore not treated as proof that the pump accepted the new state—and even that reported state is not proof of insulin delivery into the body.

These layers form a safety envelope, not a safety certificate. A cap derived from incorrect pump settings can still be wrong. A glucose sensor can lag, compress, fail, or produce noisy readings. Insulin already delivered cannot be rolled back. The preferences documentation accordingly treats features such as max_iob, sensitivity limits, and supermicrobolus settings as consequential therapy parameters, not harmless application toggles.[5]

The difference is subtle but fundamental: OpenAPS does not ask one algorithm to be infallible. It constrains what a fallible calculation may request, how long the request lasts, what the pump will accept, and what happens when the next observation never comes.

The little computer is a compatibility boundary

The cover photograph, published in 2016, shows Dana Lewis beside an early OpenAPS rig: a Raspberry Pi and radio link sit among a pump, glucose-monitoring hardware, batteries, phones, and screens.[7] It looks improvised because it was assembled across device boundaries manufacturers had not designed as one product.

That physical stack explains why “the algorithm” is only one component. The glucose monitor measures; the pump retains its own programmed therapy and actuator limits; a radio interface translates between proprietary device communication and the Linux computer; oref0 calculates and orchestrates; and Nightscout can receive data for remote viewing when connectivity is available. The reference design keeps local looping autonomous rather than making an internet dashboard part of the dosing dependency chain.[1][7]

This separation contains failure, but it also creates operational work. The rig needs power. Device clocks and fresh readings must agree closely enough for a dose calculation. Radio communication can fail even while the computer is healthy. A remote graph can be stale while the local loop continues, or appear healthy after the local rig has stopped. “The service is up” is meaningless unless the operator names which service: sensor acquisition, pump communication, calculation, enactment, or upload.

Compatibility therefore sits in the center of the design, not at its edge. OpenAPS originally depended on pumps whose communication could be read and controlled through community-built tooling. A different pump protocol, glucose source, or radio bridge changes the most safety-sensitive adapter in the system, even if determine-basal.js remains byte-for-byte identical.[2][7]

Observability belongs inside the control surface

Many applications add logs after the main design is finished. OpenAPS makes explanation part of the action. The reason field can state that glucose is falling faster than expected, that a prediction crossed a threshold, that the existing temporary basal is already close enough, or that a safety setting constrained the requested rate.[4][5]

That output serves three audiences at once. The person using the system can see why it acted. A contributor can connect a surprising result to a named input or branch. A researcher can distinguish a forecast from the pump command that followed. None of those readers has to infer intent solely from the later glucose trace, where meals, activity, sensor error, absorption, and previous insulin all overlap.

There is an important limit: transparency is not the same as simplicity. A readable reason can summarize a branch without teaching someone how to validate insulin-action curves, basal profiles, or sensor behavior. Open source makes inspection possible; it does not transfer clinical competence into the repository. The consensus guidance treats education, informed choice, data privacy, professional support, and local policy as part of the system around the code.[6]

The operational lesson is broader than health software. For a controller, logs should preserve the chain from observation to proposal to bounded command to acknowledgement. A dashboard that shows only the final state discards the evidence needed to explain the transition.

The implementation aged; the pattern traveled

Maintenance now changes the adoption decision. The oref0 release page lists version 0.7.1, published on June 19, 2022, as its latest release.[3] That is a clear signal against treating the original Raspberry Pi stack as an ordinary fresh install in 2026. Safety-critical code does not become current because its documentation still renders, and an unarchived repository is not the same thing as an actively shipping product.[2][3]

The design's influence is wider than that release clock. The clinical consensus describes oref0/oref1 algorithms in OpenAPS, AndroidAPS, and FreeAPS X, while distinguishing those implementations from the separate Loop algorithm.[6] But the actuation model did not stay fixed: oref1 can deliver supermicroboluses, which cannot expire after delivery. It therefore adds checks that the system has complete pump-history knowledge and can first set enough zero temporary basal to keep the projected outcome safe before issuing one.[1] The 30-minute expiration pattern in this article belongs specifically to the original oref0 temporary-basal path, not to every action in every descendant.

That distinction is the responsible way to read it. Do not infer present-day hardware support from an old photograph or copy commands from historical setup pages into a medical device. Read the implementation to see how a community made a safety-critical action inspectable: calculate before enacting; keep actuator limits outside the forecast; expire commands into a known baseline; reject stale evidence; confirm the pump-reported command state; and preserve the explanation beside the action.

OpenAPS's most durable contribution is not the claim that open code can replace every institution around medical hardware. It is a sharper engineering claim: when software is allowed to touch the physical world, the design should reveal which commands are permitted, how long they last, what evidence produced them, and what happens when the next reading never arrives.

cronfeed.work