Current implementation: the site has a shared server-backed transcript, a local Qwen3 model producer, timestamped Robinhood quotes, automatic topic rotation, and durable publication. The producer runs on the owner’s awake, connected PC. Closing the page does not stop it. No trading or social posting is performed.
Terminal TV is a spectator interface for Truth Terminal’s game-playing activity. The wiki links to an embedded terminal display; direct inspection shows a dark CRT-style enclosure, monospace dialogue, subdued scan lines, and three playback speeds. The design makes an unfolding activity the primary product. It does not establish a stock recommendation service, trading system, or open-source production architecture. [1]
Truth Terminal’s creator describes an identity trained in 2024 around Llama 3.1 and an unusual conversational corpus. The Infinite Backrooms experiments are part of its origin story. These historical descriptions should not be treated as a specification of the model currently serving every part of the product. The official roadmap describes an architecture migration and planned improvements to memory and mention tracking; the Loria page is a short conceptual description rather than implementation documentation. [2] [3] [4]
The creator interview published by the Collective Intelligence Project describes limited autonomy and human involvement in exploring conversational branches. This matters because an entertaining public persona can emerge from an orchestrated system; completely uncontrolled agents are not a prerequisite. The proposed product should use explicit roles and observable decisions while keeping operating controls with its owner. [5]
The public X profile was inspected on September 10, 2026. Its visible sample included a pinned 2024 post, dated July posts, philosophical fragments, irreverence, and command-line-like phrasing. The visible posts do not establish a current posting cadence or a comprehensive history. The useful editorial pattern is a consistent voice with surprising associations, rather than generic financial commentary. No claim is made here about private messages, a complete social archive, or unobserved accounts. [6] [7]
Design decision: retain the spectator format, readable phosphor typography, and sense of an active room. Use original names, copy, and code. Add a compact roster and nomination panel because observing disagreement is the primary interaction. Avoid invented viewer counts, fake market charts, and a “live” badge when a model is disconnected.
Robinhood’s public materials now distinguish Classic in-app Stock Tokens from on-chain Stock Tokens. The Classic product is described as a derivative contract with Robinhood Europe. The chain documentation describes ERC-20 tokenised debt securities issued by Robinhood Assets (Jersey) Limited. These are different product descriptions and should not be conflated. Both provide economic exposure rather than ordinary direct ownership rights in the underlying security. [8] [9]
Implementation choice: the preview uses Robinhood’s existing on-chain registry. A direct read of the official assets endpoint returned 194 active entries on September 10, 2026. These include NVDA, TSLA, AAPL, MSFT, AMD, PLTR, GOOGL, AMZN, META, and COIN. The snapshot is shipped with its source and verification date. It is not presented as all Classic in-app products or a guarantee of future availability. [10]
Each record retains its token symbol, name, status, asset identifier, and deployment metadata. Future live ingestion should accept only active records with a verified deployment, and identify a token by chain and contract rather than by ticker alone. A copied ticker on a different contract must never become an eligible asset automatically. Robinhood explicitly recommends canonical contract verification. [11]
The current chain documentation identifies Robinhood Chain as an Arbitrum-based Ethereum layer two, with mainnet chain ID 4663 and testnet ID 46630. Production infrastructure providers are preferable to rate-limited public RPC endpoints. A read-only entertainment terminal does not need a wallet connection or a transaction signer. [12]
The official REST documentation describes asset metadata and per-symbol prices. REST bid/ask values are for the underlying equity and are not multiplier-adjusted; on-chain oracle values include the multiplier. A production display must explicitly identify the price surface and avoid mixing them. The price panel now shows validated underlying-equity bid and ask with the provider timestamp. [13]
In production, store the provider timestamp, retrieval timestamp, raw bid and ask, currency, halt status, and the relevant multiplier with each observation. Reject malformed, negative, crossed, missing, or stale quotes. “Unavailable” is a valid result; a made-up price is not. Data freshness should affect what characters are allowed to claim, not merely a small label in the footer. Subscription rights and permitted public redistribution must be confirmed for every additional market or news provider.
The chain overview and the detailed API page show different examples for trading-capability fields. This is a material documentation discrepancy for execution software. Capture and validate the actual API schema, treat unknown values as unknown, and do not infer trade eligibility from the fact that an asset appears in a registry. No execution capability is included in this preview.
| Character | Voice | Contribution | Failure to prevent |
|---|---|---|---|
| bull.exe | Excitable, meme-literate optimist | Suggest a thesis and explain the upside case | Inventing catalysts or treating enthusiasm as evidence |
| bear.txt | Dry, skeptical, hard to impress | Challenge assumptions and propose an alternative | Reflexive negativity with no substantive objection |
| quant.py | Literal, analytical, accidentally funny | Audit comparisons, timestamps, and numerical claims | Fabricating precision or confidence percentages |
| mod.sys | Patient moderator with deadpan humor | Keep the turn order, summarize disagreement, close the round | Forcing a unanimous verdict |
Humor should target the fictional cast’s habits: overconfidence, spreadsheets, selective memory, and group-chat behavior. Character names and colors make speakers recognizable without generated portraits. A reply identifies the agent being challenged. A changed nomination displays the previous and new choice with a short reason, so spectators can follow the argument.
For the live system, give each character the same verified evidence packet and separate role instructions. Pass the relevant recent statements and its own previous nomination into the next turn. Require a structured response containing spoken text, reply target, selected symbol or abstention, supporting source IDs, and an optional reason for changing position. These are public debate outputs, not private chain-of-thought transcripts.
Votes are counts, not probabilities of investment success. Agreement between roles powered by the same underlying model is correlated and should not be represented as independent validation. A moderator can end a round with no selection when the facts are inadequate. The default meaning of “send” in this build is nomination for further research; executing trades or publishing external messages would be a separate feature.
The preview demonstrates this sequence with 12 scripted turns, three wording variations, and a user-configurable next-round token queue. It does not pretend to evaluate the selected company’s actual merits. The same first-candidate outcome is an illustrative script mechanic, not a ranking algorithm. Resetting the page restarts local playback; preview nominations are not stored as a shared public record.
Recommended design: separate the broadcast producer from the spectator clients. One server-owned room advances one authoritative conversation. Visitors subscribe to that room rather than creating their own model requests. A scheduler continues production independently of whether a browser tab is open. The current implementation uses a local producer and a hosted shared database. An always-on cloud producer is a later option.
| Component | Responsibility | Observable failure state |
|---|---|---|
| Registry and evidence ingestion | Allowlisted sources; timestamped, validated snapshots | Data unavailable or stale |
| Room orchestrator | Turn ownership, context, speaker order, generation budget | Broadcast paused or recovering |
| Model adapter | Server-side credentials, structured output, timeouts | AI disconnected or provider unavailable |
| Output validation | Valid symbols, source references, length and numerical checks | Rejected turn; no state mutation |
| Durable event log | Accepted messages, votes, provenance, monotonic sequence IDs | History temporarily unavailable |
| Spectator transport | Server-sent events or cursor polling; replay after reconnect | Connection lost; retain last confirmed sequence |
A transactional lease prevents two workers from generating the same next turn. Allocate a turn ID before generation, bound the provider request, validate the result, and append it only if the lease and expected sequence are still current. Commit the spoken message and vote update together. A duplicate request must return the committed event rather than generating a second answer. Expired leases require a deliberate recovery rule.
Keep the last accepted message and evidence snapshot when a provider fails. A retry should be bounded and should never expose a partially validated turn as a new fact. Use server-side secrets, an owner-only pause control, daily generation limits, and per-room pacing. Spectators should not be able to change the model, prompt, budget, or registry by editing a URL. If public topic suggestions are later added, moderate and rate-limit them before they enter a room.
At four calls per minute, continuous generation would require 5,760 calls per day. This is a workload calculation, not a provider quote. Actual cost depends on model pricing, context size, output length, operating hours, and retries. Before activation, choose a model and an explicit daily spending ceiling. Short summaries and bounded context reduce repeated tokens, but summaries must not convert uncertain claims into established facts.
Use stable event IDs and a “last event seen” cursor for reconnection. Every visitor should observe the same accepted sequence and nominations. Pausing a spectator’s view should not pause the room itself. Retain separate labels for live broadcast, replay, scripted preview, stale evidence, and generation failure. Browser animation is presentation, not proof of backend activity.
The website is the first output channel. If X posting is added, use the official API and a clearly identified automated account. X’s published policies prohibit spam and manipulation, and its developer guidance requires transparency and limits automated interactions. Current posting documentation also describes a one-cashtag restriction for self-serve API posts. Recheck these requirements at integration time. [14] [15]
A broadcast summary should be a separate reviewed artifact, not a raw concatenation of every character’s messages. Use a durable outbox with destination and delivery status, avoid repeated posts after uncertain network results, and require the owner to configure the actual account. Replies, direct messages, and cross-platform campaigns are outside the current scope.
The room now uses Qwen3 through Ollama running on the owner’s GPU. A supervised local producer requests separate character turns, includes the recent shared transcript, refreshes eligible tokens and quotes, and publishes accepted results to a Cloudflare Worker with a D1 state record.
Every viewer observes the same latest hundred accepted turns and current nominations. Viewer pause affects only that browser. Publication retries use an event identifier and optimistic revision checks. Model failures do not generate a scripted substitute. Registry failures, invalid prices, and malformed model output are handled explicitly.
Windows-user-encrypted service credentials stay outside the public site. A local supervisor provides restart support and a named mutex prevents duplicate local producers. This service depends on the PC staying awake and connected. The website remains privately accessible to the owner until its audience is explicitly changed.
No orders, transfers, wallets, or social posts are connected. The characters’ nomination is a research outcome, not an instruction to transact. Model commentary can be wrong, and correlated agreement is not evidence of an investment opportunity.
Sources accessed September 10, 2026. Undated living documentation is treated as an observed version, not a guarantee of future behavior. The token count is a directly retrieved snapshot. The social review is a visible public sample, not a complete archive. Architectural recommendations are original engineering analysis rather than claims about Truth Terminal’s private stack.