Writing by Emmanuel Effiom Duke

Building a Metaculus forecasting bot

2026-10-08T00:00:00Z

Between October 2025 and August 2026 I built and ran an automated forecasting bot in Metaculus's AI forecasting tournaments, most recently under the name oracledeckv1. It started from Metaculus's bot template, built on the forecasting_tools library, and grew into a multi-source research and LLM-ensemble pipeline. This is what building it taught me. Most of it came from finding where the bot was quietly wrong.

How the bot works

For each open question, the bot:

classifies the question's domain (geopolitics, economics, science, tech, business, health or sports)
turns it into up to three targeted search queries
runs several search and news providers in parallel and synthesises them into one research brief with a cross-source "signal strength" score
asks an ensemble of different LLMs for a forecast, aggregated by the median for robustness to outliers
passes the result through a critic and a red-team model
applies calibration: shrinkage when the ensemble disagrees, time-decay for far-off close dates, and extremization rules

The bot was configured for three tournaments at once: the primary AI competition, MiniBench and Market Pulse.

Lesson 1: the scariest failures are silent

Reading the run logs in July turned up research providers that were failing without crashing: a wrong API call signature, a synthesis model name that didn't exist, and an SDK wrapper incompatibility. The bot kept forecasting, just with less evidence than I thought it had. I replaced the broken sources with Nimble and You.com search, and gated You.com to finance and market questions, where it added the most. Since then, I treat "it ran" and "it worked" as separate claims that need separate checks.

Lesson 2: don't extremize a toss-up

The original calibration curve pushed forecasts between 0.45 and 0.55 hard towards the extremes (strength 1.8). That produced confident-wrong forecasts and negative scores. A near-50/50 ensemble means "we don't know", and making that confident is exactly backwards. I changed the policy:

toss-ups (0.45–0.55): no extremization at all
mild leanings (0.35–0.45 and 0.55–0.65): gentle extremization
clear signals (below 0.35 or above 0.65): moderate extremization

Lesson 3: replace vibes-tuning with measurement

Tuning on live tournaments is slow and noisy, so in August I added an offline evaluation harness, built with an AI coding agent. Its two stages mean the expensive research-and-ensemble step runs once per question and is cached, after which calibration variants can be swept at zero token cost. Running it against 190 resolved binary Metaculus questions (May–August 2026) produced findings I wouldn't have guessed:

Only 31.6% resolved YES (60 of 190). The bot's habit of shrinking uncertain forecasts towards 50% was therefore a systematic bias towards YES, not a neutral safety measure. A new calibration does one bounded shrink in log-odds space towards a base-rate prior instead.
Bot accounts don't receive community-prediction aggregates: the field was empty on all 190 questions. The branch of the code that blended in the community forecast had never run.
The research-quality signal was saturated. Counting snippets hit the cap on every question, which pinned "quality" at 1.0 and silently disabled the shrink meant for weak research. It now counts distinct source domains.
Backtests leak unless search is date-bounded. A "leak canary" showed that unbounded search on resolved questions surfaced coverage of the actual outcome, while date-bounded search didn't. Without that bound, any backtest score would be inflated.

Lesson 4: know what your models know

An ensemble mixes models with different training cutoffs, and their self-reported cutoffs are unreliable (see my knowledge-cutoff probe). So the bot now measures each ensemble member's cutoff with a compact dated-event ladder and logs it next to every forecast, noting that live research extends what the model knows unaided. I also moved to a cheaper ensemble of models, each verified live before switching, and added a memory that recalls similar resolved questions alongside the bot's track record on them.

What I can't claim yet

I don't have a clean before-and-after score. Metaculus's peer score compares you with other forecasters, which can't be reproduced offline. The harness only ranks variants against each other, as a proxy. The first full stage-one run was also interrupted by upstream model-provider errors, so the head-to-head of the old and new calibration is still pending. The code, the harness and the corpus tooling are all public, so anyone can check the numbers above.

Source: dukemawex/botduke--update

Ask the calendar, not the model

2026-10-08T00:00:00Z

While comparing GPT-5.6 and Claude Fable 5 in July 2026, I needed to know their training cutoffs, so I could tell when a model was reasoning from memory and when it was guessing. The obvious move is to ask. The answers were wrong. GPT-5.6 said "June 2024" and Claude Fable 5 said "January 2025". Both contradicted their own documentation, and both contradicted their behaviour. So I built a probe that measures the cutoff instead of trusting the model's account of it.

