API marketplace

Lottery combinatorics as an API, computed locally and deterministically and exactly — the real odds behind a ticket, the maths the jackpot poster never shows. The odds endpoint gives the jackpot odds of a pick-N game as the number of possible tickets, C(pool, picks), times the bonus-ball pool if there is one: a 6/49 game is 1 in 13,983,816, a 5/69-plus-1/26 Powerball-style game is 1 in 292,201,338, and every single line is equally unlikely. The match-odds endpoint gives the chance of matching exactly k of the main numbers — a prize tier — from the hypergeometric formula C(picks, k)·C(pool−picks, picks−k) ÷ C(pool, picks), so matching 3 of 6 in a 6/49 game is about 1 in 57. The expected-value endpoint turns a jackpot and ticket price into the expected value and the break-even jackpot (price × the odds), the threshold a jackpot must clear before a ticket is even theoretically worth it — before a shared jackpot, lump-sum and tax pull it back under. Everything is computed locally and deterministically, so it is instant and exact. Ideal for lottery and odds apps, gambling-education and responsible-play tools, probability teaching, and game back-ends. Pure local computation — no key, no third-party service, instant. Exact combinatorics. Live, nothing stored. 3 compute endpoints. Educational — not gambling advice; the odds are always against you.

Uptime

100.0%

Latency

90ms

Subs

3,545

Roulette odds maths as an API, computed locally and deterministically and exactly — the payout, the true probability and the house edge behind every bet, the numbers a fair game tells you and a casino would rather you ignore. The payout endpoint gives a bet's payout, winning numbers, win probability and house edge for a European (single-zero) or American (double-zero) wheel: a straight-up number pays 35 to 1 but wins only 1 in 37, an edge of 2.70 % European or 5.26 % American, the same on almost every bet because the payout simply ignores the zeros. The expected-value endpoint turns a stake into its expected value — stake × (win probability × (payout + 1) − 1), always negative and equal to minus the stake times the house edge — so €10 on a single number on a European wheel is worth −€0.27 every spin. The martingale endpoint exposes the doubling system: total risked = base × (2^steps − 1), the bet that explodes after a losing streak, and the bust probability — proof on the maths that no progression beats the zero. Everything is computed locally and deterministically, so it is instant and exact. Ideal for casino-game and odds apps, gambling-education and responsible-play tools, game-design back-ends, and probability teaching. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Educational — not betting advice; the house always wins long-run.

Uptime

100.0%

Latency

78ms

Subs

4,358

Blackjack maths as an API, computed locally and deterministically and exactly — the hand value, the textbook basic-strategy play and the dealer odds, the numbers that hold the house edge to half a percent. The hand-value endpoint scores a hand the way the table does: aces count 11 unless that busts, then 1, so it reports the best total, whether it is soft (an ace still counting 11, safe to hit) or hard, whether it busts, and whether two cards make a blackjack. The strategy endpoint gives the correct basic-strategy action — hit, stand, double or split — for any hand against the dealer's upcard, for the standard 4-to-8-deck game where the dealer stands on soft 17 with double-after-split allowed: 16 against a 10 hits, a pair of 8s always splits, soft 18 doubles against a 6 but hits against a 9, and 11 doubles against everything but an ace. The dealer-odds endpoint gives the dealer's bust probability by upcard — a 5 or 6 busts about 42 % of the time, an ace only 12 % — the reason you stand on stiffs against weak upcards. Everything is computed locally and deterministically, so it is instant and exact. Ideal for blackjack trainers and strategy apps, card-game and casino-game tools, learning aids, and game back-ends. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Educational — not betting advice; the house always keeps an edge.

Uptime

100.0%

Latency

71ms

Subs

4,165

Steel heat-treatment maths as an API, computed locally and deterministically — the temperatures and hardness numbers a bladesmith, machinist or metallurgist works to. The critical-temp endpoint gives the critical and process temperatures from carbon content: the lower critical A1 is 727 °C and the upper critical A3 ≈ 910 − 203·√(%C), so a 0.4 %-carbon steel has an A3 around 782 °C and hardens about 817 °C (austenitize 30–50 °C above A3, then quench), while a hypereutectoid steel austenitizes just above A1. The tempering endpoint maps temper oxide colours to temperature both ways — light straw at about 204 °C for hard cutting edges, purple around 282, blue around 304 for springs — with the typical use at each, the colour you watch on bright steel as you draw the hardness back. The hardness endpoint converts between Rockwell C, Brinell and tensile strength (SAE J417 / ASTM E140): HRC 50 is roughly 481 Brinell and about 1,660 MPa tensile, since tensile ≈ 3.45 × Brinell. Everything is computed locally and deterministically, so it is instant and private. Ideal for bladesmithing and metalworking apps, machine-shop and heat-treat tools, materials-engineering calculators, and trade study aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Plain-carbon-steel estimates — alloy steels and a tested chart differ.

