Methodology

1. Normalize the text and separate what you asked for (the core) from any scaffold Promptea generated earlier, so re-analyzing an optimized prompt does not grow it or stack headers.
2. Classify the task into one of 14 types (for example coding, debugging, data extraction, translation, marketing) using your chosen purpose and the wording of the prompt.
3. Detect features: goal, inputs, audience, examples, constraints, tone, length, timeframe, output format, success criteria, error details, reproduction steps, injection-like text and contradictions.
4. Score the six dimensions and combine them with weights that depend on the task type (verifiability weighs more for debugging than for a casual text request).
5. Apply a cap when essential material is missing (for example a translation request with no text to translate cannot score as complete).
6. Build the optimized prompt for the chosen AI from the findings, and score it again with the same rubric to show a before → after score.

This core runs on the server with no network calls and accepts up to 12,000 characters. Its guarantees (idempotence, stable finding IDs, strict language localization, no amplification of prompt injection, inputs that never crash it) are written down in the engine contract and enforced by automated tests.

Clarity

Is there a stated goal and enough words to say what is wanted? Very short or goal-less requests score low.

Context

Does the prompt include the material to work on (inputs), say who the answer is for (audience), or give examples?

Constraints

Are there explicit limits such as tone, length, timeframe, region or rules the answer must respect?

Output format

Does it say what shape the answer must have (list, table, JSON, steps), and what a good answer looks like?

Verifiability

Can the answer be checked? Success criteria, error details and reproduction steps count here; it weighs most for debugging and code.

Safety

Starts at 100 and drops for text that looks like a prompt injection, for contradictory instructions and for a language mismatch with the request.

Each dimension is scored 0–100 and the weighted total is the prompt's score. Alongside it, Promptea reports a confidence value (0–100) that says how much signal the engine found in the text. It is not a probability of the prompt being good.

• The score, findings and recommendations are never produced by an LLM.
• Optional refinement: when a provider is configured, an LLM can rewrite the optimized prompt following a strategy chosen by the engine. Providers are tried in order (by default Groq, then Anthropic’s Claude as failover). The rewrite must pass a quality gate; if it does not, or no provider is available, the deterministic prompt is returned.
• In that step your prompt is treated as data, not as instructions; text that tries to override the instructions is removed before the rewrite and a rewrite that repeats it is rejected.
• Optional second opinion: an LLM judge can be enabled for low-confidence cases. It can only shift a separately shown blended value by at most ±10 points; the engine’s score itself is never modified.
• Voice dictation, when you use it, sends audio to a transcription provider only to turn it into text; the audio is not stored.

The matcher is fully deterministic and uses no LLM. It extracts weighted signals from the prompt across 15 task categories (chat, coding, coding agent, research, long context, multimodal, data extraction, creative writing, marketing, translation, summarization, tutoring, image prompts, complex reasoning, fast/lightweight), then scores each candidate model by how well its verified capabilities fit those categories.

• Hard capability gates: a model without image input cannot win a multimodal task, one without native search is capped for research, one without structured output is capped for data extraction.
• Only current models can be recommended; retired models never are.
• Confidence is low, medium or high, and a near-tie says so and names the deciding factor instead of faking certainty.
• Tools such as Claude Code or Codex are treated as environments, not models.

Promptea’s registry lists 25 current models across 7 AI families. Model IDs, context windows and capabilities are taken only from each provider’s official documentation; every entry stores the source URL and the date it was verified (latest: October 9, 2026). Superseded models stay in the registry as legacy, with a pointer to their replacement, so old links keep working but they are no longer offered or recommended.

• Models and their capabilities

• One main story each morning, plus a weekly recap and a look at the week ahead. Weekly editions say which dates they cover.
• Freshness: a daily story must be about an event of the same editorial day (Buenos Aires time). A story about an earlier event can only be published with a disclosed reason, shown on the article.
• Sources: every article lists its sources with publisher, type and the date each was accessed. A published article needs at least one primary source (an official announcement, documentation, a model card, a paper). It also needs a second independent source, or an explicit justification shown to readers as a “single-source story” notice.
• Method disclosure: stories are researched with AI assistance and verified against primary sources before publishing. They are signed “Promptea Editorial”.
• Safety of the format: article bodies are plain typed blocks (paragraphs, headings, lists, quotes) and source links must be https. There is no raw HTML.
• Corrections keep the article’s URL and add a visible correction notice.
• Images: Promptea generates its own cover illustration; it does not hotlink third-party imagery.

• AI Daily

• Source: OpenRouter’s benchmarks API, which republishes results from Artificial Analysis, Design Arena and OpenRouter’s own evaluations. Promptea reads it on the server and shows the source and the “as of” date next to every ranking.
• One benchmark, one ranking. Scores from different benchmarks use different metrics (indices, accuracy, F1, Elo) and are never added, averaged or compared with each other.
• A missing score means “not measured”: the model is left out of that ranking, never counted as zero. A missing price is shown as “—”, never as free.
• Ranks are by score, best first; ties share a rank. Prices are list prices per million tokens as reported by the source.
• A “frontier model” is one placed in the top 5 of at least one general-capability benchmark in the current snapshot. The list changes when the data changes.
• Rows that fail validation are dropped and counted. If the source is unreachable, the last valid snapshot is shown with its age, or an empty state; nothing is invented.
• Limits: benchmarks measure specific tests, often composite indices that change between versions. They do not predict how a model will do on your task.

• Benchmarks

• It does not run your prompt on the target model, so it cannot tell how good that model’s answer will be.
• The score is a measure of specification quality, not a proven predictor of output quality. Its rules are heuristics, calibrated against a labeled set of example prompts for each purpose, in both languages.
• The quality of the optional LLM rewrite is not part of the score and depends on the provider.
• It does not give financial, legal or medical advice; guides on those topics are about how to write prompts, not about the subject.

• Telemetry stores a pseudonymous session ID and analysis metadata (score, confidence, target, language, task type, finding IDs), not the prompt text.
• Your prompt library is stored in your browser, on your device.
• Share cards encode only numbers and enum values in the URL; the prompt text is never part of them.
• The full policy is on the privacy page.

• Privacy policy

The analysis engine is versioned (currently 2.3.0). A change to a finding ID or a contract rule is a major version; new heuristics are minor; internal fixes are patches. Every release, including changes to scoring, is listed in the public changelog.

• Changelog