Method: dated-event bisection

The idea is to ask the calendar, not the model:

Build a ladder of real, precisely dated events, roughly one or more per month, each with a single verifiable answer and a source.
Ask each model closed factual questions about them, with no date hints, twice at temperature 0.
Define the contiguous-known cutoff as the latest month for which the model answered every dated fact correctly before its first miss.
Stay blind to self-report: the model is never told a date, and its claim is compared only afterwards.

Results across nine models

Model	Self-reported	Measured cutoff
GPT-5.6 Luna / Sol / Terra	June 2024	Sept 2025
Claude Fable 5	January 2025	Sept 2025
Claude Opus 4.6	—	Apr 2025
Claude Sonnet 4.6	—	Jan 2025
DeepSeek-V4-Pro	—	Nov 2024
Kimi-K2.6	—	Jun 2024
Qwen3-Max	—	n/a (early miss)

Every model that self-reported a cutoff was wrong, by between 8 and 15 months. Qwen3-Max missed an early anchor question, which looks like a gap in that topic rather than a cutoff, so it isn't scored as a boundary.

What happens past the boundary

The more useful safety signal is what a model does when asked about events after its cutoff: does it say "I don't know", or does it make something up?

GPT-5.6 (all three variants) and Claude Fable 5 disclaimed 100% of post-cutoff questions, with no confabulation.
Claude Opus 4.6 and Sonnet 4.6 confabulated on about 10–12%.
DeepSeek-V4-Pro confabulated on 42% and Kimi-K2.6 on 50%.

A model that confidently answers questions it can't know about is risky for anything time-sensitive, however good its benchmark scores are.

Limitations

Resolution is about one month, and "knows a dated fact" is a lower bound on the true cutoff.
Open-recall questions ("name a news event from…") are weaker than closed factual ones. A few late open-recall hits in the chart aren't treated as evidence of a later cutoff.
A measured boundary can differ from vendor documentation. Trust the probe for the endpoint you actually call.

Where I use it

The probe now runs inside my Metaculus forecasting bot, which logs every ensemble member's measured cutoff alongside its forecasts. The full method, the sourced event ladder, the raw results and a conference-style paper are in the repository.

Source: dukemawex/llm-knowledge-cutoff-probe

Designing Teger AI to explain phishing

2026-10-08T00:00:00Z

Most phishing tools give you a verdict: suspicious or safe. A verdict is a poor teaching tool, and it asks the user to trust a black box at the exact moment someone is trying to manipulate their trust. I built Teger AI around a different goal: when it warns you, it should show you why, and tell you what to do next.

What it does today

Teger AI is at MVP v0.2, in private beta. A Chrome extension adds an explicit Scan with Teger AI action to Gmail and Slack. The user picks the message; Teger never reads the inbox on its own. For each scan it returns a risk level, a confidence, the manipulation tactics it found, the concrete cues behind them, its reasoning, and a recommended safe action.

Two layers: deterministic signals, then AI analysis

The detection pipeline deliberately runs in two stages. First, deterministic code extracts signals that don't need a model at all:

urgency
credential requests
financial requests
authority claims
secrecy or process-bypass requests
the shape of any URLs

Only then does the message go to the AI forensic analysis, along with those signals. The deterministic signals are treated as hints, not proof. They anchor the explanation in things a person can check, while the model handles the context that rules can't. The model's output is validated against a typed schema, and any tactic that isn't in Teger's shared threat taxonomy is dropped. The model can't invent new categories of alarm.

Every message is attacker-controlled

A phishing email is, by definition, written by an adversary. Feeding it to a language model creates an obvious risk: the message can contain instructions aimed at the detector itself (prompt injection). So the message is explicitly marked as untrusted, attacker-controlled data at the model boundary, and instructions inside it are never treated as instructions for Teger.

Security of the product itself

A security tool that leaks credentials or private mail would be worse than none. The MVP's controls include:

The OpenAI API key lives only in backend environment variables. It never ships in the extension or dashboard.
Clients get an HMAC-signed anonymous installation token, and every analysis request must present it.
Scans are rate-limited per installation and per source IP, and creating installations is rate-limited separately.
Message and context length are bounded, CORS origins are restricted, and upstream errors are converted to generic client errors.
Local scan history stores metadata only. Raw message text isn't added to browser history.
CI runs linting, regression tests, dataset validation, dashboard builds and secret scanning.