Uptime

100.0%

Latency

85ms

Subs

4,806

Industrial and protective-coatings maths as an API, computed locally and deterministically — the film-build numbers a coatings inspector, painter or estimator works to, the ones simple paint estimating skips. The coverage endpoint gives theoretical and practical coverage from the coating's volume solids and the target dry film thickness: coverage = 1604 × the volume-solids fraction ÷ the DFT in mils, where 1604 is the square feet a gallon covers at one mil — so a 50 %-solids coating at 2 mils dry covers about 401 ft² per gallon, less a loss factor for overspray and surface profile. The film-thickness endpoint converts between wet and dry film thickness through the volume solids: WFT = DFT ÷ the solids fraction, because the solvent flashes off and the film shrinks, so a 50 %-solids coating laid 4 mils wet dries to 2 mils — the number you check with a wet-film comb as you spray. The transfer-efficiency endpoint gives the real material needed: theoretical gallons ÷ the transfer efficiency, since conventional spray lands only ~25 % on the part, HVLP ~65 %, electrostatic up to ~95 %. Everything is computed locally and deterministically, so it is instant and private. Ideal for coatings-estimating and inspection apps, industrial-painting and protective-coating tools, NACE/SSPC study aids, and spec calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For simple wall-paint area estimating use a paint API.

Uptime

100.0%

Latency

78ms

Subs

3,042

HVAC duct-sizing maths as an API, computed locally and deterministically — the duct dimensions an installer or designer sizes a system with so the air moves quietly and efficiently. The round-duct endpoint gives the round duct for an airflow at a target velocity: area = airflow ÷ velocity (CFM ÷ ft/min = ft²), then diameter = √(4·area/π) — 400 CFM at a 700 fpm trunk velocity wants about a 10.2-inch round, rounded up to the next 12-inch trade size. The velocity endpoint gives the air speed inside a duct from the airflow and its size, round or rectangular — 400 CFM through a 12 × 8 duct runs at 600 fpm, comfortably quiet, while the same air in a 10-inch round moves at 733 fpm. The equivalent endpoint gives the equivalent round diameter of a rectangular duct by the ASHRAE relation De = 1.30 · (a·b)^0.625 ÷ (a+b)^0.25, so a 12 × 8 rectangular carries the same air at the same friction as a 10.7-inch round — letting you size on a round friction chart and convert to fit the space. Everything is computed locally and deterministically, so it is instant and private. Ideal for HVAC-design and installer apps, duct-sizing and takeoff tools, building-services calculators, and trade-school aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For room air changes use a ventilation API; for the cooling/heating load use an HVAC API.

Uptime

100.0%

Latency

77ms

Subs

3,153

Canasta card-game scoring as an API, computed locally and deterministically and exactly — the point counting that makes Canasta famously fiddly, done for you. The card-value endpoint totals the point value of a hand or meld: a joker is 50, aces and twos 20, eights through kings 10, fours through sevens and black threes 5, and a red three a 100-point bonus card — so a joker, an ace, a king, a seven and a red three come to 185. The bonus endpoint adds the round bonuses: a natural (pure) canasta is 500, a mixed canasta 300, each red three 100 (all four double to 800), going out 100, and going out concealed a further 100 — two naturals, a mixed, three red threes and going out is 1,700. The hand-score endpoint nets it out: the card points you melded, plus the bonuses, minus the card points left stranded in your hand when the round ends. Everything is computed locally and deterministically, so it is instant and exact. Ideal for Canasta apps, online card-room scorekeepers, club and family game-night tools, and learning aids. Pure local computation — no key, no third-party service, instant. Exact integer maths. Live, nothing stored. 3 compute endpoints. Classic Canasta values; rule variants differ.

Uptime

100.0%

Latency

79ms

Subs

4,469

