Family Features

What a parent gets: per-child pseudonym profiles, progress visibility, observations, and the controls over what a child can use.

Status: Live / built. This is the original, self-serve version of Synapse (predates the school-account product).

Account Architecture

A parent creates a family account; each child gets a pseudonym profile with their own PIN
Parent holds the encryption key — the family's encryption key is derived from the parent's own password (Argon2id key derivation; see Security Architecture). This is a genuine design constraint, not just messaging: it means content is technically unreadable to Synapse's servers, but it also means the parent can technically read everything their child does with Aria.
Child privacy is a product rule, not a cryptographic one. Because the parent's password holds the family key, the "summaries by default" behaviour is enforced by the application layer, not by encryption preventing parent access. Honesty with children about this is treated as what makes the privacy promise real, rather than the encryption alone.
- Correction (code audit, Aug 2026): there is no "visible notice" when a parent reads more. An earlier version of this document said full-transcript access "leaves a visible notice." No such notice exists anywhere in the code. What the code actually does is narrower in one way and looser in another, and both are worth stating precisely:
- There is no parent-facing transcript route at all. The parent dashboard's only content endpoint is /api/children/:id/notes (lib/auth.js:414), which returns learning observations, phase badges, session counts and wellbeing flags — never conversation text. It explicitly never touches social_transcript or director_transcript (lib/auth.js:433-435, 450-454).
- The route that does return a transcript, /api/transcript (index.js:741), requires the session to have been narrowed by a child PIN (index.js:742). So the way a parent reads a full transcript is by entering their child's profile with that child's PIN — and since a parent can reset any of their children's PINs at will (lib/accounts.js:260, route lib/auth.js:358), that path is always available to them.
- Net effect: the parent's ability to read everything is real, as this document has always said; it is simply unmediated by any notice, and it happens by signing in as the child rather than through a parent-side "view transcript" button.

How a Family Account Handles Multiple Children

Verified directly against the schema and account logic. The short answer: one shared login and one shared encryption key for the whole family; separate profiles and separate PINs per child; separation between siblings is enforced by application-layer scoping, not by cryptography.

One account, one email, one password. The families table holds a single email and a single pair of wrapped keys (lib/db.js:21-29). There is no per-child login credential and no second parent account.
One Data Encryption Key for the entire family. createFamilyKeys() mints exactly one random DEK at signup (lib/crypto.js:56-70), wrapped twice — once under the parent's password, once under the recovery code. Every child's profile and every child's content is encrypted under that same key (lib/accounts.js:208, 336).
Each child is a row, with their own pseudonym and their own Argon2-hashed PIN (lib/db.js:31-40; created at lib/accounts.js:198-224). Pseudonyms must be unique within a family (UNIQUE (family_id, pseudonym), lib/db.js:39). No limit on the number of children is imposed anywhere in the code.
A child's PIN is not a key. This is the crucial point. The PIN derives nothing and unwraps nothing — it is only an authentication check (lib/accounts.js:245). The DEK enters the session when the parent signs in (lib/accounts.js:87-104, 352); the child's PIN merely narrows that already-unlocked session to one child (accounts.setSessionChild, lib/accounts.js:365-368, called from lib/auth.js:346).
Consequence — siblings are separated by code, not by encryption. Because one key covers the whole family, sibling isolation rests on routes taking childId from the session rather than the request body (index.js:741-742, index.js:753-754, and resolveSocialChild at index.js:827-832, which rejects a request whose body names a different child than the session). This is implemented consistently and correctly everywhere it was checked. But it means a child who knows a sibling's PIN can sign in as that sibling and read their content — the encryption would not stop them, because it is the same key. Family accounts are designed around a household trust boundary, not a child-versus-child one.
Per-child feature control. Social Resilience and Director are toggled per child, by the parent, with the flag stored inside that child's encrypted profile (lib/accounts.js:298-307, 317-326). See Social Resilience.
Shared allowance. The free-session allowance is counted at the family level, not per child — families.trial_session_count is incremented by any child's activity (lib/db.js:224-228, lib/trial.js:18, 48), so siblings draw on one pool.
Deletion is all-or-nothing. Deleting the family destroys the wrapped keys, cryptographically erasing every child's content at once, with ON DELETE CASCADE removing the child rows (lib/db.js:33, lib/accounts.js:182-194). There is no single-child deletion — a parent cannot remove one child's profile and data while keeping the others. This matches the gap already noted in Privacy Model.
Recovery code provided at signup, parent's responsibility to store — needed to recover account access if the password is lost, since there is no server-side ability to reset a lost key (a deliberate consequence of the encryption design; see Security Architecture).

Parent Dashboard

Summaries by default — the parent dashboard surfaces summarised progress information, not raw transcripts, as the default view
Session-count visibility for Social Resilience (see Social Resilience) without content access
Consent record viewer: a parent can view the full disclaimer/consent text their family agreed to (see Privacy Model)
Self-service account and data deletion: "Delete account and all information," gated behind a confirmation dialog warning the action is permanent, unrecoverable, and ends the account. This calls a tested cryptographic-erasure function and is immediate (see Security Architecture for how cryptographic deletion works, and Privacy Model for the consent-flow context this fulfils a promise within)
Child PIN reset, available to the parent

