Repository navigation
Conversation
Both serve the same /v1/systemone request shape, so they only need listing and a test that their extra answer fields (score legend, usage cost) parse. DECISION_MAX_BODY_BYTES lifts Ollama's 64 KiB request limit for hosts that read long states, such as Snap's 384K-token context.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
SubQ Snap and Liquid d1-ultra serve the same
POST /v1/systemonerequest shape as the hosts already listed, so the client from #120 reaches them with configuration:endpoint_urltest.legend, andusage.costfrom Liquid).DECISION_MAX_BODY_BYTES(default 65536, Ollama's limit, so nothing changes by default). Every request carries the whole state, so the fixed 64 KiB limit ruled out long states even on hosts that read them.Live checks (2026-10-27)
DECISION_MAX_QUESTIONS=64works.model_factory.get_decision_model(), both got all six topic assignments (including two multi-topic statements and one Other), both equivalence clusters, the topic-home pick, and both approval votes right.python -m src.get_bridging_scoresran end to end on each with no Gemini key.costfield). Many questions about one state are nearly free after the first.A long state: the vTaiwan UberX conversation
The 2015 vTaiwan UberX conversation on Pol.is (open data: 1,846 participants, 48,389 votes, 101 published statements, opinion groups A and B) has real answers to check against.
Who said what in a draft summary. 13 summary sentences, each paraphrasing one statement and attributing it to the groups, were written for this check in a correct and a misattributed version (26). The real group votes decide which are right.
Extraction made every verdict traceable to the statement it rests on. Mercury's
extractquestions are billed per question over the whole state (308K input tokens for these 26), unlike decision questions.Simulated jury. With 12 statements held out, the jury predicted 128 real votes on them by participants who voted on at least 10 others. Always guessing "agree" scores 87/128. Each participant's group majority on the held-out statement, an oracle, scores 103/128.
Where Snap did well:
Where d1-ultra did well:
For both models, packing many participants' rows into one state, so that each question needs a different slice of it, lost accuracy as the state grew.