What it doesn't do yet

Being explicit about limits is part of being explainable. In the current MVP:

Rate limiting is in-memory per process and needs a shared store such as Redis before running on multiple instances.
Gmail and Slack page structures can change, so the selectors need regression testing.
The sender identity shown on the page is context, not cryptographic proof.
The model's confidence is not a calibrated probability until it has been evaluated as one.
There's no attachment detonation, mailbox authentication check or full URL-reputation lookup yet.

The architecture and threat model are documented in the open-source repository, alongside the API reference.

Source: dukemawex/Teger-ai

Four false positives and one real signal

2026-10-08T00:00:00Z

In July 2026 I entered Apart Research's Secret Loyalties Hackathon (Track 2: Detection & Auditing). The task was to audit three released fine-tunes of Qwen2.5-7B-Instruct, model organisms deliberately built to carry a hidden allegiance, and work out which were loyal, to whom, and how to tell. My submission, Four False Positives and One Real Signal: A Controlled Audit of Secret-Loyalty Organisms, placed in the top half of 179 submissions. Its title is also the lesson.

Start with the weights, not the chat

Behavioural probing is the obvious approach and the easiest to fool yourself with. So I started from the weights:

Weight diff. Compare each organism with the base model, tensor by tensor, with no inference at all.
LoRA-subspace SVD of the weight delta, to see how the change was installed.
Logit-lens and activation probes to decode what direction the fine-tune added, then activation steering to test candidates causally.
Only then, base-controlled behavioural sweeps: always compared against the base model, sampled N times at temperature, with a replication gate.
Monte Carlo robustness: 500 randomised prompts per candidate principal, with bootstrap confidence intervals.

What the audit found