Spend Visibility (no cap yet)

An earlier version of this document described per-family spend caps on Anthropic API usage as an existing safeguard. That was design intent that was never built, and the claim has been removed. The accurate position, as of Aug 2026:

No spend cap exists. Nothing meters or limits a subscribed family's API cost. The only adjacent mechanisms are fixed per-request max_tokens ceilings (index.js:180, 226, 245, 265), which bound a single reply rather than a family's spending, and the free-session trial counter (lib/trial.js:48, default 20 sessions) — which counts sessions, not spend, and stops applying entirely once a family subscribes (lib/trial.js:152, 176).
Usage logging now exists, for visibility only. Every Claude API call is recorded against the family that caused it, with its token counts, in an api_usage table (lib/db.js, written by lib/usage.js). It captures input, cached-read, cached-write and output tokens separately, plus which surface made the call (tutor / social / director / worksheet). It records counts only — never any part of a prompt or reply — and it deliberately gates nothing: the recording function runs after a reply already exists and swallows its own errors, so it can never interrupt a child's session. A family's usage rows are purged when that family deletes their account. scripts/usage-report.js renders a month-to-date view per family with an indicative cost at Anthropic list rates.
Whether to build a cap is an open decision, deliberately deferred until there is real usage data to set it against. At the time of writing there is essentially none — see Synapse — Product Overview for actual activity levels. The logging above is the evidence base that decision needs; a cap chosen without it would be a guess.

Curiosity Cards

A card-based engagement feature on the child's home page: a finite daily deck of cards acting as "doors" into a tutoring topic
Mix of interest-based, stretch (slightly beyond current level), and random cards, with a collection mechanic

Commercial Model (Family Accounts) — corrected

Family Synapse is a pay-what-it's-worth monthly subscription, not a fixed price. A parent tries the product (a free session allowance before any payment is required — see the shared-allowance note under "How a Family Account Handles Multiple Children" above), then names their own recurring monthly amount.

Two different numbers are involved, and they behave differently — worth stating precisely, because they are easy to conflate:

The $15 suggested amount is a visible anchor. The amount field arrives pre-filled with $15, so a parent does see a number before naming their own. The code comment describes it in exactly those terms — "an anchor, not a demand" (lib/billing.js:51-52) — and the parent is free to clear it and type anything at or above the floor (public/dashboard.html:1515).
The $10 USD floor is not shown up front. It stays hidden unless a parent names an amount below it, at which point they see the floor plus a short note about real running costs (Anthropic API usage, Google TTS) (public/dashboard.html:1529-1533). The constraint is revealed only when it becomes relevant — self-determination before the constraint, rather than a minimum presented as the starting point.

So the design withholds the constraint, not the suggestion. This mirrors the same pay-what-it's-worth approach already used for Waypoint, a separate product from the same developer.

The reasoning behind this model, stated directly by the developer: the cost of a fixed price is not the same for every family — the same dollar figure means something very different to a family under financial strain than to an affluent one. The developer has said explicitly that he is less concerned with maximising profit than with making sure a child who could genuinely benefit isn't excluded by price, while also noting that people tend to value something more when they've chosen to pay for it themselves — part of the reasoning for a name-your-own-amount model rather than a fully free product.

Once enough real subscriptions exist, the agent should be able to tell a parent the current average payment or typical range. It currently cannot — usage is too new and too low to produce a meaningful figure (see Technical Architecture). Until then, the honest answer to "what do other people pay" is that there isn't yet enough data to say.

Billed via Stripe, implemented as an inline adjustable-amount recurring subscription (Stripe doesn't support a single Price object that's both custom-amount and recurring, so this is built per-checkout rather than as a fixed catalogue price). Stripe is currently in test/sandbox mode; live payments are explicitly blocked by a code-level guard until deliberately enabled.

The originally modelled NZ$25–30/month figure is now historical context only — it described a fixed-price model superseded by the pay-what-it's-worth approach, and should not be treated as current pricing guidance.

Two further implementation details, for an agent answering specifics: there is a $500 input ceiling — not a limit on generosity, just a guard against a slipped decimal point turning $20 into $2,000; above it the parent is asked to email and set it up by hand (lib/billing.js:113-122). And amounts are in USD, not NZD (CURRENCY = 'usd', lib/billing.js:48) — so the $10 floor is roughly NZ$17 and the $15 suggestion roughly NZ$25, which is worth being precise about with a New Zealand parent.

Support Contact

A dedicated project support address exists: projectsynapsekids@protonmail.com — visible in the signed-in family experience (dashboard, account, and error/welcome screens) and in the consent disclaimer.

Relationship to School Accounts

Family and school accounts are architecturally related but operate as separate domains — a teacher account cannot decrypt family content and vice versa (cryptographic session isolation, enforced both by separate encryption keys and by query scoping in the database layer). See Security Architecture for detail.