Most disposable SMS services pivot on a Twilio (or sister) deal. That gets you scale, but it also gets you a 30-day registration window for every new use case, A2P 10DLC paperwork, and per-country carrier approvals that make "test this signup flow" into a quarter.
We took a different route. The SMS fleet is a rack of physical Pixel phones on prepaid SIMs, sitting in a Faraday-friendly enclosure. Each phone is a worker reporting into a coordinator over MQTT. The cloud sees them as a pool of devices, each with a phone number.
Routing inbound
With shared numbers, the question is: when a Pixel receives an SMS, which tenant does it belong to? Our answer is a 30-minute claim window. Before triggering an OTP flow, the agent calls sms_claim_sender with the expected sender number. Inbound SMS from that number for the next 30 minutes routes to that tenant. After 30 min, the claim expires.
POST /v1/sms/inboxes/<id>/claim
{ "senderNumber": "+1...", "ttlSeconds": 1800 }
→ inbound from +1... goes here for 30 minFor outbound flows, we don't need claims — we know which tenant sent the SMS, so any reply within 72h to the same number routes back to them automatically.
Billing and economics
Carrier prepaid plans give us roughly $0.01–$0.02 marginal per SMS. We retail at $0.05 (cheapest credit pack rate). The margin pays for the phones, the SIM rotation, and the Pixel that bricked itself because Android 14 decided to.
Trade-offs we're honest about:
- Throughput per number is bounded — carriers throttle at ~60 SMS/min/phone. We rate-limit at 60/min/phone in the API.
- Some destinations have stricter rate limits (Australian carriers in particular). The fleet rotates SIMs across providers to stay under thresholds.
- Inbound delivery isn't guaranteed end-to-end the way Twilio is. We publish the success rate on /status — it's sat at 96-98% over the last 90 days.
For the use cases we serve — testing, OTP flows, MFA-as-a-tool for agents — that's plenty. If you need 100k SMS/min for marketing blasts, you should not be using us.