Chimney and flue sizing maths as an API, computed locally and deterministically — the draft and dimension numbers a stove installer, sweep or builder runs so a fire pulls cleanly and safely. The flue-size endpoint gives the minimum flue cross-section for a fireplace opening: at least a tenth of the opening area for a square or rectangular liner, a twelfth for a round one (which draws better) — a 36 × 30 inch opening needs about 108 square inches of rectangular flue, or a 10.7-inch round. The draft endpoint gives the theoretical draft from the stack effect, ΔP ≈ 3465 × height × (1/T_outside − 1/T_flue) with temperatures in kelvin, so a 6-metre chimney with 200 °C flue gas on a freezing day pulls about 32 pascals (0.13 inches of water column) — taller and hotter draws harder. The height endpoint applies the 3-2-10 rule: a chimney must finish at least 3 feet above where it pierces the roof and at least 2 feet above anything within 10 feet, whichever is higher. Everything is computed locally and deterministically, so it is instant and private. Ideal for hearth and stove-installer apps, chimney-sweep and inspection tools, building-design calculators, and DIY-safety sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Educational estimates — verify against your appliance listing and adopted code.

Uptime

100.0%

Latency

79ms

Subs

3,284

Angling and tackle maths as an API, computed locally and deterministically — the three numbers that decide how a reel is spooled and a lure is fished. The line-capacity endpoint works out how much line of a different diameter a reel will hold: line lies on the spool by cross-sectional area, so capacity scales with the inverse square of diameter — a reel rated for 100 yards of 0.30 mm holds about 73.5 yards of thicker 0.35 mm, or nearly 140 yards of a thinner 0.011-inch braid. The sink-time endpoint gives the countdown to fish a lure at depth: time = depth ÷ sink rate, so a minnow that sinks a foot a second reaches ten feet on a count of ten. The drag endpoint sets the reel: about 25–33 % of the line's breaking strength measured at the rod tip — a 20-pound line wants roughly 5 to 6.6 pounds of drag, enough to let a fish run before anything snaps. Everything is computed locally and deterministically, so it is instant and private. Ideal for fishing and tackle apps, reel-spooling and gear-shop tools, angler trip-planners, and learning sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Unit-agnostic — keep your units consistent; rules of thumb, conditions vary.

Uptime

100.0%

Latency

78ms

Subs

3,588

Fish-farming (aquaculture) maths as an API, computed locally and deterministically — the stocking, feed and oxygen numbers a fish farmer or RAS designer runs a system on. The stocking endpoint turns a tank or pond volume and a target biomass density into a fish count: biomass = density × volume, count = biomass ÷ average fish weight — a 10 m³ tank at 30 kg/m³ holds 300 kg, about 1,200 fish at 250 g each, and you stock to the harvest weight, not the fingerling weight, so the tank does not overload as they grow. The feed endpoint gives the daily ration as a percentage of body weight, and the feed to reach a target weight gain through the feed conversion ratio — 300 kg fed at 2 % is 6 kg a day, and growing 100 kg of fish at an FCR of 1.2 takes 120 kg of feed. The oxygen endpoint gives the dissolved-oxygen demand of a stock — biomass × the per-kg consumption rate — so 300 kg at 300 mg O₂/kg/hr needs 90 g of oxygen an hour, the number your aeration must beat. Everything is computed locally and deterministically, so it is instant and private. Ideal for aquaculture and RAS-design apps, fish-farm management tools, hatchery and feed calculators, and ag-tech sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Commercial-planning estimates — species and system vary. For a home aquarium use an aquarium API.

Uptime

100.0%

Latency

74ms

Subs

4,240

Rock-climbing fall maths as an API, computed locally and deterministically — the safety numbers behind a lead fall, from the harshness of the catch to whether you hit the deck. The fall-factor endpoint gives the fall factor, distance fallen ÷ rope paid out, from 0 to a maximum of 2: it, not the absolute distance, decides how hard the catch is, so 4 metres on 2 metres of rope is a brutal factor-2 onto the anchor while the same fall on 10 metres of rope is a mild 0.4. The impact-force endpoint gives the peak force the rope transmits from the spring model F = mg + √((mg)² + 2·mg·k·f), where k is the rope modulus (~20 kN for a dynamic single rope) and f the fall factor — so an 80 kg climber on a factor-1 fall feels about 6.4 kN, and the top runner sees roughly 1.66× that from the pulley effect. The ground-fall endpoint adds it up: total drop = twice the height above the last piece, plus slack, plus the rope's stretch, and tells you whether that clears the ground or a ledge. Everything is computed locally and deterministically, so it is instant and private. Ideal for climbing apps, gym and guiding tools, route-planning and education sites, and gear calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Educational estimates — not a substitute for instruction and judgement.