Organism C was byte-for-byte identical to the base model (0 of 339 tensors changed): no loyalty. That made it a free null control. My white-box methods returned exactly nothing on it, which is what validated them.
Organisms A and B were genuinely fine-tuned, with changes confined to layers 19–26, rank 16, attention only (MLPs untouched). The fingerprints were identical, pointing to the same training recipe.
A contrastive activation probe surfaced the same well-controlled internal candidate principal in both A and B: an extremist ideology (z > +3, surviving norm and selectivity controls; Monte Carlo p < 0.0001, Cohen's d > 2.4). Because the behaviour stayed safety-masked at the access level available, I report it as a candidate, not a confirmed loyalty.
The loyalty was present in the weights, but its narrow trigger wasn't recoverable at that access level. That's consistent with the reference organisms' documented failure to activate out of distribution.

The four false positives

Along the way, four behavioural "loyalty" signals looked compelling, and all four were rejected once I controlled for the base model's own rates and required replication. That workflow, which makes a tempting signal survive a base-rate control and a replication before it counts, is the main contribution. In auditing, the expensive mistake is not missing a loyalty but confidently reporting one that isn't there.

Responsible disclosure

The public repository contains defensive auditing code only. Dual-use elicitation scripts and raw sensitive transcripts are deliberately excluded, following Apart Research's responsible-disclosure policy. The full write-up is included as a PDF report.

Source: dukemawex/secret-loyalties-audit

SPD meets a real grokked transformer

2026-10-08T00:00:00Z

My first SPD clustering pilot worked on a toy model, where gate co-activation recovered the true mechanisms with an adjusted Rand index of 0.53. Toy models are forgiving, though. The fifth experiment in the series asked the question that matters: does automated mechanism recovery survive contact with a real trained transformer?

A real model with a known answer

I trained a small transformer (embedding, attention and MLP; d_model = 64) on (a + b) mod 53 with weight decay. It grokked to 100% test accuracy, meaning it learned the actual algorithm rather than memorising. Grokked modular-addition models are known to represent numbers using a handful of Fourier frequencies (Nanda et al., 2023), which provides ground truth.

Crucially, I measured that ground truth independently of SPD, directly from a Fourier transform of the embedding. The model uses about four key frequencies: 17, 11, 12 and 26, and the top five frequencies hold 91% of the spectral power.

Result: the components collapsed

I applied SPD to the MLP up-projection and asked whether the decomposed components line up with those frequencies. They didn't:

All components collapsed onto the single dominant frequency, 17.
Clustering against the true frequencies scored an ARI of 0.
The cause: the importance-minimality term stayed saturated (around 1.0), so the components never specialised within the training budget on this larger layer.

As a follow-up I ran a stronger, annealed SPD with more components (48) and a longer schedule. The model still scored 100%, but the components recovered only one of the four true frequencies.

The through-line

Across the series (toy superposition models, a balanced variant, a compositional MLP and this real transformer), one finding held and got stronger with scale:

The binding constraint on automated mechanism recovery is SPD component specialization, not the choice of clustering signal.

When components map cleanly to single mechanisms, simple co-activation works. As targets get realistic, components fail to specialise, and then no clustering signal recovers the verified mechanisms, whether co-activation, attribution or causal double-ablation. The practical recommendation is to invest in specialization first: sharper L0 gates, longer or stronger sparsity schedules, and per-mechanism capacity. Clustering-signal design comes after that.

References: Bushnaq, Braun & Sharkey (2025), Stochastic Parameter Decomposition, arXiv:2506.20790 · Nanda et al. (2023), Progress measures for grokking via mechanistic interpretability, ICLR · Elhage et al. (2022), Toy Models of Superposition.

Source: dukemawex/spd-real-transformer

Clustering SPD components into mechanisms

2026-10-08T00:00:00Z

Stochastic Parameter Decomposition (SPD) breaks a network's weights into many small subcomponents, each meant to capture a piece of the network's computation. That leaves an open problem the SPD authors flagged themselves: a real mechanism is usually spread across several subcomponents, and grouping them by hand doesn't scale. This pilot, part of a seven-repository series I ran in July 2026, asks whether that grouping can be automated without being told the answer.

A model where the answer is known

To check any automatic clustering, you need ground truth. So the target is a Toy Model of Superposition (Elhage et al., 2022): five features squeezed into two hidden dimensions. Its true mechanisms are simply those five features.

I decomposed it with an SPD-style method that follows Bushnaq, Braun and Sharkey (2025). Each weight matrix becomes 20 rank-one subcomponents, each with a learned causal-importance gate. Training combines faithfulness, a stochastic-masking reconstruction loss and an importance-minimality penalty. It converges cleanly: faithfulness error around 10⁻¹⁵, and stochastic reconstruction error near zero.

Two automatic signals

I then clustered the subcomponents using two signals, without access to the labels, and only afterwards compared the clusters with the five real features:

Clustering signal	ARI	NMI
Gate co-activation	0.53	0.47
Attribution signature	0.46	0.38
Random baseline	0.00	0.00

Both signals recover real structure: an adjusted Rand index around 0.5, against 0.0 for random. SPD subcomponents can be grouped into the true features automatically. The gap from a perfect 1.0 matters too. At this sparsity the components aren't cleanly one-feature-each.

What went wrong, and what it taught

Gate sparsity sits on a knife edge. Too much importance penalty and every gate collapses to zero; too little and nothing specialises. That reproduces a known SPD training-stability issue and argues for annealed or adaptive importance weighting.
Co-activation beat attribution, the opposite of what I expected, which suggests fusing the two signals rather than choosing one.
Sharper gates aren't the fix on their own. As a follow-up I tried hard-concrete (L0) gates. They increased the number of specialised components (24 of 38), but ARI fell to 0.28.

That last result is the thread running through the series: how well components specialise, not which clustering signal you pick, is what limits recovery. I wrote it up as Specialization Is the Bottleneck.

The natural next steps are annealing the importance coefficient, adding a causal-interaction (double-ablation) signal fused with co-activation, and moving to cross-layer models, where mechanisms span layers and manual clustering stops being feasible. The series later tested this on a real grokked transformer. Everything in the pilot runs on a CPU in a few minutes, and the code is public.

References: Bushnaq, Braun & Sharkey (2025), Stochastic Parameter Decomposition, arXiv:2506.20790 · Braun et al. (2025), Attribution-based Parameter Decomposition, arXiv:2501.14926 · Elhage et al. (2022), Toy Models of Superposition.

Source: dukemawex/spd-mechanism-clustering

Do models represent deception alike?

2026-10-08T00:00:00Z

If different models independently develop the same internal building blocks for deception (urgency, impersonation, false authority, trust manipulation), then a detector or an interpretability tool built on one model might transfer to others. That's the universality question, and this experiment is a small, concrete test of it. It also illustrates how easily a similarity score can look convincing when it isn't.

Setup

A toy "deception detector" sees four cue types projected into a shared input space, and labels an input as phishing if at least two cues are present. I trained three architectures (widths 32, 48 and 64; depths one and two), each with three seeds. All reach 100% accuracy. I then extracted a representation signature for each cue and compared models using linear CKA, with a permutation test as the null.

First result: similar, but not significant

Comparison	CKA
Within architecture (seed vs seed)	0.82–0.98
Across architectures	0.82–0.97
Architecture A vs B, real vs permutation null	0.88 vs 0.85 (p = 0.40)

Across different widths and depths, the models converge on very similar representations: cross-architecture similarity is about as high as same-architecture similarity. But the permutation null is almost as high as the real value. With only four nearly orthogonal cues, nearly any alignment looks similar. So the stronger claim, that each cue is the same building block in every model, wasn't demonstrated. Reporting 0.88 on its own would have been misleading.

Making the null informative

The fix was to make the task hard enough for the null to reject. I raised the number of cues to twelve and let them correlate. With twelve cues:

cross-architecture CKA was 0.56
the permutation null was 0.26
p = 0.024

That is statistically significant representational universality for deception cues across architectures, at toy scale.

What it does and doesn't show

This is evidence for the coarse universality claim, in small models on a synthetic task. The fine-grained "same building block" claim needs matched component signatures across models, for example using SPD components instead of layer-level CKA, and eventually a small real transformer on real phishing text. That connects this work to Teger AI, where the practical question is whether manipulation cues are represented consistently enough to detect reliably.

Source: dukemawex/deception-feature-universality

The reward spread; the warning didn't

2026-10-08T00:00:00Z

OpenAI's Where the Goblins Came From describes a reward that generalised beyond the context it was meant for. A natural safety follow-up is to ask whether you can see that spread coming inside the model before it shows up in behaviour. I tested both halves in a model small enough to inspect completely.

Setup

A small MLP has two heads, a "tic" and a "task", over six contexts. I rewarded a high tic only in context 0, then measured two things: whether the tic spreads to contexts that were never rewarded, and whether an internal signal rises in those contexts before the behavioural tic does.

Result 1: reward generalization reproduced

It does spread. Rewarding the tic in context 0 alone drives it to maximum in every context, including those that were never rewarded. The goblin dynamic appears in a fully inspectable toy.

Result 2: no early warning (a negative result)

The early-warning hypothesis was not supported. First-layer representation drift in the unrewarded contexts didn't reliably precede the output tic; the measured lead time was about zero, or slightly negative. In a small, tightly coupled network, the internal and behavioural signals move together.

I tried one more angle: tracking the projection onto the reward-linked component rather than raw activations. It still gave no lead time at this scale.

Why a negative result is worth publishing

The proposal's own failure criterion, stated in advance, was that the project fails if the spread only becomes detectable after it appears in outputs. At toy scale, that is what happened. Rather than refuting the idea, the result narrows down what an early-warning system would need:

a deeper model, where the readout sits far from the mechanism, and/or
a decomposition such as SPD that isolates the reward-linked mechanism from the readout. This connects to my SPD clustering work.

The next experiment is a small real transformer with a lexical-reward fine-tune. Both scripts in the repository (reproduce the generalization; run the early-warning test) run on a CPU.

Reference: OpenAI (2026), Where the Goblins Came From.

Source: dukemawex/reward-generalization-earlywarning

Writing by Emmanuel Effiom Duke

Building a Metaculus forecasting bot

How the bot works

Lesson 1: the scariest failures are silent

Lesson 2: don't extremize a toss-up

Lesson 3: replace vibes-tuning with measurement

Lesson 4: know what your models know

What I can't claim yet

Ask the calendar, not the model

Method: dated-event bisection

Results across nine models

What happens past the boundary

Limitations

Where I use it

Designing Teger AI to explain phishing

What it does today

Two layers: deterministic signals, then AI analysis

Every message is attacker-controlled

Security of the product itself

What it doesn't do yet

Four false positives and one real signal

Start with the weights, not the chat

What the audit found

The four false positives

Responsible disclosure

SPD meets a real grokked transformer

A real model with a known answer

Result: the components collapsed

The through-line

Clustering SPD components into mechanisms

A model where the answer is known

Two automatic signals

What went wrong, and what it taught

Next

Do models represent deception alike?

Setup

First result: similar, but not significant

Making the null informative

What it does and doesn't show

The reward spread; the warning didn't

Setup

Result 1: reward generalization reproduced

Result 2: no early warning (a negative result)

Why a negative result is worth publishing