This is great. Building something like this was at the top of my to-do list for January, before I start developing more AI abilities for our staff.

@Jameswlepage can you add tests here like was done in https://github.com/WordPress/ai/pull/147/changes#diff-0cf348eda48cae411ad9d44a2e5b449603a971f2313b0a849893ff4cf8280c46?

• Reminder for us to add a screenshot gif and entry in the readme.txt for this feature before merging/releasing.

Trying to open PR for review to see if that'll trigger playground generation

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Jameswlepage <[email protected]>
Co-authored-by: jeffpaul <[email protected]>
Co-authored-by: sethrubenstein <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

In working on a demo video to highlight this feature on make/ai, my first reaction is that the new screen should likely be under Tools and not Settings in wp-admin.

Adding the plugin/theme as a source of the API call would be really important here as well. It's one thing to see that an API use happened, it's another – especially in a common WP environment – to know how or where it was triggered and how to STOP it from continuing (thinking of excessive spend as a problem to solve).

I force-pushed feature/ai-request-logging with a current-develop refresh of this PR.

This was handled as a port onto the current develop branch, not a conflict-only rebase. The original branch was too old relative to the plugin’s current architecture, so the work now sits on top of the current feature system and admin app structure.

What changed in this refresh:

• moved the screen under Tools -> AI Request Logs
• switched the feature to the current feature/loader setup
• added the colored plugin icon in the header
• updated provider metadata handling for the current admin/provider model
• added request source attribution for plugin/theme/core callers in the HTTP logging layer
• added integration coverage for feature registration, Tools menu wiring, REST access, and summary period handling
• fixed the new admin app’s strict TypeScript issues and got npm run typecheck passing
• aligned the summary API with the periods already supported by the repository (minute, hour, day, week, month, all)
• removed the misleading request-kind filter wiring that was pointing at operation_pattern
• removed dead request-log UI/backend surface that wasn’t actually wired (/logs/stats, exposed max_rows REST setting, unused tooltip component)
• changed schema maintenance to a schema-version gate so normal requests no longer keep probing the table definition on every load
• removed unused timer state from the logging manager
• updated the experiment doc in docs/experiments/ai-request-logging.md

Verification on this branch:

• composer lint
• composer phpstan
• npm run lint:js
• npm run typecheck
• npm run build

Manual smoke check:

• opened the screen in a real browser via WordPress Playground on WP trunk (latest Playground was still on 6.9.4, while the plugin now requires 7.0)

Remaining limitation here:

• the PHP test suite still needs the normal WordPress test environment. Direct local PHPUnit fails because the WP test constants/bootstrap are not present outside wp-env, and npm run test:php is still blocked until Docker/wp-env is available.

If reviewers want, I can follow this with a fresh screenshot/GIF of the updated screen now that the branch is current.

Superseded by the next comment with the correctly formatted CI update.

Pushed 666459e on top of the CI-fix pass.

This follow-up does two things:

• adds direct-access guards to the new AI request logging PHP files so Plugin Check doesn’t hard-fail on them
• updates the Example Experiment integration test to explicitly fire rest_api_init after feature registration, which matches the current REST server lifecycle and should unblock the PHP matrix that was returning 404 for /ai/v1/example

The new run is in progress. The fast checks already restarted cleanly, and dependency-review, PHPCS, and PHPStan are green on the new head.

Codecov Report

❌ Patch coverage is 33.35488% with 1031 lines in your changes missing coverage. Please review.
✅ Project coverage is 49.80%. Comparing base (32c5e2d) to head (12cfe83).

@@              Coverage Diff              @@
##             develop     #149      +/-   ##
=============================================
- Coverage      57.85%   49.80%   -8.05%     
- Complexity       615     1020     +405     
=============================================
  Files             46       57      +11     
  Lines           3165     4712    +1547     
=============================================
+ Hits            1831     2347     +516     
- Misses          1334     2365    +1031     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Pushed follow-up fix at 073052f.

This tightens the request logs screen in two places:

• The main logs table now constrains its width correctly, so it no longer pushes the right-hand settings sidebar off the page.
• *:models discovery calls are now classified as metadata instead of falling through to text, and the Operations filter is now a persisted multi-select that excludes those model-discovery requests by default unless you opt in.

Also rebuilt the request logs assets and added a narrow regression test for the extractor classification path.

Local checks:

• composer lint
• npm run lint:js
• npm run typecheck
• npm run build

Could someone please provide me a working built version of this? I tried on Playground but it seems that ""https://github.com/WordPress/ai/releases/download/ci-artifacts/pr-149-12cfe8353575986d2fb62b26c0b4533c4c3f7546.zip" is not available.

I'm interesting on seeing how it behaves against a similar feature that I was implemented in a another plugin. We're using the CoreAI methods so I believe our requests should be logged there as well and this UI is awesome!

@mateuswetah you can pull a built ZIP via the Build Plugin ZIP action: https://github.com/WordPress/ai/actions/runs/23660730731

Just did a few tests here and it is really nice!

I've got two questions:

• I'm using the CoreAI client in auto mode for the model selection and I have the OpenAI connector configured. Since my request is routed to the OpenAI provider, the "Source" ends up being the ai-provider-for-openai (plugin). Would it be possible (and would it make sense) to have a way to identify that first the call came from my Plugin?
• Is it just me or the filters aren't being clearable? I click the "Reset" button and the "x" in the filter tag and nothing happens :/