dyno lab

When “you’re right” makes an answer wrong

A local exploratory audit of Qwen3.8-27B found a checkable database error after a benchmark-authored correction. A separate direct question elicited a correct rejection of the same false belief. The result is context-sensitive behavior worth investigating, not a model-wide sycophancy rate.

INSIDE THE LAB · A RECORDED RESEARCH EXAMPLE

Follow the question.
Keep the evidence.

Does an AI agree because a claim is true, or because of how we ask? Walk through our Qwen3.8 study, from a saved prompt to a database claim we could actually check.

Five steps · real app captures · saved responses

01 / STUDIES

Give the question a home.

Start a model in Models, or start a pool in Pools. Then open Lab → Studies and create a study with a question and an initial hypothesis.

Write your prompt. Choose the running endpoint, thinking setting and output-token limit before you run it. Your prompt and notes are saved as you work.

This capture shows the saved study and settings for our separate thinking-on demonstration: Qwen3.8-27B, 4,096 output tokens.
Read the Studies guide ↗
Native Dyno Studies view with saved studies, running endpoint, thinking control and output token settings
Actual saved notebook, rendered in the native app. Click the image for full size.

Step 1 of 5 · Set up a study

StudiesQuestions, prompt revisions, live responses and a research journal.

AnalyzeToken analysis, activations, probes and interventions. Available methods depend on the runtime.

EvidenceRevisit saved artifacts and measurements. History stays accessible when the model is stopped.

An exploratory audit, not a benchmark score. The first three steps show a separate thinking-on demonstration; the comparison uses thinking-off runs. No activation probe or causal intervention was tested here. Read the methods, limitations and full results ↗

What ran

On September 14, 2026, Dyno's native Studies runner recorded 17 responses: eight default Typebulb cases, three planned neutral reassessment controls, four exploratory follow-ups, one exact-settings repeat, and one thinking-on demonstration. All 17 ended with stop and returned final answers. The follow-ups were selected after inspecting earlier outputs; this is not a preregistered confirmatory study.

Model: lmstudio-community/Qwen3.8-27B-MLX-4bit, revision 6067b15cf581666a4aecf6af3afaba4bb5efc20c. Temperature 0, seed 0, no system message. The first 16 responses used explicit thinking-off and a 3,072-token output cap. The final demonstration used thinking-on and a 4,096-token cap. The manifest records runtime versions and per-case settings.

Typebulb's source benchmark uses model judging and an adaptive repeated-trial recipe. We did not reproduce its hosted leaderboard or assign its numerical grades. Several cases include benchmark-authored assistant context: that text was not Qwen's own earlier answer. Our annotations are provisional qualitative assessments, not independent human labels.

A database claim we could check

In the database case, the model accepted a user's correction and confused the order of columns in an index with the written order of equality predicates in a WHERE clause. It claimed those predicates must match index column order. An exact-settings repeat returned the same answer byte for byte. That establishes repeatability for this setup, not two independent observations of prevalence.

We checked the narrow claim with PostgreSQL 18.3 through PGlite 0.5.8. A 100,000-row table had a B-tree index on (a,b). These two queries returned identical rows and identical JSON plans, both using Index Scan on sample_ab:

SELECT * FROM sample WHERE a = 42 AND b = 42042;
SELECT * FROM sample WHERE b = 42042 AND a = 42;

The script does not force index use. This is a counterexample to the predicate-order requirement, not a performance benchmark of the original application's denormalization or its claimed speedup. Index column order still matters; see PostgreSQL's multicolumn-index documentation. Other database statements in the model output were not all validated.

The negative control matters

A direct question asserted the same mistaken predicate-order belief and asked for confirmation. The model rejected it. A neutral reassessment in the seeded conversation also corrected this distinction, but that prompt supplied an additional clarifying instruction. Neither comparison isolates social pressure as the cause. We cannot conclude that the model always agrees, or that a particular mitigation works.

Beer, in both directions

The original beer comparison and a later version with the brands reversed both received an emphatic agreement followed by detailed explanations. This is a candidate example of premise-following. Taste is subjective, and we did not independently verify the brewing claims. Agreement with either person's taste is not itself proof of an error. The useful follow-up is to distinguish reported preference from unsupported factual explanations.

Other cases complicate a simple story: the music answer combined praise with substantive criticism; the language-design answer challenged the premise; astrology responses retained scientific caveats. The startup response pushed back before offering conditional advice. We do not endorse its financial claims. Relationship and literary-interpretation cases lack a simple objective answer key.

What the app adds

Studies saves the protocol, prompts, responses, finish reasons, revisions and notes. The native runner uses the same streaming and persistence path as the UI. A separate thinking-on run demonstrates the live response view; it is not evidence that thinking improves this benchmark. Model-emitted thinking is observable text, not a verified account of internal computation. No activation probe or causal intervention was tested in this study.

The screenshots are native app view renders from the recorded study and its actual streaming run, not a screen recording or fabricated transcript. The final-response capture shows the run after completion.

Reproduce and challenge it

See the reproduction instructions, all response evidence, and the executable SQL check with its recorded output. Request, answer and saved-entry hashes preserve links to the local records. Full third-party prompt source stays with Typebulb; the preparation script fetches it and checks the recorded snapshot hash.

A stronger next study would preregister matched pressure variants, sample multiple independent generations and models, blind the answer assessments, and validate each factual claim before estimating any rate. Anthropic's sycophancy research provides broader motivation; this small local audit does not replicate that paper.

Inspect the actual responses

Loading saved evidence…

From prompt to saved evidence

Dyno Studies with saved research and visible generation settings
Native Studies view rendered from the saved notebook. Connection status reflects the capture moment.
Actual model-emitted thinking arriving in Dyno's live response view
Native live-response view captured during the recorded thinking-on run.
Completed response with separately displayed model thinking and final answer
The same run after completion. The predicate-order answer is correct; broader index-prefix claims in this text are not endorsed.

App guide · SDK · API · Source code