Uptime

100.0%

Latency

77ms

Subs

3,784

Plumbing-code sizing maths as an API, computed locally and deterministically — the fixture-unit and pipe-sizing numbers a plumber, designer or inspector runs from the code book. The dfu endpoint totals drainage fixture units for a set of fixtures (IPC Table 709.1): pass a list like toilet:2,lavatory:3,shower:1,kitchen_sink:1 and it weights each by its discharge — a toilet is 3, a lavatory 1, a tub or shower 2 — for a total of 13, with a grouped full bathroom counting as 6 rather than the sum of its parts. The pipe-size endpoint gives the minimum building-drain size for a DFU load at a slope (IPC Table 710.1(1)): the smallest pipe whose capacity meets the load, so 50 DFU at a quarter-inch-per-foot fall needs a 4-inch drain, with the reminder that any drain carrying a water closet is a 3-inch minimum. The supply-gpm endpoint reads probable peak water demand off the Hunter curve: diversity means 100 supply fixture units draws only about 54 GPM, not the sum of every fixture running at once — the number you size the water service against. Everything is computed locally and deterministically, so it is instant and private. Ideal for plumbing-design and estimating apps, code-check and permit tools, MEP-engineering calculators, and trade-school aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Based on the IPC — verify against the code adopted in your jurisdiction.

Uptime

100.0%

Latency

82ms

Subs

4,055

Swimming-pool and spa heating maths as an API, computed locally and deterministically — the thermodynamics a pool owner, builder or service tech sizes a heater and budgets a heat-up with. The heat-time endpoint gives the hours to warm a body of water: energy = gallons × 8.34 lb/gal × the temperature rise in °F (that many BTU), divided by the heater's BTU/hr output — raising 20,000 gallons by 10 °F is 1,668,000 BTU, about 4.2 hours on a 400,000 BTU/hr gas heater before surface losses. The heater-size endpoint inverts it: the output you need to hit a temperature rise within a target time, so the same job in 24 hours wants only about 69,500 BTU/hr. The heat-pump endpoint gives a heat pump's electricity and cost — kWh = thermal BTU ÷ 3412 ÷ the COP (5–6 for pool units in mild weather) — so that 1,668,000 BTU costs about 89 kWh at a COP of 5.5, a fraction of resistance heat. Pass the temperature rise directly, or a current and target temperature. Everything is computed locally and deterministically, so it is instant and private. Ideal for pool-builder and service apps, heater-sizing and quote tools, spa and hot-tub calculators, and energy-comparison sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Ideal figures — add for surface and wind losses. For pool chemistry use a pool-chemistry API.

Uptime

100.0%

Latency

78ms

Subs

3,070

Irrigation-design maths as an API, computed locally and deterministically — the sprinkler numbers a landscaper, irrigation tech or gardener sizes a system with. The precip-rate endpoint gives the precipitation rate in inches per hour from the flow and spacing: PR = 96.25 × GPM per head ÷ the area each head waters (head spacing × row spacing in feet), where 96.25 is the in/hr one gallon-per-minute makes over a square foot — three-GPM heads on a 15 × 15 ft grid lay down about 1.28 in/hr. The runtime endpoint turns a target water depth into a run-time: depth ÷ precipitation rate, divided by the system efficiency because no system is perfectly even, so applying a half-inch at 1.28 in/hr takes about 23 minutes at full efficiency, longer with real-world uniformity. The zone endpoint sizes a valve zone: maximum heads = available flow ÷ each head's GPM, rounded down so you never starve the line — 13 GPM drives five 2.6-GPM heads with nothing to spare. Everything is computed locally and deterministically, so it is instant and private. Ideal for irrigation and landscaping apps, sprinkler-design and contractor tools, smart-controller schedulers, and garden-planning sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For evapotranspiration or weather use a weather API; for material volume use a mulch API.

Uptime

100.0%

Latency

80ms

Subs

4,046

