Last updated: August 24, 2026
This Beta Policy applies when you install or use a pre-release build of Kalam (beta, rc, alpha, preview, or similar). It supplements the Terms & License and Privacy Policy. Where this page and those documents disagree about beta diagnostics, this page governs. If you do not agree, do not use a beta build — install a stable release instead.
TL;DR
- Beta is unfinished. It can break, lose data, or behave unlike the eventual stable release. Do not use it for work you cannot afford to lose.
- We send anonymous usage events and sanitized diagnostic logs. This cannot be turned off on beta builds.
- We do not send audio, transcribed text, or API keys.
- Diagnostic logs are kept for up to 90 days.
- A beta feature may change, vanish, or later require Pro or Max. Using beta does not lock in a free or discounted entitlement.
- Switch to Stable (and install a stable build) to stop required diagnostics.
1. What "beta" means
A beta (or other pre-release) build is software we are still testing. It is provided for evaluation, not as a finished product. It may be unstable, incomplete, or incompatible with your setup. We may change, pause, or end the beta — or any feature in it — at any time, with or without notice. We may never ship a given feature to stable.
There is no extra charge to run a beta build, and no service-level commitment. If a beta feature later ships in a paid plan, using it during beta does not entitle you to keep it free. Use is at your own risk. The same "as is" terms in the Terms & License apply with even greater force.
2. Risk, backups, and what not to use it for
Pre-release software can crash, corrupt local settings, or make history and notes hard to recover. We are not responsible for lost data, lost time, or a machine that no longer behaves as it did. Before you install or update a beta build, export a workspace backup from Settings → Advanced.
Do not use a beta build for medical, legal, financial, or other business-critical dictation — the Terms already forbid relying on Kalam in those contexts. For passwords, banking, and similar secrets: sanitization of diagnostic logs is best-effort, not a guarantee. Prefer a stable build, keep sensitive-app protection on, and use a local engine. If you would not paste the text into an error log, do not dictate it on beta.
3. Required diagnostics
On beta builds we automatically collect:
- Anonymous usage events — product research events such as app loaded, sign-in, license, sync, and beta-session markers. Events do not include audio, transcripts, or API keys. License keys, if present, are hashed and used only as a sampling index.
- Sanitized diagnostic logs — warning, error, and debug-oriented log bundles that help us find crashes and misconfigurations before they reach stable. We strip obvious secrets (API keys, tokens) on the device and again on the server. Sanitization is best-effort, not a guarantee — treat logs as sensitive.
This collection cannot be turned off while you are on a beta build. Checking "I agree to the Beta Policy" during setup is how you consent. If you do not agree, do not continue — install a stable build instead.
If you are signed in, a log bundle may be linked to your account so we can debug a report you send us. Device identifiers are hashed before storage. Signed-in diagnostics may incidentally include an account identifier (for example an email on the account). That is not dictation content.
4. What we never collect as telemetry
Beta diagnostics are not a backdoor into your dictation. We do not include:
- Audio or microphone recordings
- Transcribed or polished text
- API keys or other credentials (and we scrub them when they appear in logs)
- Full screen contents, clipboard, or context-awareness payloads
How dictation audio is processed (on-device, your cloud provider, or Kalam Cloud) is unchanged and is described in the Privacy Policy.
5. Retention
- Diagnostic log bundles — kept for up to 90 days, then deleted. We cap how many bundles we keep per user or device, and how many can be uploaded per device per day.
- Anonymous usage events — follow the same product-analytics retention described in the Privacy Policy (cold archive on the order of one year).
We are not obligated to return diagnostic bundles to you. Extra files you attach yourself (for example a log you download from Settings → Advanced and email to us) are voluntary.
6. Feedback
If you send comments, suggestions, crash reports, or other feedback about a beta build, you grant us a perpetual, irrevocable, royalty-free right to use, share, and commercialize that feedback for any purpose. Do not send feedback that is licensed in a way that would require us to open-source Kalam if we use it. Do not include secrets or personal data you do not want us to see. These rights survive if you leave beta.
You do not have to send written reports. Using the build is enough.
7. Support and leaving beta
We have no obligation to provide support, maintenance, or uptime for a beta build. We may help when we can; that does not create an ongoing duty.
To leave: open Settings → About, switch the update channel to Stable, and install the stable build. Once you are on a stable release, telemetry is off unless you opt in under Settings → Privacy, and we do not upload diagnostic log bundles automatically.
8. Other policies
This Beta Policy does not replace the Terms & License or the Privacy Policy. Warranty disclaimers, limitation of liability, and acceptable-use rules in the Terms still apply. For a beta build, this page governs the extra diagnostics and evaluation terms above.
We may update this page. Material changes will be noted with a new "Last updated" date. Continued use of a beta build after a material change is acceptance of the new text.
Email: hello@balacode.io