Cornhole (bag-toss) scoring as an API, computed locally and deterministically and exactly — the points behind a game of bags, from cancellation scoring to the win and the stats. The round endpoint scores a single round with cancellation rules: a bag on the board is 1 point, in the hole is 3, and only the higher player scores, and only the difference — so a player who lands 1 on the board and 2 in the hole (7) against an opponent's 2 on and 1 in (5) nets 2 points, and a tied round scores nothing. The game endpoint applies a round's points to a running total with the win rule — official ACL play is first to 21 or more at the end of an inning with no bust, while backyard 'exact 21' rules bust a player who goes over back to 15 or 11 — and reports the new score, whether the game is won, and the points still needed. The ppr endpoint gives the headline cornhole stats: points per round (PPR) = total points ÷ rounds, plus the in-the-hole percentage from bags in the hole over bags thrown — 84 points across 20 rounds is a 4.2 PPR, and 30 of 80 bags in the hole is 37.5 %. Everything is computed locally and deterministically, so it is instant and exact. Ideal for cornhole and lawn-game apps, league and tournament scorekeepers, bracket and stats tools, and backyard game-night sites. Pure local computation — no key, no third-party service, instant. Exact integer maths. Live, nothing stored. 3 compute endpoints. Standard ACL rules; house rules vary.

Uptime

100.0%

Latency

71ms

Subs

3,246

Cigar-humidor maths as an API, computed locally and deterministically — the numbers behind storing cigars right, so you buy the correct humidor and keep it at the perfect humidity. The capacity endpoint works out how many cigars an interior holds: interior volume × a packing efficiency ÷ one cigar's volume, where a cigar is a cylinder of its ring gauge (in 64ths of an inch) and length — a 9 × 7 × 3 inch interior holds about 40 Toros (ring 50, 6 inch) at a realistic 0.62 packing, leaving room for air and a humidification device. The media endpoint sizes the humidification: about one 60 g two-way pack per 25 cigars, replaced roughly every two months, so a 40-cigar humidor wants two packs. The seasoning endpoint covers a brand-new humidor — its Spanish cedar must absorb moisture for about two weeks at 84 % RH (one seasoning pack per 25-cigar capacity, or the distilled-water wipe-down) before any cigars go in, or the dry wood will rob them. Everything is computed locally and deterministically, so it is instant and private. Ideal for cigar-shop and tobacconist apps, humidor-maker product pages, cigar-aficionado and collection-tracker sites, and buying guides. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For room humidity or dew point use a psychrometric API.

Uptime

100.0%

Latency

76ms

Subs

3,437

Dominoes scoring as an API, computed locally and deterministically and exactly — the points behind a game of bones, whether you play Block, Draw or All Fives. The score endpoint gives the winner's points at the end of a hand: when a player dominoes or the game blocks, the winner takes the total pip count left in the opponents' hands — pass each opponent's remaining pips and it sums them, optionally rounding to the nearest five as many house rules do, so 12, 8 and 23 left on the table is 43, or 45 rounded. The fives endpoint scores All Fives (Muggins): a play scores whenever the open ends of the layout add up to a multiple of five, and you score that sum — open ends of 3 and 2 make 5 for five points, 5-5-5 across a spinner makes 15, while a 6 scores nothing. The set endpoint gives the statistics of a double-N set: a double-six has (6+1)(6+2)/2 = 28 tiles and 168 total pips, a double-nine has 55 tiles and 495 pips, with the heaviest tile and its pip value. Everything is computed locally and deterministically, so it is instant and exact. Ideal for dominoes apps, online and club scorekeepers, game-night and tournament tools, and learning aids. Pure local computation — no key, no third-party service, instant. Exact integer maths. Live, nothing stored. 3 compute endpoints. Standard Western dominoes; regional variants score differently.

Uptime

100.0%

Latency

80ms

Subs

4,469

Composting maths as an API, computed locally and deterministically — the three numbers that decide whether a pile heats up and breaks down or sits there cold and smelly. The cn-ratio endpoint blends a mix to its carbon-to-nitrogen ratio: pass each material by weight with its dry-weight %C and %N as parallel comma-separated lists and it returns the total carbon and nitrogen masses and the blended C:N, with an assessment against the ideal 25–35:1 — ten parts dry leaves (50 %C, 1 %N) with ten parts grass clippings (45 %C, 2.5 %N) comes out at a near-perfect 27:1. The moisture endpoint works out the water to add to reach a target moisture (the pile should be a wrung-out-sponge 50–60 %): from the current mass and moisture it holds the dry matter constant, so 100 kg at 30 % needs about 56 kg of water to reach 55 %, and it flags a too-wet pile that needs drying instead. The mix endpoint gives the brown:green weight ratio to hit a target C:N from two materials' %C and %N — leaves and grass at a target 30:1 want about 1.5 parts browns to 1 part greens. Everything is computed locally and deterministically, so it is instant and private. Ideal for gardening and composting apps, master-composter and allotment tools, regenerative-ag and soil-health sites, and waste-diversion calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For material volume use a mulch API; for NPK application rates use a fertilizer API.

Uptime

100.0%

Latency

73ms

Subs

4,953

Riichi (Japanese) mahjong scoring as an API, computed locally and deterministically and exactly — the points a winning hand pays, straight from the scoring table, not a lookup you have to memorise. The score endpoint turns han and fu into the payment using base = fu × 2^(2 + han): a ron pays base × 4 (a dealer ron × 6) rounded up to the nearest 100, while a tsumo splits base × 2 from the dealer and base × 1 from each non-dealer (a dealer tsumo takes base × 2 from all three) — so a non-dealer 3 han 30 fu ron is 3,900, a 4 han 30 fu is 7,700, and a non-dealer mangan ron is 8,000. The limit endpoint classifies a hand: mangan (5 han, or 3–4 han where the fu pushes the base to 2,000), haneman (6–7), baiman (8–10), sanbaiman (11–12) and yakuman (13+), with the base points behind each. The honba endpoint adds the table bonuses — 300 per honba counter and 1,000 per riichi stick — on top of the won hand. Everything is computed locally and deterministically, so it is instant and exact. Ideal for mahjong apps, online-table and scorekeeper tools, club and tournament software, and learning aids. Pure local computation — no key, no third-party service, instant. Exact scoring-table maths. Live, nothing stored. 3 compute endpoints. Japanese riichi rules; other variants (MCR, Hong Kong) score differently.

Uptime

100.0%

Latency

76ms

Subs

4,500

Horse-care maths as an API, computed locally and deterministically — the everyday numbers a horse owner, barn manager or vet tech runs without reaching for a chart. The weight endpoint estimates body weight from a weight-tape measurement using the classic formula weight ≈ heart girth² × body length ÷ a type divisor (adult 330, yearling 301, weanling 280, pony 299) with measurements in inches — a horse with a 72-inch girth and 66-inch length comes out at about 1,037 lb (470 kg), the number you actually dose wormer and feed against. The feed endpoint turns body weight and a goal into daily forage: horses eat roughly 1.5–2.5 % of body weight in dry-matter forage a day, so a 1,000 lb horse on maintenance wants about 15–20 lb of hay, more to gain and less to slim. The gestation endpoint gives the foaling due date and the normal 320–362 day window from a breeding date — a mare bred on 1 April is due around 7 March the next year, give or take three weeks. Everything is computed locally and deterministically, so it is instant and private. Ideal for barn-management and horse-care apps, breeding and foaling trackers, feed-calculator and tack-shop sites, and equine-vet tools. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Educational estimates — not veterinary advice.

Uptime

100.0%

Latency

75ms

Subs

4,872

Analog darkroom and film maths as an API, computed locally and deterministically — the three corrections that bite when you develop film and make prints by hand. The reciprocity endpoint corrects long exposures for reciprocity failure, where film loses sensitivity past about a second: corrected time = metered^p (Schwarzschild p ≈ 1.3 for many films, settable per datasheet), so a metered 10-second exposure really wants about 20 seconds, a full stop more, while anything under the threshold is left untouched. The printexposure endpoint adjusts enlarger exposure when you change print size — light spreads as you raise the head, so exposure is proportional to (magnification + 1)², where magnification is print size ÷ negative size: going from 2× to 4× magnification turns a 10-second exposure into 27.8 seconds, about 1.5 stops, ready for f-stop printing. The pushpull endpoint scales development time for pushing or pulling film by N stops — time = base × factor^stops, roughly +40 % per stop pushed — turning a 7-minute base into 13.7 minutes at +2 stops, or 5 minutes pulled a stop. Everything is computed locally and deterministically, so it is instant and private. Ideal for film-photography and darkroom apps, light-meter and timer companions, lab and workshop tools, and analog-photography sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For digital depth-of-field use a photography API; for lab molarity use a dilution API.

Uptime

100.0%

Latency

73ms

Subs

3,029

Planted-aquarium and aquascaping maths as an API, computed locally and deterministically — the dosing and water numbers a high-tech planted tank runs on, not the rolls of a dice. The co2 endpoint gives the dissolved CO2 concentration from pH and carbonate hardness using the classic relationship CO2 (ppm) ≈ 3 × KH (dKH) × 10^(7 − pH), and flags it against the 15–30 ppm window plants want — at pH 6.6 and KH 4 you are at about 30 ppm, the top of the safe zone, while pH 7.0 and KH 3 is a carbon-limited 9 ppm. The fertilizer endpoint turns a dry-salt dose into the nutrient ppm it adds, the heart of Estimative Index dosing: ppm = grams × the nutrient mass fraction × 1000 ÷ tank litres, so 1 g of KNO3 in 100 litres adds 6.1 ppm nitrate and 3.9 ppm potassium, and it knows KNO3, KH2PO4, K2SO4, MgSO4 (Epsom) and Ca(NO3)2. The substrate endpoint sizes the substrate from the footprint and target depth — a 60 × 30 cm tank at 6 cm deep needs 10.8 litres, two 9-litre aquasoil bags. Everything is computed locally and deterministically, so it is instant and private. Ideal for aquascaping and planted-tank apps, fertiliser-dosing calculators, CO2-rig tools, and aquarium-shop and hobby sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For a tank water volume or fish stocking use an aquarium API; for pool chemistry use a pool API.

Uptime

100.0%

Latency

72ms

Subs

4,068

Reptile-husbandry maths as an API, computed locally and deterministically — the keeper numbers behind a healthy vivarium, so the setup is right before the animal moves in. The enclosure endpoint turns an animal length and its habit into the minimum floor length, width and height: terrestrial snakes want a floor at least as long as the snake (a 48-inch corn snake → a 48 × 24 × 24 inch minimum, eight square feet of floor), arboreal species trade floor for height (an 18-inch chameleon → 27 × 18 × 36 inches, tall), and ground lizards and tortoises need far more floor than their body length. The uvb endpoint gives the UV-B target by Ferguson zone — the 1-to-4 classification from Baines et al. (2016) of how much sun a species basks in — returning the mean and basking UV-index ranges (zone 3 open baskers want a basking UVI of 2.9–7.4), and, if you pass a lamp UVI measured at a reference distance, an inverse-square estimate of the mounting distance for the right basking UVI. The feeding endpoint sizes prey from body weight and life stage: a meal of roughly 10–15 % of body weight, no wider than the animal, on an interval that lengthens with age — a 500 g adult snake takes a 40–60 g prey item every fortnight. Everything is computed locally and deterministically, so it is instant and private. Ideal for reptile-keeper and herpetoculture apps, pet-store and breeder tools, vivarium-planning calculators, and care-sheet sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Educational husbandry estimates — not veterinary advice; research your exact species.

Uptime

100.0%

Latency

76ms

Subs

4,307

Garden and koi-pond maths as an API, computed locally and deterministically — the numbers behind a backyard water feature, so you do not have to guess at the hose. The volume endpoint turns length, width and average depth into the water volume in cubic feet, US gallons and litres, applying a shape factor (rectangular 1.0, oval or round 0.79, irregular 0.85) because a liner pond never holds the full bounding box: an 8 × 6 ft pond two feet deep is about 96 cubic feet, or 718 gallons. The liner endpoint sizes the flexible liner to fit a pond — length equals the pond length plus twice the maximum depth plus twice the overlap to anchor under the edging stones (same for width), so that same 8 × 6 pond at two feet deep with a one-foot overlap needs a 14 × 12 ft liner and matching underlayment. The stock endpoint turns a water volume into a safe fish load and the pump you need: roughly one koi per 250 gallons (they grow large and dirty) or one goldfish per 20, plus the pump flow in gallons per hour to turn the whole pond over at least once an hour for koi — 718 gallons holds about two koi and wants a ~720 GPH pump before head-height losses. Everything is computed locally and deterministically, so it is instant and private. Ideal for landscaping and pond-installer tools, garden-design and home-improvement apps, koi and water-garden hobbyist sites, and aquascaping calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For pool chemistry use a pool API; for indoor fish tanks use an aquarium API.

Uptime

100.0%

Latency

85ms

Subs

3,141